这两年的Agent江湖变化快得让人跟不上。去年大家还在晒单个Agent能写一篇文章、能调一个API今年风向已经变了——智能体从单任务走向多任务协作几乎成了标配。不少人跑来问我Agent到底该怎么从一个模型包打天下进化成一群智能体分工合作这是第十九章我想聊透的事。这一篇我会从一个做过多年Agent落地的工程视角出发把单Agent真正的瓶颈在哪里、主流框架流派如何选、多Agent协作到底靠哪几根支柱撑起来、以及实际改造时踩过的坑全部摊开。适合正在做Agent开发、准备把单Agent升级成多Agent系统、或者被长任务稳定性折磨过的人看。我的态度一直很明确Agent不是拿来表演的是拿来干活的。1. 独行侠困局单任务Agent为什么撑不起复杂需求1.1 上下文窗口与工具路的单兵上限单个Agent看起来什么都能干本质上是一套模型上下文工具的组合。演示的时候你给它一个清晰任务它能顺着做下来一旦任务链条变长第一个问题就是上下文窗口不够用。搜索返回20条网页摘要代码仓扫描出来50个文件再加上系统提示词、历史消息Token很快逼近上限。你只能做截断一截断早期结论就丢了后面全凭模型瞎猜。这种失忆式推断在Demo里不常见但在真实任务里几乎是常态。第二个问题是工具调用链。单Agent要为每个步骤自己选工具、自己纠错今天让它写SQL明天画架构图后天发邮件它很容易在执行到一半把工具用串。不是说模型能力不行而是链路太长时什么都会一点恰恰意味着每一步都可能错一点而且错误会累积。搜索跑偏一个关键词后续分析全站在错误的地基上代码生成漏了一个依赖后面的验证步骤全都白做。单Agent像独行侠单挑能力再强也架不住复杂局面里的多方拉扯。1.2 角色杂糅与确定性缺失单Agent最常见的写法是在系统提示词里塞一堆角色你是一个资深的搜索分析师同时是代码专家也是报告撰写者请完成以下任务。这个思路看起来省事实际干活时会发现角色之间互相打架要求严谨搜索时它忍不住给建议要求只输出JSON时它非要解释两句。本质上一个上下文里同时存在多个互相冲突的目标模型无法稳定地在不同落点之间切换。更致命的是单Agent流程的输出完全是概率性的。每一步都有波动哪怕提示词写得再精细也很难保证两个分支任务在同一组生成参数下都收敛到正确路径。我见过很多团队把希望全押在换更大更强的模型上结果模型升级之后任务确实变顺了一点但复杂链路的失败率还是高得令人头疼。这时候你就会理解复杂任务需要的不是更强的单体模型而是一个可以把不确定性拆解掉、再用确定性框架管起来的系统。1.3 从压榨单个模型到拆分复杂度所以我一直建议判断一个需求要不要上多Agent协作不是看它听起来够不够智能而是看任务本身是否具备两个特征一是子任务之间可以清晰切分边界二是每个子任务需要不同上下文、不同工具、不同评价标准。具备这两条拆成多Agent收益远大于成本不具备硬拆只会多出一堆通信和协调开销。说到底多Agent协作的价值是把复杂度从提示词转移到了系统架构每个Agent只承担一个职责上下文短且专注工具列表收敛模型出错的概率被隔离在单点不再一路传导到最终结果。这就像把一个复杂的江湖局面交给一个团队而不是指望某个大侠一个人把文案、账房、情报、后援全包圆。对比维度单Agent多Agent协作上下文压力长期任务容易爆窗口只能粗暴截断每个Agent只用自己需要的上下文配合记忆压缩职责边界角色混杂在同一个上下文里互相干扰每个Agent一个职责系统提示词清晰独立故障隔离一步错全链路崩单点出错可重试、可降级、可单独修复可测试性整条链路黑盒难以定位问题每个节点可单独测试审计留痕清晰成本单次Token少但失败重跑次数多单次Token偏多但稳定性和可复用性更好适用场景短任务、单工具、低风险长链路、多工具、需要不同专业视角2. 江湖门派主流Agent框架与架构流派取样2.1 编排派把流程写成图编排派的代表是LangGraph、Temporal、Prefect这类工作流引擎在Agent层的变体。核心思想是把系统Flow显式建模为有向图节点是Agent或工具边是状态转移。好处是可测试、可审计每一步都留痕代价是流程变化时必须改代码。LangGraph的StateGraph是典型做法共享State节点消费和更新State边的条件判断决定下一步。适合业务路径比较固定的生产系统。很多生产级Agent应用表面上是多Agent协作底层其实是一张精心设计的图。你会发现Agent架构这个词被用得泛滥但真正落到代码层面编排派仍然是生产环境里最稳妥的起点。2.2 星主派Planner统一调度星主派对应AutoGen、CrewAI的Crew/Manager模式。一个中心化Planner接收总任务拆解后分发给若干Worker AgentWorker做完把结果回报再由Planner汇总或继续派活。好处是灵活可以处理没有固定路径的长尾任务坏处是Planner本身成为瓶颈。大家熟知的多AI协作产品很大一部分是星主派实现。如果规划得当它最贴近人的管理直觉但要注意Token消耗Planner每次都要汇总所有Worker的回报上下文增长极快成本往往超出预期。我见过一个团队做市场调研AgentPlanner把二十个搜索结果全部塞进记忆结果第二次对话还没开始上下文窗口就满了。2.3 自由结社派去中心化消息传递自由结社派以A2A协议、消息总线/黑板模式、ACL通信为典型。Agent之间通过消息中间件自由发消息没有中央调度者类似江湖人士自行合纵连横。这种模式适合探索性场景比如一群Agent围绕一个开放问题辩论或协同创造但它的可预测性很差你不知道谁先发言、谁回应了谁、最后怎么收敛。除非你有很强的通信协议和终止条件设计否则不建议直接用在生产链路里。我见过很多团队一开始用自由结社觉得很酷上线后第一周就被不可复现的结果折磨最后乖乖换回编排派。自由结社不是不能用而是它要求你把通信协议设计得像法律条文一样严密这对大多数业务团队来说投入产出比不高。2.4 代理骨架Harness、Agent与Skill的边界聊框架绕不开harness和agent区别这个问题。用大白话讲Harness是跑Agent的那个外壳/运行时负责循环控制、IO路由、权限管理、工具注册Agent本身是模型加上下文加技能的组合Skill则是可以被Agent调用的武功秘籍。比如Claude Agent Skills就是用一个SKILL.md的Markdown目录把某一类操作的完整说明、示例、模板固化下来让Agent遇到同类任务时不用从零摸索。三者各管一层Harness管机制Agent管决策Skill管能力。理解了这层边界你会发现很多框架都是在Harness层较劲。有的用Python写有的用Rust写。Rust写Agent运行时确实有优势内存占用低、并发能力强、打包成单文件方便分发一些机器人场景比如OpenClaw加ROS给Agent装身体也偏好这类高效运行时但除非你要做底层Runner或嵌入式部署业务层用Python/TS框架就够了没必要为了性能把所有Agent都用Rust重写一遍。框架/模式协作风格适合场景上手难度主要风险LangGraph编排派显式图生产链路、有固定流程中流程变更要改代码AutoGen/CrewAI星主派中心调度长尾任务、探索性研究低Planner上下文膨胀、成本高A2A消息总线自由结社派开放讨论、协议严格高难以收敛、可复现性差Claude Agent Skills技能封装层配合Harness使用低依赖宿主Agent能力Rust Agent Runner底层运行时高并发、嵌入式高开发效率低、生态薄3. 协作心法任务编排、通信协议与共享记忆三板斧3.1 任务编排把分活变成确定性DAG多Agent协作的第一步不是写代码而是先把活分清楚。我习惯先把任务拆成DAG有向无环图每个节点有明确的输入输出定义再考虑哪些节点由Agent完成哪些节点用确定性程序完成。为什么强调确定性因为模型天生随机如果任务分派也随机整个系统就变成掷骰子。正确做法是不确定的部分交给Agent节点确定性的规则如数据校验、格式转换、超时重试用普通代码写死在流程里。这样可以显著降低整体波动。一个典型的DAG包括入口校验节点、多个并行执行节点、聚合节点、审核节点。入口校验节点负责判断任务意图能不能做、合不合规并行执行节点把独立子任务分发给不同Agent聚合节点把结果合并审核节点做质量把关。这套结构一旦搭好就相当于给江湖定了规矩谁负责哪一段出了事找谁。3.2 通信协议结构化消息优于自由对话Agent之间交换信息最容易犯的错是让它们像人一样聊天我把结果发你了你看看。自由文本看似灵活实则难解析、难过滤、难追踪。我建议所有跨Agent通信都用结构化消息至少包含sender、receiver、task_id、trace_id、message_type、payload、timestamp设计成JSON Schema强制每个Agent输出符合Schema的内容这样下游Agent能直接解析而不需要LLM再去猜。消息传递层面可以用共享State或消息队列但无论哪种都要有超时、重试、死信处理。另外要控制通信频率两个Agent互相发几十轮消息除了消耗Token还容易陷入循环必须在消息计数上设上限。我的经验是一次完整任务里Agent间消息最好控制在10轮以内。超过这个数大概率是边界没切干净或者任务拆分的粒度不对。3.3 共享记忆协作系统的内存与外存Agent记忆是今年热词多Agent协作里记忆问题会被放大。单Agent记忆至少还有上下文兜底多Agent的记忆必须分清三层工作记忆、长期记忆、临时交互状态。工作记忆就是当前任务的共享State放中间结果这一层要尽量精简避免无脑堆历史。长期记忆放向量数据库比如pgvector、Milvus、Chroma每个Agent按需检索检索时机要和任务切片对齐。临时交互状态则记录Agent之间最近几轮的消息摘要防止每次通信都要翻聊天记录。我常用的做法是每完成一个大节点做一次记忆压缩把早期原文替换成一段结构化摘要释放上下文空间同时防止信息过载导致模型捡了芝麻丢西瓜。这一步很土但极其有效。你不做记忆压缩十个Agent串起来之后光是互相传递的历史摘要就能撑爆上下文窗口。4. 实战拆解把一个单Agent改造成多Agent协作系统4.1 改造案例技术调研报告助手假设我们原来有一个单Agent任务是输入一个技术主题输出一份带观点、带来源的调研报告。单Agent版大致是一个大提示词让模型自己搜索、自己分析、自己写报告。跑Demo没问题长期用就发现两个老毛病第一搜索和写作混在一起写作者经常把来源编得不像话第二一个环节出错比如搜索超时整个任务就报废。改造方案我拆成五个节点Guard意图校验、Researcher搜索并整理事实、Analyst基于事实做分析、Writer生成报告、Reviewer质量审核。每个节点只负责一件事工具也各不相同。Researcher只能调搜索API不带写文件权限Analyst只看Researcher传过来的结构化事实不自己搜Writer只负责把分析结果变成可读文本不编来源Reviewer专门检查报告里有没有事实性错误和来源缺失。4.2 代码示例用LangGraph搭五Agent流水线用LangGraph写这个流水线代码可以很简洁。首先定义State结构然后注册各个节点再把节点连接起来from typing import TypedDict, List from langgraph.graph import StateGraph, START, END class ReportState(TypedDict): task: str fact_records: List[dict] # Researcher 的产出 analysis: str # Analyst 的产出 report: str # Writer 的产出 review_result: str # Reviewer 的结论 def guard_node(state: ReportState) - dict: # 校验任务意图比如是否涉及敏感词、是否属于可执行范围 # 如果不通过直接抛错或返回终止信号 return {task: state[task]} def researcher_node(state: ReportState) - dict: # 调用搜索工具把结果清洗成 fact_records # 注意这里只调用搜索工具不调用其他工具 return {fact_records: search_and_extract(state[task])} def analyst_node(state: ReportState) - dict: # 基于 fact_records 做分析输出 analysis return {analysis: analyze_facts(state[fact_records])} def writer_node(state: ReportState) - dict: # 基于 analysis 生成报告严格禁止编造来源 return {report: write_report(state[analysis])} def reviewer_node(state: ReportState) - dict: # 检查报告是否满足要求不通过则要求 writer 重写 return {review_result: review(state[report])} graph StateGraph(ReportState) graph.add_node(guard, guard_node) graph.add_node(researcher, researcher_node) graph.add_node(analyst, analyst_node) graph.add_node(writer, writer_node) graph.add_node(reviewer, reviewer_node) graph.add_edge(START, guard) graph.add_edge(guard, researcher) graph.add_edge(researcher, analyst) graph.add_edge(analyst, writer) graph.add_edge(writer, reviewer) graph.add_edge(reviewer, END) app graph.compile()这段代码里每个节点都是纯函数输入输出通过State显式传递。Reviewer节点如果发现报告不合格可以从图层面加一条reviewer回writer的循环边但要同时加最大重写次数避免死循环。实际生产里我还会把每个节点的输出都打上trace_id写入日志存储方便事后回放。4.3 先跑通再优化状态持久化与并发控制很多人问Agent怎么扛并发这要分开看。Coordination层多并发比如同时十个用户各自跑一条Agent链路这时候要关注进程/线程隔离、每个链路的独立State、API限流单链路内部也有并发比如Researcher可以并行起多个搜索子Agent。代码层面我给API调用打一层并发控制用asyncio.Semaphore限制同时进行的模型请求避免触发上游限流。每条链路独立保存State用Checkpointer定期落盘这样进程重启或超时后可以恢复。还要给每个Agent设max_steps上限防止一个错误在节点间来回传递导致死循环。这步我踩过坑某次Planner一直把自己提出的计划推倒重来整整空转了一个小时账单吓人。设置max_steps之后这类问题才算彻底治住。状态持久化和并发控制一定要在系统设计时留好位置。如果你把所有Agent状态都放在内存里一旦服务重启正在执行的任务全部丢失用户只能重新发起请求。生产环境里我建议把State落数据库每个节点处理完就持久化一次。虽然慢一点但稳定性和可恢复性提升是巨大的。5. 兜底护栏多Agent协作的安全、并发与人工介入5.1 权限最小化每个Agent只配一把剑多Agent系统安全第一原则是权限最小化。每个Agent的工具列表要根据职责收敛Researcher只给搜索工具不带写文件权限Writer只给文本生成不给删库权限涉及对外发消息、改配置、写数据库的节点单独设置高危通道。工具注册中心里面对每个工具可以做白名单和参数校验。比如搜索工具只允许访问预设的URL白名单生成工具不允许输入特殊系统指令。还要关注Agent之间的信息泄漏A Agent读到的数据不经筛选就传给B Agent可能把敏感内容漏出去。所以每个通信Schema要定义数据最小字段能传结论就不传原文。权限最小化的核心思路是每个Agent手里只拿完成自己职责所必需的最小权限不给多余的能力自然也就不存在误操作删库这种大事故。5.2 审核节点与人工介入兜底我强烈建议在关键出口或高风险动作前面加Human-in-the-loop节点Agent生成完内容后先进入Pending状态由人工或规则系统审核通过才放行。用自动化规则关键词、敏感字段、异常分数做第一道闸拿不准的再让人看。不要指望模型自省能拦住一切。多Agent交互中最大的风险是级联幻觉A Agent编了一个结论B Agent基于这个结论继续推理C Agent再引用B整个链条看似逻辑自洽实际源头就是错的。审核节点放在每个链路段落末端比放在最终出口更有效但成本更高需要取舍。我的做法是高风险节点涉及外部写入、法律相关、财务相关强制人工审核低风险节点用规则自动放行。这样既保证安全又不至于让人工介入拖慢整个流程。5.3 可观测性追踪与回放是安全的最后防线多Agent系统里的故障几乎都是分布式的没有可观测性根本无法排查。我上线前会强制要求每个链路贯穿一个trace_id每轮消息、每个节点输出、每次状态变更都记录审计日志甚至把关键节点的输入输出摘要落到存储里。出问题的时候能按trace_id回放完整执行过程。Agent安全不能光靠别让它干坏事更重要是它能干坏事的时候你能看到它在干什么。把Agent运行时的日志、工具调用、模型响应完整记录回放机制就是你的后悔药。尤其是权限事故如果连日志都没有事后连追责和修复都无从谈起。多Agent系统的链路比单Agent长排查问题的时间成本也成倍增加好的可观测性设计能帮你把排查时间从小时级降到分钟级。6. 经验沉淀我在多Agent项目里的避坑清单6.1 我踩过的坑按危害排序坑根因解决办法Agent间互相传错误结论整条链崩节点没有单测错误没有被及时拦截每个节点加输入校验和输出校验Planner上下文撑爆Token费用失控没有做记忆压缩中间结果越攒越多每个大节点结束做一次结构化摘要Agent循环调用空转烧钱没有设max_steps上限每个Agent加最大步数限制超时熔断工具权限过大误删数据工具列表没有按职责收敛权限最小化高危操作单独设人工审核并发请求导致API限流没有做并发控制asyncio.Semaphore限流退避重试进程重启任务全部丢失State只存在内存里Checkpointer定期落盘数据库持久化消息格式不统一下游解析失败Agent自由文本通信强制JSON Schema结构化消息这些坑我基本都踩过一遍。尤其是第一个Agent间互相传错误结论在早期开发时几乎天天遇到。后来我把每个节点的输入输出都做了严格校验错误率才真正降下来。6.2 给刚开始做多Agent协作的人的三条建议第一不要一上来就堆Agent。很多场景单Agent加精心设计的Skill加Harness就够先跑通再拆。单Agent都跑不稳的项目拆成多Agent只会更乱因为你多了一堆协调问题要面对。第二每个Agent的系统提示词只写一个职责评价标准要可度量。比如Researcher的评价标准是返回事实条数、来源可用率Writer的评价标准是引用完整度、格式通过率越具体越好。第三把不确定性留在模型内把确定性收归代码。能用规则做的事情不要交给模型能用代码校验的不要交给提示词。多Agent协作不是把几个模型凑在一起就能焕发智能。它背后是工程手段的刻意收敛谁能调用什么工具、消息按什么格式流动、中间状态放哪、错了谁兜底这些都要在代码里写清楚而不是靠模型临场发挥。Agent爆发带来的真正变化不是出现了多少智能体而是人们开始意识到智能不是模型独角戏而是系统协作的涌现。我在实际项目里的体会是当你把单Agent改造成多Agent协作后最先感受到的不是变聪明了而是变可控了。这个变化才是它真正值得投入的原因。