Pull Request已成功合入, 合并人@openJiuwen-bot
（感谢 zhangyao 的贡献）
变更摘要
本 PR 属于 /kind bug 修复，核心是完善 DeepAgent 对 AgentTemplate（模板）与插件（plugin）的创建、加载与执行支持。主要包含三方面：其一，DeepAgent 在加载、切换或卸载 AgentTemplate 时，通过 PromptAttachmentManager 向会话写入 expert_role 专家角色切换的模型可见通知（加载/卸载提示），并用 _active_agent_template 记录当前生效模板；其二，extension_binder 调整技能绑定顺序，使包内扩展技能优先于宿主同名技能（优先级：专家 > 插件 > 用户本地技能）；其三，插件 manifest 支持通过 file 字段路由加载 prompt_sections/*.md 作为提示词片段。
主要改动
- 专家角色加载/卸载通知同步：在
deep_agent.py中新增_sync_expert_role_attachment、_expert_role_load_content、_expert_role_unload_content以及_active_agent_template状态记录，在invoke/stream/run_one_round的调用路径上同步expert_role会话附件（PromptAttachmentKind.RUNTIME），实现加载、切换、卸载时的角色提示写入。 - 默认会话 ID 兜底：当
session与conversation_id均为空时，invoke_inputs.conversation_id会填充为_DEFAULT_CONVERSATION_ID = "default_session"，保证内层 agent 与附件管理使用一致的会话标识。 - 技能绑定优先级调整：
extension_binder._bind_skill重排skills_dir，将已绑定的包根目录置于宿主目录之前，使扩展（插件）包内的同名技能优先于宿主技能（SkillUseRail保留先加载的名称）。 - 插件提示片段文件路由：
extension_loader新增_build_prompt_section_specs，支持 manifest 中prompt_sections以file指向prompt_sections/*.md的方式加载（文件名作为name，文件内容作为content），同时校验文件必须位于prompt_sections/目录且为.md，并保留内联name+content写法及priority、render_params透传。 - 测试覆盖更新：新增
tests/unit_tests/harness/test_deep_agent_expert_role.py（覆盖加载/切换/卸载/失败回滚/多会话/任务循环等场景），并为插件提示片段路由、技能优先级、默认会话 ID 补充或更新了既有单测断言。
欢迎来到 openJiuwen 社区
Hey @zhangyaomaggie , 感谢你对社区的贡献.
机器人使用手册
有关指令的使用，可以点击 此处 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。
联系指引
有疑问可以联系 SIG: sig-agent-core ,
维护者是： @seanzhang_cn, @xinyu-jiuwen ,
审核者是： @alan_cheng, @chenmaxqian, @cyz95, @deyang, @gcw_xJSJ32Ge, @iamcandiceguo, @xiaowenzihwl, @yangzequ, @zepinzhang .
The pipeline(pipeline number:2558) is running. Please wait a moment...
The pipeline(pipeline number:2558) is running. Please wait a moment...
检视意见：
实现质量高、测试充分（T-01~T-13 覆盖快照位置、幂等、切换、失败回退、插件隔离、子代理隔离）。三块改动各自独立成立。红线核查：生产代码无新增 URL；专家角色通知属 runtime attachment 功能设计，非篡改基础系统提示词。以下问题建议作者回应：
🟡 建议修改
N1 — 专家角色通知文案硬编码中文，无 i18n（deep_agent.py:261-272）
_expert_role_load_content / _expert_role_unload_content 固定输出中文，而 harness 提示体系是语言感知的（_render_identity_prompt(prompt_builder, language)）。英文 locale 的 agent 会收到中文运行时通知。建议按 agent language 走双语模板。
N2 — 技能优先级静默反转，属破坏性行为变更（extension_binder.py:235-258）
旧语义（旧注释明确记载）：workspace/skills 赢过同名 package skill；新语义：package 全面优先。测试同步改写说明是有意为之，但对依赖 workspace 覆盖同名插件技能的现有用户是静默破坏。建议在 PR 描述/CHANGELOG 显式声明此行为变更及动机。
N3 — invoke 无 session 时强制注入 conversation_id="default_session"（deep_agent.py:2796-2799）
_sync_expert_role_attachment 为拿到落点 session_id 直接改写 invoke_inputs.conversation_id，这是全部 invoke 路径的可见行为变更（test_deep_agent.py:518 断言改写证实）。可能影响下游按 conversation_id 路由的记忆/持久化行为。建议仅在确有 active template 时才补默认值，或换一种不修改调用方输入的落点推导方式。
🔵 信息
- N4：
_bind_skill深入读取agent._load_records内部结构并逐条 resolve() 分类 package/host 目录——binder 层耦合 agent 内部状态，可在 LoadRecord 上预计算 package_root 消除 - N5：
_sync_expert_role_attachment整体 except Exception 吞掉并 warning——"角色通知不得阻塞模型调用"取舍合理，但附件写失败时用户无感知丢失角色切换指令 - N6：prompt_sections 以 md stem 作 section name，不同子目录同名 stem 会冲突（低风险）
- N7：unload 通知写入后永久保留 unload 文案（不清 section）——T-09 证实同角色重载幂等，语义自洽
📡 KV-cache 命中率影响分析
结论：核心设计对 KV-cache 友好，稳态无额外失效；有三处一次性/边界成本需知晓。
✅ 对缓存友好的证据：
- 增量注入设计正确。expert_role 通知经 PromptAttachmentManager 以 SystemMessage 快照/增量形式追加到上下文历史尾部（T-01 断言 [snapshot, user_message]；
collect_for_session仅被 sync_to_context 消费，不进每次请求的系统提示词）。尾部追加意味着 system prompt + 历史前缀不变，provider 侧前缀缓存（DeepSeek/GLM implicit cache、KVCacheAffinityConfig）仍然命中——角色切换只增加新 token，不作废前缀。 - 稳态幂等。同角色重复 invoke 时 add_section 内容确定性相同，state 无变化 → sync 返回 None（T-02 证实），不产生任何新消息，零缓存成本。
conversation_id="default_session"预填不改变 KV-cache 亲和键。核对 react_agent invoke 路径：session 为 None 时原本就走session_id = conversation_id or "default_session"，自动创建的 session id 在本 PR 之前就是 "default_session"；resolve_lineage以ctx.context.session_id()为 fallback，亲和键 (id(model), session_id) 前后一致。
⚠️ 需知晓的成本与边界：
- 切换/卸载轮次的一次性尾部追加：load/unload/A→B 各产生一条 SystemMessage 增量（自包含文案，T-03），纯增量、无前缀作废——成本可忽略。频繁切换场景下尾部会积累角色通知 token（与 N7 的永久保留叠加），长会话有轻微上下文膨胀。
- N2 的技能目录重排序会在 hot-load 绑定后改变 skills_dir 顺序 → 若技能列表渲染进系统提示词，绑定后的首个请求系统提示词内容变化 → 一次性全前缀失效。这不是新增的失效类别（绑定本来就会改 skills_dir），但重排使绑定前后差异更大，值得留意。
- 边界：agent 全局的
_active_agent_template对多 session 实例意味着每个 session 在各自下一次 invoke 时尾部各追加一条通知——按 session 分别看仍是尾部追加、缓存安全；但同一实例服务多个无 session 调用方时，所有调用方共享 "default_session" 的附件状态，存在角色通知跨调用方污染的正确性风险（与 N3 相关，非缓存问题本身）。 - 压缩恢复路径已考虑：manager 在快照被 compaction 移除后会重渲染完整快照避免孤儿增量（docstring 明确），该重建同样是尾部追加。
综上：从 KV-cache 命中率角度本 PR 无回归风险；建议把第 6 点的多调用方共享 default_session 附件状态纳入 N3 一并考虑。
The pipeline(pipeline number:2558) is running. Please wait a moment...
Paired: GitHub #1001 ↔ GitCode !2558
What type of PR is this?
/kind bug
prompt_sections/*.md.Self-checklist:（请自检，在[ ]内打上x，我们将检视你的完成情况，否则会导致pr无法合入）
Linked Closing Issues: