最近agency-agents这个词在AI应用圈的热度有点出乎我意料GitHub上相关的项目收藏量涨得很快社区里讨论也从这是什么慢慢转向怎么落地。我用两周时间把一个基于多智能体协作的小项目从头跑到了尾过程中反复改了好几版架构踩了不少坑今天把整套思考和实践记录整理出来给准备入坑或者已经在做的朋友一点参考。agents anywhere这个说法我也挺喜欢——它代表的是一种趋势智能体不该困在单个对话框里而是应该像团队一样渗透到各个业务流程中。而agency-agents正是实现这种形态的一条具体路径让多个agent像一家微型公司那样分工协作有负责拆任务的老板有各司其职的员工最后把成果汇总给用户。这篇文章适合两类人看一是想在项目里引入多智能体架构但还没理清思路的开发者二是已经在用单agent做自动化、但发现复杂任务根本搞不定的朋友。我会从架构选型讲到核心实现再把我踩过的坑一个不落地倒出来。1. 为什么突然都在聊agency-agents单agent的边界与多agent的价值1.1 单agent做复杂任务时的三个老毛病先说个很现实的场景你让一个agent帮你调研一下某个行业输出一份包含市场规模、头部玩家、技术趋势和投资建议的报告。单agent会怎么做它会尝试在一个上下文窗口里完成所有事。问题很快就来了。第一个毛病是上下文长度失控。这种多段式任务中间涉及大量网页抓取、数据整理、推理总结每一步的中间结果都要占token长一点的调研任务跑到一半就可能把上下文窗口塞满后面的推理质量断崖式下跌。第二个毛病是工具切换混乱。agent既要调搜索又要读文档还要写代码分析数据工具一多模型在这些工具之间来回切换时经常迷路表现为重复调用同一个工具、忘记已经拿到的信息、突然开始执行和当前任务无关的动作。第三个毛病最要命——目标漂移。任务太长太复杂agent做到后面往往已经忘了最初的长尾目标产出的结果跟用户实际想要的东西越跑越偏。我拿单agent跑复杂调研任务的时候经常得到一份看起来完整、但仔细一看每个板块都很浅的报告。它不是不能做而是单线程的注意力和受限的上下文窗口决定了它只能做到这个程度。这就好比一个人既当项目经理又当调研员又当分析师最后一定会顾此失彼。1.2 Agency模式的本质把一个人干所有事变成一个团队干所有事agency-agents的核心思路特别简单既然单agent有这些瓶颈那就别让它一个人扛而是按照真实公司运作的方式把任务拆开。一个典型的agency架构是这样的有一个老板agentSupervisor/Planner它不直接干活主要负责三件事——听懂用户的模糊需求、把需求拆成明确的子任务、把子任务分配给合适的员工agent。然后有一批员工agentWorker每个员工只负责一个垂直领域比如有的专门做信息检索有的专门做数据分析有的专门做内容撰写有的专门做代码编写。员工之间不需要互相知道对方在干嘛它们只需要向老板汇报结果。老板收集完所有结果后负责汇总、校验、整合成最终产出。这个架构的好处很直接。每个agent的上下文窗口只需要装自己那个子任务相关的信息不相关的统统不加载上下文被污染的概率大幅下降每个agent的系统提示词可以做得非常聚焦不需要把几十条规则塞进一个agent的脑子里某个员工agent崩溃或者输出质量差时老板可以直接把它换掉重跑不需要整个任务从头再来。这种分工带来的容错性、聚焦性和可扩展性是单agent怎么调prompt都换不来的。1.3 不是所有场景都适合agency别为了架构而架构我必须先泼一盆冷水。agency模式不是银弹它解决的问题是复杂多步骤任务但它本身也带来了新的开销。最大的开销是token成本翻倍因为中间多了一层老板agent的规划、汇总、调度再加上每个员工agent都要独立跑一轮整体消耗可能比单agent高出2到3倍如果任务拆得不好5倍都可能。另外多agent协作有一个非常典型的可靠性问题错误会在层级之间累积。员工输出一个错误结果老板没有识别出来直接整合进最终报告比单agent犯错还难发现因为老板默认员工是可靠的。我自己实测下来如果一个任务用单agent能在两次工具调用内完成那完全没有必要上agency——杀鸡用牛刀纯属浪费。agency适合的场景有这些共性任务有明确的阶段划分调研、分析、产出各阶段独立、子任务之间不需要频繁共享中间状态、整体任务量超过单个上下文窗口的承受能力、或者天然需要多个不同风格的产出维度。2. 核心架构拆解老板agent和员工agent是怎么协作的2.1 老板agent的真正职责不是发命令是做好任务建模老板agent其实是整个系统里最难设计的一环。很多人一开始以为老板就是把用户的话换个说法丢给员工结果跑起来发现效果一塌糊涂员工根本不知道要做什么或者做出来的东西对不上。我做了几轮迭代之后发现老板agent真正的核心能力是任务建模——它要能判断当前这个请求需要哪些能力一个能力对应到哪个员工agent这个子任务要达成什么验收标准才算完成子任务之间有没有依赖关系。举个例子用户说帮我做一份社区团购行业的竞品分析。合格的老板agent应该输出这样的计划员工A检索员搜集社区团购头部玩家名单、各家最新融资情况和业务覆盖城市员工B数据员整理各家的用户规模、GMV、SKU数量等核心数据输出结构化表格员工C分析师基于A和B的产出分析竞争格局、各家差异化策略员工D内容员将前三步整合成一份完整报告按受众输出任务拆到这种粒度员工agent执行起来就很明确了。我在实现里给老板agent加了一个硬性要求先输出计划JSON经过校验之后才允许进入派发阶段。计划里每个子任务必须包含四个字段任务ID、执行员工、任务描述、验收标准。这样做的原因是让老板agent的规划行为变成可检查的中间产物而不是黑盒里一闪而过的想法。如果老板拆出来的任务员工根本接不住你至少能知道问题出在规划阶段还是执行阶段。2.2 员工agent的配置思路垂直、极简、带验收意识员工agent恰好相反它的设计原则是越笨越好、越专注越好。因为员工不需要全局视野它只需要在收到任务后调用自己那几个工具把任务结果回传给老板。我在实践里给每个员工agent配了四样东西独立的系统提示词、独立的工具集、独立的输出模板、独立的验收条件。比方说检索员系统提示词就一句话你是信息检索专员只负责搜索并返回与查询相关的事实不进行推测不添加评论。工具集只给它搜索API和网页抓取工具不给它代码执行器——不给它用不着的工具能从根上防止它越权发挥。员工还有一个被我加进去但一开始并没有的设计验收意识。我要求员工在回传结果之前必须用一行自检说明我依据什么数据来源得出了这个结论。这一行自检内容不是为了写进最终报告而是给老板agent做质量判断用的线索。有了这个字段老板在面对员工结果时就不是盲目信任而是能带着审校的眼光去整合这其实是用极低的成本换来了多agent系统里非常宝贵的可校验性。2.3 上下文的传递策略隔离与汇总并重多agent协作里最容易踩雷的还有一个点信息怎么传。我第一版实现得很粗暴——把上一轮所有员工的结果全部塞进下一轮所有员工的上下文里结果没跑几次就遇到了严重的上下文污染检索员在分析数据、分析师在去搜索资料各agent的焦点完全被带偏了。后来我换成了黑板架构的变体员工与员工之间不直接通信所有信息只通过老板转达而且每个员工只接收和自己任务相关的信息片段。具体来说老板在派发任务时会附带一个context字段这个字段只包含该员工执行任务所需的最小信息集。比如分析师只需要知道这是汇总表格、这是检索记录原文完全不需要知道检索员中途搜了哪些失败的查询词。在执行完成后员工回传给老板的结果也会被要求说人话——我定义了一种结构化汇报格式包含结果正文、数据来源、可信度自评、以及无法完成/部分完成的诚实标记。这个设计让老板在汇总阶段能只读汇报结构不用再去翻原文大大减轻了老板的上下文负担也让整个链路清晰可控。2.4 记忆与状态管理任务级状态和会话级记忆要分开整个系统跑了一段时间后我发现记忆这个问题不能忽视。如果系统只服务一次性任务那么每次只需要任务级状态管理就够了。但如果你希望这个agency能有延续性——比如同一个用户上一次让它做过数据分析这次再让它做行业调研它能记得用户偏好简洁风格——那你就需要会话级记忆。我现在的做法是把记忆分成两层。任务上下文存在一个独立的临时存储里任务是啥、拆了哪些子任务、每个子任务的输入输出是什么任务结束后就清理会话记忆只存用户偏好、历史主题摘要、以及用户对历史产出的修改意见摘要。每次新任务开始时老板agent会先读会话记忆但不会把整段历史都塞给员工而是把历史摘要转化为用户的交付偏好说明附在计划里。这样既不浪费token又能让系统显得记得你。3. 从零实操一个能跑起来的agency-agents项目骨架3.1 框架选型为什么我最后选了自研轻量编排市面上已经有几个现成的多agent框架比如CrewAI、AutoGen、LangGraph还有我关注到的ChatAgency这类专门做双层代理的项目。我的看法是如果你的目标只是体验一下多agent协作直接拿CrewAI或者ChatAgency跑个demo是最快的路径但如果你像我一样准备把它接进自己的业务系统那自己写一层轻量的编排逻辑反而更可控。理由有三个一是框架封装度越高黑盒就越多出了问题你连日志都看不懂二是业务系统里的工具往往是内部API通用框架对接起来反而要多写一堆适配代码三是token成本管控、任务超时重试、质量校验这些逻辑框架里要么没有要么做得很浅最后还是要自己写。我的做法是用LangGraph做底层的agent执行引擎但自己实现了任务拆解、派发、汇总这层编排逻辑。这样既借了LangGraph在agent节点间转移控制的成熟能力又把业务逻辑掌握在自己手里。3.2 核心实现三个关键节点加一条消息路由我把整个系统抽象成三个节点planner_node规划节点、worker_node执行节点、summarizer_node汇总节点外加一个消息路由函数决定每个循环里该调用哪个节点。下面这段是核心骨架的简化版去掉了具体的业务细节保留了关键逻辑from typing import TypedDict, Optional, List import json class AgentTask(TypedDict): task_id: str worker_name: str description: str acceptance_criteria: str context: Optional[str] class WorkerResult(TypedDict): task_id: str worker_name: str output: str sources: List[str] confidence: str # high / medium / low is_completed: bool # 是否完整完成 note: Optional[str] # 未完成时的说明 class AgencyState(TypedDict): user_request: str plan: Optional[List[AgentTask]] results: dict # task_id - WorkerResult final_report: Optional[str] def planner_node(state: AgencyState) - AgencyState: 老板agent解析用户请求产出任务计划。 内部调用LLM并强制其返回JSON数组每个元素包含 task_id/worker_name/description/acceptance_criteria prompt build_planner_prompt(state[user_request], available_workers()) plan_response call_llm(prompt, response_formatjson) plan_data json.loads(plan_response) # 关键校验检查计划是否合法 validate_plan(plan_data) state[plan] plan_data return state def worker_node(state: AgencyState, task: AgentTask) - WorkerResult: 员工agent执行单个子任务返回结构化结果。 每个worker是独立的agent实例只加载自己的工具集和system prompt。 worker get_worker(task[worker_name]) result worker.execute( descriptiontask[description], acceptance_criteriatask[acceptance_criteria], contexttask.get(context, ) ) return result def route(state: AgencyState): # 首先检查是否已经有计划 if not state.get(plan): return planner # 把计划里未完成的任务逐个派发给worker pending [t for t in state[plan] if t[task_id] not in state[results]] if pending: return worker # 全部完成后进入汇总 return summarizer这段代码是典型的状态机结构每个循环里根据当前状态决定下一步动作。注意validate_plan这一步——在规划阶段就校验计划格式而不是等到执行阶段才发现老板agent输出的东西员工接不住这一行省下的调试时间比什么都值。3.3 worker的注册机制与prompt模板员工agent的注册我用了一个简单的配置类注册表每个worker就是一个类实例里面装上自己的name、description老板agent用这个来判断该把任务发给谁、system_prompt、tools和max_retries。下面是一个示例配置结构WORKER_REGISTRY [ { name: researcher, description: 适合信息检索、资料收集类任务, system_prompt: 你是信息检索专员。只返回基于事实的内容标注信息来源不进行推测。, tools: [web_search, web_fetch], max_retries: 3, }, { name: analyst, description: 适合数据分析、市场信号识别类任务, system_prompt: 你是数据分析师。基于给定的数据和事实进行逻辑分析输出可追溯的结论和证据链。, tools: [data_reader, code_interpreter], max_retries: 2, }, { name: writer, description: 适合报告撰写、内容润色类任务, system_prompt: 你是内容撰写专员。负责将给定材料整合为结构清晰的专业文档遵循用户的交付要求。, tools: [text_formatter], max_retries: 2, }, ]这里有一个非常关键的细节description字段不是给人看的是给老板agent看的。老板agent正是在读了每个worker的description之后才能判断这个子任务应该发给谁。所以description的措辞必须强调适合什么类型的任务而不是一堆华丽的能力形容词。我见过一个团队把员工agent的description写成高级数据科学专家、精通机器学习、NLP、CV结果老板什么都往它那里派因为它看起来什么都能干——这完全违背了垂直分工的初衷。3.4 老板agent的规划prompt模板老板agent的表现完全取决于规划prompt怎么写。我的经验是纯文本说明自由发挥不如给定格式模板加few-shot示例。下面贴一个我实际使用的精简版prompt模板你是任务规划专员。你的职责是将用户的复杂需求拆解为清晰、可执行的子任务。 可用的员工agent及其专长如下 {worker_descriptions} 要求 1. 每个子任务必须能由一个员工独立完成 2. 子任务之间尽量无依赖如果存在依赖请在task_id中用依赖字段体现 3. 每个子任务需要明确验收标准让员工知道自己做到什么程度算完成 4. 最多拆分不超过5个子任务超过5个说明你的拆分粒度没有掌握好请合并同类项 必须严格输出以下JSON数组格式不要输出其它内容 [ {{ task_id: t1, worker_name: researcher, description: ……, acceptance_criteria: ……, context_prompt: 附带给员工的精简上下文不得超过200字 }} ]这里我特别想强调的是最多5个子任务这个约束。一开始我没加老板agent经常恨不得拆出十几个子任务每个子任务又小又碎token开销爆炸、任务间依赖混乱、执行时间拉得巨长。加了数量上限之后规划质量反而明显提升——因为它必须做合并和取舍而合并的过程其实就是对任务本质的再思考。这个约束是免费的性能优化。4. 踩坑实录一周时间踩出来的六个坑个个都是钱买来的教训4.1 坑一任务拆解粒度过细导致token爆炸这是我第一版系统跑起来后遇到的最早、也是最贵的坑。当时我拆一个竞品分析任务老板一口气拆了12个子任务包括搜索公司A的融资情况搜索公司A的团队背景搜索公司A的产品功能……每个子任务都要独立调用一次LLM、独立消费一轮token跑完整个流程费用表出来我人傻了比单agent高出了6倍多。后来我做了两个调整一是像上面那样限制子任务数量上限5个二是增加了合并策略——老板在规划时先想哪些信息可以在一次fetch里同时拿到把相关查询合并成一个子任务。调整之后同样的任务拆成4个子任务成本从6倍降到2.3倍效果反而更好因为老板的精力不需要消耗在十几个毫无难度的琐碎查询上。记住一句话任务拆解不只是拆得越细越好而是要拆到每个子任务有独立交付价值为止。4.2 坑二员工之间隐蔽的无限循环多agent系统里最让人崩溃的bug就是循环依赖。员工A的输出被当成员工B的输入员工B的输出又被当成员工A的输入两边互相纠缠整个流程变成一个无底洞。我遇到的实际情况是老板让检索员找社区团购行业报告,检索员返回了一些资料摘要资料摘要被丢给分析师分析师说信息不足需要补充搜索;然后老板又把分析师的需求转回检索员检索员又去搜新一轮……如果我没在循环外层设上限这轮循环能无限进行下去。解决方案是在编排层加两层防线。第一层是全局迭代上限max_iterations通常设为5到8轮达到上限强制进入汇总阶段第二层是worker间通信白名单员工的结果只能回到老板绝对不允许一个员工直接触发另一个员工。很多框架允许这种自由通信听起来很灵活但实践里没有严格的壁垒控制就一定会在某个边界出乱子。4.3 坑三员工交付幻觉说自己完成了但实际内容是垃圾这个问题比模型幻觉更隐性。在多agent架构里员工知道老板不会全面检查自己的输出部分模型在执行时会倾向于敷衍了事——输出格式是对的、长度是够的但内容深度明显不够。我给检索员设了标注来源的自检字段之后发现了更搞笑的情况它标注的来源链接实际上是打不开的、或者链接内容和正文对不上。我针对这个做了两个改善。一个在员工侧增加结果自评机制要求员工明确对验收标准逐条打勾标注每个条件是否满足而不是笼统说完成。另一个在老板侧增加汇总抽查规则老板在整合阶段必须对每个员工结果用一行话评价是否采信及其原因。这个采信意见看起来增加了token开销但它让老板从甩手掌柜变成了审稿人整个系统的输出质量有了质的提升。对于高风险任务我还会在汇总后单独跑一个独立评审agent只负责找茬不负责产出——它的实践证明独立评审找出的问题比老板自己复查找到的多一倍以上。4.4 坑四老板的上下文被汇报轰炸淹没老板agent虽然不执行具体任务但它要接收所有员工的结果。任务一多员工汇报一长老板的上下文还是会爆。我第一次跑完整流程的时候老板输入里光员工汇报就有2万字规划结果的质量肉眼可见地下降——它已经没精力去判断哪个结果可信变成了简单的拼接机器。解法我前面提过精简汇报模板。我在员工回传结构里强制要求正文不超过500字的摘要详细内容通过引用标记附带。更重要的一招是老板汇总时不需要看完整原文只需要看每个员工的output摘要 confidence is_completed note四个字段。这四个字段已经足够老板判断采信与否了。原文数据怎么办存起来在最终报告里作为引用来源附上给用户看不给老板看。4.5 坑五模型选型一刀切贵模型干杂活最初我给老板和所有员工都用同一个高强度大模型原因是省事。但成本报表出来之后发现大头根本不是老板的规划也不是分析师的推理而是检索员执行的那一堆简单搜索整理——每个搜索都走最贵的模型性价比极低。我现在是这样搭配的老板规划、最终汇总用强推理模型数据清洗、格式整理类员工用性价比模型分析师这种需要一定逻辑推理的用中档模型。成本大概省了40%多而且输出质量没有明显下降。需要注意一点不要让规划模型指派的模型运行在与规划模型完全不同的指令遵循能力下也就是说如果员工模型的指令遵循能力太弱老板输出的复杂任务描述它根本执行不了。如果遇到这个情况优先给员工配置更高档的模型而不是简化老板的任务描述——简化任务描述的代价是任务质量下降。4.6 坑六调试时无法复盘黑盒里发生了什么要可视化多agent系统调试的难度是指数级上升的因为你有多个智能体在跑任何一个环节出错都会波及后续。第一版我只有最终产出中间过程全在日志里淹没出了问题根本没法定位是规划错了、执行错了、还是整合错了。后来我加了一个trace日志功能每个节点执行前后的状态快照、每次LLM调用的输入输出、每个员工的完整决策轨迹都会以结构化的JSON写入trace文件。关键的一次bug排查中我通过trace发现是员工在第四步收到了一个来源标记错误的上下文直接导致后续所有分析建立在错误假设上——这种问题不靠trace复盘靠肉眼根本找不出来。如果你在用LangGraph它本身就自带state的逐步可视化能力建议善用。如果是自研的编排层至少要把state的每次变更快照存下来再配一个简易的Web界面把状态流转画出来。调试多agent的时间至少有一半应该花在看trace上这句话我是在被坑了整整两天之后才完全理解的。5. 一些掏心窝的实操建议从两个agent起步把agents anywhere落到自己的业务里5.1 设计上的建议先把流程图画在纸上再写代码做多agent系统最大的忌讳是直接开写。我第二次重构的时候先把整个业务流程用流程图在纸上画了一遍——用户输入到最终输出的所有环节、每个环节用到哪个工具、哪个员工、什么条件下跳转。画完才发现两个之前想不到的问题一是任务链路里有两个冗余环节可以合并二是有一个环节根本不需要agent一个普通的规则判断就够了。不要为了用agent而用agent。业务里凡是能用if-else写清楚的逻辑就用if-else凡是能用一个函数算出来的就别让LLM参与。agent只用在真正需要语义理解、需要灵活决策、需要从非结构化信息中提取结论的地方。这样不仅省钱整个系统的稳定性也会上一个大台阶。5.2 迭代上的建议两个员工起步跑通再加不要一上来就设计8个员工agent分工协作那基本注定要翻车。我建议从最简单的两步开始一个规划agent加一个执行agent。哪怕只这样你已经能处理很多单agent搞不定的任务了——规划agent负责拆解和判断执行agent负责具体干活。跑通之后再把执行agent拆成两个垂直方向的员工逐步扩展。每加一个员工先加一个边角料任务试试水不要在核心流程上直接启用新员工等测试通过再逐步承担重要任务。5.3 把agents anywhere落地的思路从高频重复流程里找场景最后聊聊agents anywhere这个说法。我的理解是它不是让你把agent塞进所有产品功能里而是让你找到那些高频、重复、有明确规则但又不完全规则的流程把它们agent化。以我们自己的实践为例我们已经跑起来的场景有舆情日报生成检索员收集信息、分析师提炼要点、内容员输出简报每天早上自动跑一轮客服工单分类与初答工单语义理解、历史案例检索、初步回复起草三件事分别由三个轻量agent协作完成人工客服只需要做最后验收会议纪要与行动项抽取语音转录后由分析agent提取决议、拆行动项、指派负责人再由复核agent对照原稿检查是否有遗漏每个场景都有一个共同点决策链路长、需要的信息维度多、但步骤之间是顺序解耦的。这种场景天然适合agency架构也是agent真正能释放效用的地方。我个人在这些实验里最大的体会是agency-agents不只是一个技术架构它其实逼着你重新梳理业务流程——你必须搞清楚每一步到底在做什么、哪个角色负责、什么算完成才能真正把一套可用的多agent系统搭起来。这个过程本身就很有价值。如果让我提一条最想让后来者记住的经验那就是先把业务拆清楚再谈技术实现先让两个agent跑起来再让十个agent跑得稳。按这个顺序来多agent这条路没那么玄乎。
