文章目录
-
- 前言
- [1. 先说清楚，subagent 到底是个啥](#1. 先说清楚，subagent 到底是个啥)
- [2. 但是，风向已经变了](#2. 但是，风向已经变了)
- [3. 康威定律：系统是公司的照妖镜](#3. 康威定律：系统是公司的照妖镜)
- [4. 企业搭 Agent 的五大翻车姿势](#4. 企业搭 Agent 的五大翻车姿势)
-
- [4.1 上下文管理：快递丢了](#4.1 上下文管理：快递丢了)
- [4.2 subagent 泛滥：Agent 太多，责任太少](#4.2 subagent 泛滥：Agent 太多，责任太少)
- [4.3 拼凑式 prompt：老式火锅底料](#4.3 拼凑式 prompt：老式火锅底料)
- [4.4 评估体系：人人满分，公司凉了](#4.4 评估体系：人人满分，公司凉了)
- [4.5 延迟：多一层，慢一截](#4.5 延迟：多一层，慢一截)
- [5. 渐进式呈现：把工具说明书改成按需取用](#5. 渐进式呈现：把工具说明书改成按需取用)
-
- [5.1 Tool Use 和 Tool Search，别傻傻分不清](#5.1 Tool Use 和 Tool Search，别傻傻分不清)
- [6. 为什么这套东西能成立](#6. 为什么这套东西能成立)
-
- [6.1 共享上下文：记性好，才能当侦探](#6.1 共享上下文：记性好，才能当侦探)
- [6.2 渐进式披露：文档删 80%，程序员哭了](#6.2 渐进式披露：文档删 80%，程序员哭了)
- [6.3 模型变强：关不掉思考的同事](#6.3 模型变强：关不掉思考的同事)
- [7. 单循环到底长啥样](#7. 单循环到底长啥样)
-
- [7.1 核心机制：单一上下文 + 开放式工具循环](#7.1 核心机制：单一上下文 + 开放式工具循环)
- [7.2 职责四分法：模型、Skills、Tools、代码](#7.2 职责四分法：模型、Skills、Tools、代码)
- [8. 怎么把一群 subagent 塞进 Main Loop](#8. 怎么把一群 subagent 塞进 Main Loop)
-
- [8.1 第一步：先建评估集](#8.1 第一步：先建评估集)
- [8.2 第二步：逐步减少，别跳楼](#8.2 第二步：逐步减少，别跳楼)
- [8.3 先合并耦合最深的](#8.3 先合并耦合最深的)
- [8.4 subagent 降级当工具](#8.4 subagent 降级当工具)
- [8.5 用 Skills 和工具接手](#8.5 用 Skills 和工具接手)
- [9. 一个 Agent，怎么让多个团队一起 Build](#9. 一个 Agent，怎么让多个团队一起 Build)
- 结尾：别学了，真的
P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程传送门http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。
前言
最近我把 Agent 架构从里到外重新研究了一遍。研究完就一个感受：我年初刚学会的多 Agent，现在好像要进博物馆了。
都说学海无涯苦作舟，结果这海是苦海，我好不容易游到岸边，发现岸是一块浮冰。
1. 先说清楚，subagent 到底是个啥
你可以把它理解成：一个主 Agent 带着一群小弟，每个小弟都有自己的小脑瓜（独立的上下文窗口）、自己的工具包、自己的办事流程，上面还有一个协调者（Coordinator）统一派活。
是不是特别像公司？
没错，越看越像。CPU 的线程和子线程大概就是这么演化出来的。我怀疑再过几年，AI 架构师的简历上都会写一行：熟练调度多线程 Agent，精通 Agent 死锁排查。
2. 但是，风向已经变了
现在最流行的玩法是：单个 Agent + Main Loop。
翻译成人话：不养一群小弟了，改养一个超级大脑，让它在自己的大循环里转圈圈，边想边干、边干边改主意。
有人拿一堆企业级部署横评过：一个带多个 Skills 的单个 Agent，质量上能打赢"万能提示词方案"，也能打赢 subagent 方案，成本更低、延迟更短。
这感觉就像，你雇了十个实习生分头干活，最后发现还不如一个老员工揣着小本本自己跑一趟。
3. 康威定律：系统是公司的照妖镜
什么是康威定律？说人话就是：你公司有客服部、物流部、售后退款部，你一做 Agent，脑子里第一反应一定是------客服 Agent、物流 Agent、退款 Agent，再找个编排器当领导，在上面统筹调度。
这是把公司的组织架构图，原封不动地打印到了系统架构上。表面分工严密、各司其职，实际上嘛......
问题在于，大模型之间传话，可不像人传话那么灵活。你让 Agent A 把话捎给 Agent B，每转述一次，细节就丢一点，跟小时候玩的传声筒一模一样------传到最后，"帮我查个物流"能变成"把公司卖了"。
哦对，这个现象有个学名，叫 Telephone Game。不知道谁起的，反正起名字的人挺有生活。
4. 企业搭 Agent 的五大翻车姿势
4.1 上下文管理：快递丢了
Agent 之间到底交换哪些上下文，得你亲自定。定完你会发现，上下文在传输过程中会神秘失踪------跟快递一样，查无此件。
4.2 subagent 泛滥：Agent 太多，责任太少
每个团队都部署自己的 subagent，攒着攒着，公司里就有了几百个功能重叠的 Agent，还没有统一标准。出事了找谁？找不到。
大家异口同声：不是我干的，是我的 Agent 干的。建议各大公司成立一个"Agent 甩锅责任认定委员会"。
4.3 拼凑式 prompt：老式火锅底料
每个团队都在系统提示词里加一句自己的要求。加到最后，这个 prompt 跟老式火锅底料一样------什么味儿都有，就是没有统一的味儿。
4.4 评估体系：人人满分，公司凉了
每个人都给自己那个 subagent 定制评估指标，指标只优化自己的小地盘。管理层最后看到的，是一堆被稀释的、各自为政的分数。
翻译：每个人都在给自己的考试划重点，最后成绩单人人满分，公司业务凉了。
4.5 延迟：多一层，慢一截
多 Agent 架构每多一层，延迟就往上跳一截。有人对比过：多 Agent 框架和单 Agent + Loop，后者快了差不多两倍。
那句话怎么说来着：多一个环节，多一份拖沓；多一个 Agent，多一秒磨叽。
5. 渐进式呈现：把工具说明书改成按需取用
以前的做法，是把所有工具的完整定义、参数、JSON Schema 一股脑全塞给模型。工具少还行，工具一多，光说明书就能占掉大量 Token。
有说法是：系统提示词里暴露超过 30 到 50 个工具定义之后，模型选工具就开始瞎了。
你想想，给你一本五百页的工具说明书，让你马上挑一个用，你也瞎。人比模型强的地方在于：你会先翻目录。
5.1 Tool Use 和 Tool Search，别傻傻分不清
这两个词长得像，干的事完全不一样。Tool Use 是"用"，Tool Search 是"找"。
正确姿势是搭配着来：起步只放 Skills 的简短描述和少量常用工具，模型发现自己要查订单了，先通过 Tool Search 搜一下工具目录，命中之后再把完整参数规格加载进来，最后用 Tool Use 真正调用。
翻译：以前是把整个工具箱抬到你面前，现在是"你要螺丝刀？行，我给你找。"
python
# 单循环 + 渐进式工具的简化示意（伪代码，仅供理解）
def main_loop(task):
ctx = load_skill_descriptions() # 起步只加载 Skills 的简短描述
plan = model.plan(ctx, task) # 第一步：模型先写执行计划
while plan.has_next():
calls = plan.next_batch() # 一批并行工具调用
results = harness.parallel_call(calls) # 并发执行，返回原始数据
ctx.extend(results) # 原始结果直接进上下文
spec = tool_search(ctx, plan.next_tool()) # 需要时才搜工具
if spec:
ctx.extend(load_full_schema(spec)) # 命中后加载完整定义
ctx.extend(tool_call(spec, plan.next_tool())) # Tool Use 照常调用
plan = model.replan(ctx) # 模型看结果，动态改计划
if model.should_ask_user(ctx): # 自主决定下一步
ctx.extend(ask_user())
return model.final_answer(ctx) # 出结论，或触发预算阈值（最大轮数/Token）终止6. 为什么这套东西能成立
6.1 共享上下文：记性好，才能当侦探
长期跑下来的 Agent，得记得住自己前面干过啥。如果每一步的结果都留在同一个上下文里，模型就能把线索串起来。
这跟人一样------记性差的人，破不了案，也当不了 Agent。
6.2 渐进式披露：文档删 80%，程序员哭了
不用把所有东西一次性塞进系统提示词，需要啥加载啥。据说有家的编码 Agent，系统提示词因此瘦身了 80% 以上。
80%！你见过哪个程序员愿意把自己写的文档删掉 80%？删了那都是钱啊。
6.3 模型变强：关不掉思考的同事
以前模型弱，才需要外面搭一堆框架帮忙拿主意。现在模型强了，从某个版本开始，你连它的思考过程都关不掉。
它干着干着还会主动汇报："我检查了一下，上一步干得不错，我继续了。"
你说这是 Agent，还是你那个特别爱写日报的同事？
7. 单循环到底长啥样
7.1 核心机制：单一上下文 + 开放式工具循环
整个 Loop 的运转逻辑，拆开看就五步：
第一步，模型接到任务，先在自己的上下文里写下执行计划------注意，是写给自己看的，像你出门前列的购物清单；
第二步，批量并行调用工具，外层 Harness 负责并发调 API，把最原始的数据原样丢回来------注意是原样，不许总结，一总结就失真；
第三步，模型看着返回的数据，发现情况不对，立刻就地改计划。这是质变：以前计划是外面写死的，现在写计划和干活的是同一个脑子；
第四步，模型自己决定下一步是继续调工具、追问用户，还是直接给结论；
第五步，给出最终答案，或者触发外部预算阈值（最大轮数、Token 预算），循环终止。要质检的话，后面再挂一个轻量的 Goal/Verifier 程序核一下。
说白了，这就是一个自驱力极强、拥有全局视野的超级大脑在独立解决问题，旁边不再需要任何协调者指手画脚。
指手画脚的人，都失业了。
7.2 职责四分法：模型、Skills、Tools、代码
这一节看得我直拍大腿。四大组件各司其职，彻底解耦：
模型 = 全局大脑。定战略、看反馈、改计划。以前靠外层代码写死的那些规则目录，全删。
Skills = 领域业务 SOP。把原来每个 subagent 的提示词里沉淀的业务规范、执行顺序提炼出来，平时只露个简介，模型需要时再加载全文。跟简历一样：先看标题，有兴趣再约面。
Tools = 能力接口。所有真正的读写操作、数据检索都封装成工具，而且硬性规则和安全防线全部下沉到工具内部。模型越权？工具直接返回拦截提示，模型自己就懂了，根本不用外挂一个权限审核 Agent。
传统代码 = 脏活累活。别迷信模型干一切。正则提取订单号、构造 API Payload、解析流式响应，这些确定性的搬砖活儿，交给普通代码又快又省。
说白了：模型动脑，Skills 给方法，Tools 动手，代码搬砖。
这分工，比我见过的大部分公司都清晰。
8. 怎么把一群 subagent 塞进 Main Loop
8.1 第一步：先建评估集
动手之前，先搭一套端到端评估集，看看哪些 subagent 值得整合。核心团队维护共享测评集，Skills 的负责团队各自维护小评估集。
有个坑：Agent 的回答没法 100% 重现，不好评估。办法是记录关键事件的时间戳，等日重现之后再做评估。
翻译：先把现场保护起来，等"案发"了再破案。
8.2 第二步：逐步减少，别跳楼
把 subagent 整合成工具和 Skills：合并一些领域内的、改成工具调用、或者直接用 Skills 替代。
注意，是逐步，不是一步到位。一步到位的那不叫迁移，叫跳楼。
8.3 先合并耦合最深的
先把交互最频繁的 subagent 合并------就是那种你输出给我、我输出给你的耦合型选手，合并成一个 Domain Agent。
打个比方：两个互相递话的 Agent，跟公司里两个互相递锅的部门一样，迟早并成一个，锅就没了。
8.4 subagent 降级当工具
如果你的 subagent 适合当工具，就把它降级成 Main Loop 的一个工具，让主 Agent 掌控对话过程。只有真需要 subagent 跟用户面对面的时候，才让它出来接管。
不过要注意几个坑：每个专用 Agent 都有自己的提示词、上下文、团队和评估指标；每次调用返回的都是损耗过的摘要；每次调用都是一个嵌套的模型运行循环，延迟会涨。
翻译：把它当外包团队用可以，但外包团队多了，你还是要承担管理成本。
8.5 用 Skills 和工具接手
把 subagent 的提示词转成 Skills，API 调用转成 MCP 工具，然后对比有它和没它两种情况的表现，再决定留不留。
对比的时候别只看总分，要看看具体是哪些任务的结果发生了反转。有人就遇到过：把某个 subagent 整合进来，延迟降了，结果原本跑得通的流程反而坏了------主 Agent 查订单的时候，居然没问物流配送日期，直接自己拍板回答了。
这叫什么？这叫盲目自信。跟新来的员工一样，能力很强，但流程不熟，上来就敢自己签合同。
9. 一个 Agent，怎么让多个团队一起 Build
诀窍是把所有权从 Agent 层面下沉到 Skills 和工具层面：
MCP 工具：需要执行操作、从系统读实时数据、以固定格式返回结果，用工具；
Skills：需要按照某个团队的业务步骤、规则和判断标准来做，用 Skills；
知识库：放参考资料，让模型通过搜索或查询工具获取。
说白了：Tools 管执行，Skills 管方法，知识库存资料，核心团队管最后有没有把事做成。
各管一摊，互不抢功。这配置，建议写进企业管理学教材。
结尾：别学了，真的
研究完这一整套，我的感受是：AI 架构的更新速度，已经快过我的学习速度了。年初我还在研究多 Agent，年中它就过时了，年底我连"过时"这个词都要现查。
以后的决策会越来越内化到模型里，外部框架越来越薄，到最后可能就只剩模型能力的差异。到时候，AI 架构师这个岗位大概就剩一个职责了------给模型写提示词。
写得好，是 AI 产品经理；写得不好，是 AI 段子手。
反正都是写字的，差别不大。
P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 传送门http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。