agent的上下文组成由哪些部分组成？role，skill/tool/mcp，memory，工具结果以及以上组成的探索轨迹。也就是说，是这些定义的agent的能力，那么对于agent团队的协作来说，哪些是可以复用，哪些是应该保持不同，隔离的？

可以这么理解，但需要补一个区分：上下文是 Agent 当前“知道什么”，不等于它全部的能力。模型本身、实际工具权限、运行环境，以及外部调度和验收机制，也会决定它“能做什么”。 对 Agent 团队来说，我建议按“共享契约、复用能力、隔离执行状态、按需交换证据”来划分，而不是简单地按 role、skill、memory 整块共享。 先用一个 Coding Agent 的例子。 假设主 Agent 要给项目加登录功能，分给后端 Agent、前端 Agent 和验收 Agent。 三者应该共用登录接口契约：请求字段、响应格式、错误码、验收要求。但后端不需要看到前端排查 CSS 的全部工具日志；前端也不需要后端尝试数据库迁移时的所有失败记录。 后端完成后，应该交接“接口已实现、契约版本、修改位置、测试结果、剩余风险”，而不是把整段会话复制给另外两个 Agent。 验收 Agent 要知道需求和实现结果，但初次检查时可以不读实现者“为什么我觉得代码正确”的长篇解释，避免被同一套假设带偏。 对应到你列的组成，可以这样拆。 一、role：公共规则共享，职责和授权不同 团队可以共享编码规范、安全约束和完成标准。 不同 Agent 的任务目标、负责范围、可修改资源、交付要求应该分别设置。例如后端负责接口实现，验收者负责验证行为，不应该因为两者看到了相同上下文，就自动拥有相同写权限。 role 也不只是“你是资深后端专家”这种身份提示，更重要的是明确责任边界和验收契约。 二、Skill：可以复用，按职责加载 比如代码检索、运行测试、提交评审这些 Skill，可以作为团队公共能力库。 但“都能使用”不等于“每个 Agent 每轮都加载全部内容”。前端不需要默认加载数据库迁移流程，验收者可能需要额外加载测试设计流程。 还要区分 Skill 的定义与运行状态：同一份迁移 Skill 可以复用，但本次迁移的目标数据库、执行进度和临时产物不能混在一起。 三、tool / MCP：接口可复用，权限和会话状态要隔离 MCP 更接近连接工具和资源的协议层，不是与 tool 完全独立的一份“智能能力”。进入模型上下文的通常是工具说明、资源内容和调用结果；真实执行发生在外部。 多个 Agent 可以连接同一套服务，但不应因此共用所有权限。 例如同一个数据库服务，调查 Agent 只读，实现 Agent 可以修改测试库，两者都不能默认操作生产库。权限需要在工具端实施，不能只靠提示词说“别乱改”。 浏览器登录会话、终端进程、当前目录、事务等可变状态，也应独立或显式协调，否则一个 Agent 的操作会悄悄改变另一个 Agent 的环境。 四、memory：共享事实，隔离草稿，验证后晋升 memory 不能当作一个整体处理。 项目规范、已确认的接口契约、已验收的决策，可以进入共享记忆。 “我怀疑问题来自缓存”“这个接口可能废弃了”这类调查假设，应该先留在任务局部记忆里。确认之后，再附来源和适用版本写入共享区。 否则 Agent A 的猜测会被 Agent B 当成事实，B 的输出又强化 A 的猜测，形成团队内部的错误循环。 个人偏好、用户私密信息等，还需要按用户和授权范围隔离，不能因为属于同一个团队就全员可读。 五、工具结果：按相关性和有效期复用 某个固定 commit 的文件内容、测试报告、依赖分析结果，可以复用，减少重复调查。 但必须带条件：哪个 commit、什么环境、什么命令、什么时候执行、是否成功。 例如后端分支测试通过，不能推出合并后的主分支也通过；旧代码上的检索结果，也不能直接代表修改后的代码。 所以应该共享“有来源和版本的证据”，而不是共享一句脱离条件的“通过了”。 六、探索轨迹：默认局部保存，交接必要部分 探索轨迹不是与工具结果完全平行的类别，它通常已经包含消息、工具调用、工具返回、修订和中间产物。 不要默认把完整轨迹广播给所有 Agent。那会增加上下文成本，也容易传播过时假设、无关细节和不可信工具文本里的指令。 更合适的是交接： 任务与约束。 确认的结论及证据。 修改或产物位置。 已尝试但失败的路径及原因。 未解决问题和下一步依赖。 完整原始日志保留用于追溯，接收者需要时再读取。这里交换的是可观察的执行记录和证据，不必要求模型输出内部思维过程。 最后还有一个很重要的区分：上下文隔离，不等于资源隔离。 两个 Agent 即使使用独立会话，只要同时修改同一个工作目录，仍然会冲突。Coding 场景通常还需要独立 worktree、分支、测试环境，以及明确的合并和集成验收流程。反过来，独立 worktree 也不能避免接口语义上的冲突，所以公共契约必须共享。 因此，判断某项内容该不该共享，可以问三个问题： 它是稳定定义，还是本轮可变状态？ 它是已验证事实，还是局部假设？ 接收者需要它来完成任务吗，而且有权限看到它吗？ 结论就是：能力定义尽量复用，事实通过受控渠道共享，执行状态与权限边界保持隔离，探索轨迹按需交接。多 Agent 的价值不在于让所有成员知道所有事情，而在于让每个成员拿到足够且可信的信息。 参考：Anthropic 的多 Agent 研究系统实践，涉及独立上下文、任务委派和结果交接： https://www.anthropic.com/engineering/multi-agent-research-system