02 · 上下文、工具、技能与并行协作：不要让一个提示词承担所有职责

定位：架构方法归纳。 仓库有工具、记忆、Hooks、MCP、技能及多代理教程，也有相关比较页面；它没有实现一个通用 MCP 服务平台或多代理编排引擎。具体命令和产品能力应按实际安装版本核对。

一个 Agent 项目开始变复杂时，常见应对方式是不断扩充系统提示词：写进项目背景、业务规则、工具用法、异常处理和协作说明。短期内似乎有效，长期却很难知道某项要求到底应该由谁保证。

整理 claude-demo 的扩展点研究，可以提炼出一条原则：上下文负责解释，工具负责动作，工作流负责约束顺序，验证负责判断结果。不要让它们彼此替代。

一、先把五类职责分开

机制	主要职责	不应承担的职责
项目记忆与上下文	说明背景、约定和当前状态	代替测试，保存凭证，保证执行正确
工具	执行明确的读写或计算动作	自行扩张用户授权范围
技能	封装某类任务的入口、步骤和参考	隐藏未经确认的发布或收费行为
事件钩子	在约定事件点执行检查或动作	凭名字就被视为不可绕过的安全边界
子任务与编排	分配独立责任、协调依赖和交接	通过人数或投票自动证明事实

这些是逻辑职责，不要求每个工具产品采用同样的名称。迁移到不同的 CLI、IDE 或 Agent 平台时，先映射职责，再学习语法，比直接照搬配置片段更稳妥。

二、上下文的关键是选择，而不是堆满

仓库的上下文资料讨论了压缩、清空、项目记忆和交接。它们解决的共同问题是：长任务中，哪些信息必须保留，哪些信息应按需取回？

稳定的项目约定适合放在持久规则中；当前任务状态适合放在交接记录中；大体量代码、日志和参考资料则更适合用索引定位。把所有历史输出反复注入，并不能保证模型优先关注真正重要的约束。

这次仓库整理采用的交接单位也是“主题范围＋证据路径＋结论边界”，而不是让每个研究进程复制完整聊天记录。六个独立只读研究进程分担不同目录，主任务统一核对分类、源码引用和文章表述。

只读约束仍要说清楚：文件系统只读，不天然意味着所有外部工具都没有副作用。浏览器、云接口或生成服务可能修改远端状态，所以任务说明还需要明确网络、发布与计费边界。

三、MCP 解决连接，不替你完成授权设计

MCP 研究关注如何把 Agent 连接到外部工具或资源。连接层标准化有价值，但不能据此推导出“Agent 可以安全访问所有内部系统”。

每个工具仍然需要明确：

1. 输入中哪些参数由模型建议，哪些必须由可信上下文绑定。
2. 调用者是否有权访问目标记录或执行目标操作。
3. 返回内容来自哪里，是否可能包含提示注入或敏感数据。
4. 失败是否可以重试，重复调用是否会重复产生副作用。

仓库中的 mcp-browser-tools.html 是一个比较与展示页面，图表和评分由页面数据驱动，并不是 MCP 服务端实现。分享时应把“研究了连接方案”与“已经接通并验证了系统”分开。

四、技能应该像一个小型交付包

仓库保留的下载工具技能设计，将入口说明、参考材料、执行脚本和测试分开。这个结构比“保存一段常用提示词”更可维护：入口负责触发，说明负责边界，脚本负责确定性操作，测试负责防止回归。

其中目标技能的位置在仓库之外。本系列只据此讨论设计方法，不用仓库中的计划来证明外部技能已经安装或验证通过。

适合封装成技能的通常是反复出现、依赖稳定、失败类型可枚举的工作。例如读取素材规格、生成检查图、检查交付包。一次性的审美探索可以提供参考流程，却不应伪装成总能得到正确结果的确定性能力。

五、哪些任务适合并行

并行适合责任独立、输入明确、输出可以合并的任务，例如分别研究模型显存、素材动画和三维建模。共享同一个输出文件、依赖相同浏览器会话或需要顺序决策的任务，则需要串行化关键部分。

flowchart TD Scope["定义范围与统一证据格式"] --> ResearchA["只读调研 A"] Scope --> ResearchB["只读调研 B"] Scope --> ResearchC["只读调研 C"] ResearchA --> Review["主任务核对与冲突处理"] ResearchB --> Review ResearchC --> Review Review --> Publish["统一编辑与发布检查"]

一个合理的交接结果应该包含：发现、源文件、起始行、证据类型、未验证事项，以及可能与其他任务冲突的结论。与之相比，“我已经全面检查，没有问题”几乎无法复核。

理想并行时间受最长子任务限制，而不是所有子任务耗时相加；实际还要加上拆分、重复阅读、审查和合并成本。本文没有测量并行加速比，不把这一结构推导成效率倍率。

图 02：三条泳道仅用于解释独立分工，不对应实际研究进程数量，也不表示加速倍数。文件系统只读仍需约束远端工具的副作用。

六、复核比投票更重要

多个执行者得出相同结论，并不意味着它是真的。它们可能引用了同一篇过时文档，或者复制了同一处错误公式。

仓库的多代理审计案例提出结构化发现与反向验证，这是值得保留的方法。更稳妥的复核顺序是：先找到具体文件，再确认该文件是实现还是示例，然后用最小实验或计算检查结论，最后才讨论置信度。

在本次整理中，模型显存表格与链接协议都出现了“文档看似完整，但需要重新计算或核对消费者”的情况。增派一个只重复阅读摘要的代理不会解决问题；让复核者直接检查公式、配置和实际解析逻辑才有用。

七、可迁移的最小实践

建议从三个小改动开始：给每个工具定义副作用与错误契约；给每个长任务保存简短交接状态；给每个并行任务分配独立输出位置，并要求证据化返回。

只有当这些规则稳定后，再增加自动编排、事件钩子和更复杂的工具链。这样扩展的是可验证能力，而不是不可见的系统复杂度。