Agent、Skill、MCP、Subagent：分别解决什么问题

01 / 定义：四个词对应四种职责

Agent 指围绕目标、结合观察与工具结果选择下一步行动的执行方式。Skill 保存可复用的方法与相关资源。MCP 约定应用与能力提供方之间的通信。Subagent 把一段工作放进独立的任务上下文，再返回结果。具体产品的实现与命名可能不同。

固定步骤的流程也可以调用模型，它未必需要每一步都由 Agent 自主规划。相反，一个能动态调用工具的 Agent，也可能完全不使用 MCP，而是调用应用直接提供的函数。

02 / 推导：先判断瓶颈在哪一层

假设你要做需求评审助手。它看不到需求文档，问题在资料接入；它看到了却总漏掉异常状态，问题可能在方法；它需要分别核查权限和性能，可能适合任务拆分；它要根据检查结果决定是否继续读取，才涉及动态组织过程。

不要因为评审效果差就马上加 Subagent。若所有助手都拿到同一份过时文档，更多助手只会更快重复错误。先检查最早失败的环节，再选择组件。

03 / 应用：分四步搭一个需求评审方案

1. 先用最简单流程。上传一份脱敏需求，要求按明确清单输出问题、原文位置和建议。人工核对遗漏，得到基线。
2. 重复方法才沉淀 Skill。如果多份需求反复漏权限或异常状态，把检查动作与反例写成可复用规则。换文档后仍能工作，才说明保存了方法。
3. 资料持续更新再接工具。如果文档不再适合人工上传，提供受控读取能力。已有 MCP 服务且宿主支持时可采用 MCP；仅一个内部应用调用单一 API，也可以直接集成。
4. 独立工作足够大再拆分。把安全、数据一致性等调查分给独立任务，约定同一版本和返回证据。主任务复核冲突，不能简单拼接摘要。

需求评审的最小契约
输入：指定项目、文档 ID、版本、评审目标。
方法：检查角色、状态、异常和验收条件。
输出：问题位置、触发条件、影响、建议、未验证项。
边界：只读；不修改文档；不替业务方批准需求。
合并：冲突先对齐前提和版本，再复核证据。

每加一个组件都问一次：它解决哪个已观察到的问题？如何证明比原方案更好？如果答案只是“更像 Agent”，先不加。

04 / 验收：按职责定位失败

• 没有读到文档：检查工具连接、权限与文档标识，不先重写评审 Skill。
• 读到旧版本：检查版本与缓存，不先增加提示词长度。
• 漏掉已知风险：检查方法、样例与执行过程，不把工具可用当质量合格。
• 子任务结论冲突：核对输入版本、规则与证据，不按多数投票决定事实。
• 执行越界：收紧真实权限与动作检查，不只加一句“请谨慎”。

组件测试和整体测试都要有。读取工具可以正常、评审方法可以合理，但组合后可能把错误文档交给正确方法。最终仍应以一份完整输入及可复核输出验收。

05 / 迁移：学会组合，也学会少用

如果任务只是把五行数据分类，一段清晰指令就可能足够；如果任务固定、需要重复精确计算，脚本更合适；如果涉及变化的外部信息与多步取舍，再考虑工具与 Agent。能力越多，权限、调试和维护成本也越高。

接下来分别进入Skill 的制作、Subagent 的协作和MCP 的机制。它们是可选择的工具，不是必须依次安装的套餐。