【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】task 工具提示词（Usage Notes）
分析了 Task 工具提示词的介绍，并发执行（可以在同一条回复里连续调用多次 Task 工具），结果隔离与汇报（子智能体的返回结果对用户不可见，主 Agent 需要自己发一条文本消息，把结果总结给用户看），子智能体的两种生命周期，Fresh Context（默认情况下，每次调用 Task 工具都是启动一个全新的智能体），Resume witch task_id（如果复用了上一次返回的 task_id，就能唤醒同一个子智能体），信任授权（主 Agent 应该信任子 Agent 的输出），指明方向与验收标准（在分派任务时，主 Agent 应该再说清楚目的和验收标准，指令越精准，返工率越低），主动出击（优秀的 AI 应该具备预判性，在用户意识到需要之前，把任务分派给子智能体去预热），下面继续分析
OpenCode
接着分析 Task 提示词中举的例子
首先这里定义了两个虚拟的子智能体专家
code-reviewer：负责代码审查，当用户或者主 Agent 写完一段比较复杂的代码后，该子 Agent 会被派上场greeting-responder：负责问候，氛围组，其任务极其垂直且单一，当用户和 OpenCode 打招呼后，该 Agent 可以用一种轻松，友好，幽默的方式进行回应
接着举了第一个例子
- 用户提出需求：写一个判断质数的函数
注意，主 Agent 并没有一上来就用 Task 把任务分配给子 Agent，而是亲自操作，直接调用 Write 工具把代码写出来了，这里展示了 AI 系统的成本与延迟权衡：写一个几十行的基础函数，对主 Agent 来说是小菜一碟，响应极快且消耗 Token 少，如果这种小事都要启动子 Agent（需要建立独立上下文，传输背景信息等），那就属于典型的杀鸡用牛刀，既浪费钱又浪费时间
| 决策逻辑 | |
|---|---|
| 简单，明确，短平快的核心需求 | 主 Agent 亲自执行 |
| 复杂，庞大，需要深度调研的需求 | 分派 Task 给子 Agent |
- 思维链 ：在真正调用
code-reviewer之前，系统插入了一段<commentary>（内心独白），这是 AI 的元认知时刻，主 Agent 在执行完写代码的动作之后，并没有着急结束，而是停下来进行了一次自我审视【我刚刚完成了一个有意义的代码模块，按照标准作业程序，下一步必须触发代码审查】，如果没有这段独白，AI 很容易写完代码就直接返回给用户，而忘记做后续的质量把控，所以这段独白强制 AI 在执行模式和管理模式之间进行了切换 - 主动质检 ：紧接着，主 Agent 提到【Now let me use the code-reviewer agent ...】，这是整个例子中最核心的主动防御机制，在大模型里，写代码的模型（Writer）和代码审查的模型（Reviewer）往往需要不同的思维，写代码需要创造力和逻辑连贯性，而审查代码则需要批判性思维和找茬能力，如果让主 Agent 自己检查自己的代码，它就很痛陷入思维惯性，觉得它写的代码肯定没问题，而通过强制启动一个独立的
code-reviewer子 Agent，相当于引入了一个第三方独立审计机构，它能以全新的视角，不带任何预设偏见地去审视这段代码，从而减少 Bug - 任务派发 ：最后主 Agent 执行了动作，这里也展示了多智能体协作的松耦合设计，主 Agent 不需要知道
code-reviewer内部具体是怎么检查代码的（是跑静态分析？还是查安全漏洞？或者检查命名是否符合规范），主 Agent 只需要做一个标准的派发动作，这种设计让整个系统具有高度扩展性，假如未来用户想把审查标准改的更严格，只需要升级code-reviewer这个子 Agent 的内部提示词即可，主 Agent 的任务派发逻辑完全不用动
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog