分类：AI编程
模型只做预测，真正的执行在框架里
在 Agent 开发中，许多团队容易把“多智能体协作”理解为模型自身具备的能力：只要提示词足够强，模型就能自己拆分任务、调用工具、指挥多个子 Agent 协同工作。掘金上一篇技术文章给这类认知降温：大模型本身只负责根据输入 Token 预测下一个 Token，Sub-agent 并非模型长出的分身，而是客户端或 Agent 框架层的工程能力。
从运行机制看，大模型并没有“分身乏术”。它不能自己开辟一个独立运行环境，也不能主动创建、调度另一个模型实例。所谓 Sub-agent，本质上是外部代码把复杂任务拆开，再分别安排不同的上下文、工具和循环逻辑。
这也是 Agent 开发中最需要祛魅的一点：当用户提出一个复杂请求时，模型输出的仍然是文本形式的下一步内容，真正决定“接下来调用哪个工具、保留哪些上下文、何时结束任务”的，是框架中的状态调度和工程代码。
复杂任务为什么容易压垮单个 Agent
素材给出了一个常见场景：“帮我重构整个项目的代码，顺便写单元测试并跑通”。如果把这类任务一次性交给同一个主 Agent，失败概率会明显上升。原因并不一定是模型不够聪明，而是它可能同时面对过多目标、过多工具和过长上下文。
- 注意力被多个子目标分散，模型难以长期围绕单一任务保持一致。
- 可用工具过多时，选择调用哪个工具的判断更复杂。
- 上下文不断变长，早期指令、工具结果和中间状态会互相干扰。
在这种情况下，Sub-agent 架构的价值被凸显。文章将其概括为主从分工模式，也称 Coordinator-Worker Pattern：由主 Agent 负责总体协调，再把具体子任务交给更聚焦的子智能体处理。
子智能体不是模型分身，而是“套娃式”工程状态机
在工程实现上，LangGraph、CrewAI、AutoGen 或自定义客户端等框架都可以构建 Sub-agent。它们的共同点，不是让模型获得新的超能力，而是通过代码设计出一套可调度的流程。
素材中的伪代码展示了典型路径。开发者先定义一个专门的子智能体处理函数，例如一个代码评审子 Agent。这个函数被包装成工具，供主 Agent 调用。函数内部会创建独立的上下文，并进入独立的 ReAct 循环。系统提示可以是“你是一个资深代码评审专家，请严格检查安全漏洞”，随后子 Agent 在最多 5 步内调用模型和工具。
如果模型给出最终答案，函数把精简结果返回给主 Agent；如果模型要求调用工具，代码会执行对应工具，并把工具结果写回子 Agent 的上下文。这里的工具示例包括 git_diff_tool 和 linter_tool。最后，这个子智能体函数会被注册为主 Agent 的一个工具，例如名为 call_code_reviewer_subagent，描述为“当你需要对代码进行深度安全评审时调用此工具”。
这段实现说明，Sub-agent 的关键并不神秘：把子任务打包成工具，隔离上下文，并裁剪权限。它避免所有中间过程都挤进同一个对话窗口，也减少无关 Token 对主任务的污染。
对 AI 编程开发者的提醒
这一判断对 Agent 开发有直接意义。首先，团队不应把多智能体协作简单理解为模型版本升级后的自然结果。即使模型能力提高，任务拆解、上下文隔离和状态调度仍然是工程重点。
其次，评估一个 Agent 产品时，不能只看它接入了多少模型或列出了多少工具，还要看它如何管理任务边界。哪些信息进入子任务、子任务能调用哪些工具、循环最多执行多少步、结果如何回传，这些设计都会影响稳定性。
对于 AI 编程场景，这一点尤其重要。代码评审、测试生成、重构、构建和运行日志分析，往往需要不同权限和不同上下文。把它们全部塞给一个 Agent，容易造成上下文过载；拆成多个受控子任务，则更接近软件工程本身的处理方式。
换句话说，Agent 开发的门槛并没有因为模型会“说话”而消失。模型负责生成下一步可能的文本和工具调用建议，框架负责把这些建议变成可控的执行过程。理解这条边界，才是做好 Sub-agent 系统的第一步。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/da-mo-xing-bu-hui-zi-ji-kai-fen-shen-agent-de-duo-zhi-neng
