共享上下文的多 Agent 协作
共享上下文的协作凭什么是"继承式"的？
- 结构: 每个阶段都是一个独立 Agent（拥有自己的系统提示词与工具集），但它继承前序 Agent 的完整轨迹;
- 类比: 接班的同事能翻阅前任留下的所有工作日志;
- 核心优势: 信息不丢失，每个 Agent 都能回顾之前任何阶段的细节;
- 核心挑战: 如何让当前 Agent 专注于自身核心职责，而不被继承来的大量历史信息干扰（角色惯性）;
- 轨迹定义见 Agent 公式与边界;
为什么要在阶段之间切换角色？
- 问题: 复杂任务中 Agent 的角色与职责在不同阶段显著变化，若始终使用同一套静态系统提示词，要么过于笼统缺乏针对性，要么把所有阶段指导塞在一起而过于冗长;
- 做法: 按当前阶段动态切换系统提示词与工具集，让 Agent 在每个阶段以最合适的"身份"工作;
角色转换应该替换 system prompt 还是加载 Skill？
| 选择 | 角色规程的载体 | 工具可见性 | 上下文/KV Cache 影响 | 约束能力 |
|---|---|---|---|---|
transfer_to_agent | 替换当前 system prompt，通常并替换工具集 | 只暴露当前角色工具 | 每次切换改变请求前缀；从变化点起的缓存通常无法复用 | 强：越界工具在 schema 层不可见 |
| Skill | 固定 system prompt 中的 Skill 目录，按需把 SKILL.md 追加到轨迹 | 通常固定暴露工具全集或稳定的工具搜索入口 | 静态前缀不变；Skill 内容成为末尾轨迹，已有前缀可继续复用 | 弱：Skill 是行为指令，硬权限仍需 Harness 门 |
- 判断规则一: 角色差异主要来自知识、流程与写作风格时，优先使用 Skill;
- 判断规则二: 角色差异涉及权限、工具隔离、合规边界或需在运行时强制禁止某类动作时，使用独立 Agent 或
transfer_to_agent，并在 Harness 层用代码限制工具调用; - 相关模式: 渐进式披露与只增不改的设计意图见 设计模式;
实验对比的结论是什么？
- 控制变量: 两条路径使用同一模型、同一用户任务、同一工具实现、同一份角色规程与全量共享轨迹，任务为查找中国 2021—2023 年新能源汽车销量、计算 CAGR、写不超过 120 字的投资人摘要;
- 路径一（系统提示词切换）: 五种角色 triage（默认入口）、research、coding、data_analysis、writing，每个角色只看到自己的专属工具与
transfer_to_agent；移交时保存历史、加载目标角色提示词与工具集再继续; - 路径二（Skill）: system prompt 与完整工具全集在整个会话中固定，模型按需调用
load_skill(name)，读到的SKILL.md作为 tool result 进入共享轨迹; - 关键差异: Skill 路径静态前缀不因角色变化而重写，但工具始终可见，硬权限由 harness 中的规则保证;
- 架构含义: 共享上下文下"角色"可以是提示词层面的规程，也可以是运行时层面的隔离，两者成本模型不同，不能互相替代;