1. 从agency-agents这个名字说起一个被低估的架构命题第一次看到agency-agents这个组合词我的直觉是这大概率不是某个具体产品的名字而是一类系统设计模式的代号。拆开来看agency指向的是代理能力或者说能动性而agents则是复数形态的执行单元。合在一起它描述的是一种由多个具备自主决策能力的代理单元协同完成任务的系统架构。这个方向在最近一两年变得非常热。原因不复杂单一大模型再强它也是一个单点。你让它同时处理需求理解、任务拆解、工具调用、结果校验、异常回滚它很容易在某个环节掉链子。而如果把一个复杂流程拆成多个各司其职的代理每个代理只负责自己最擅长的那一段整体成功率反而会显著提升。这就是agency-agents这类架构最朴素的价值主张。我最初接触这个思路是在一个自动化内容处理的场景里。当时的需求是从一堆非结构化的原始素材中提取关键信息然后按照不同模板生成多份格式各异的输出。如果用一个单体流程硬扛代码会变得极其臃肿任何一个环节出问题都要从头排查。后来我把它拆成了采集代理—清洗代理—结构化代理—生成代理—校验代理五个独立单元每个单元有自己的输入输出契约整个系统的可维护性和可观测性立刻上了一个台阶。所以这篇内容我想聊的不是某个具体的框架或库而是当你决定用多代理架构来解决问题时真正需要想清楚的几件事代理怎么划分、通信怎么做、状态怎么管、失败怎么兜底、以及最关键的——什么时候你根本不该用多代理。这些经验大部分是我在实际项目中踩过坑之后总结出来的有些和主流教程的说法不太一样但我觉得更接近真实情况。适合读这篇的人已经了解基本的代理概念、正在考虑或已经开始搭建多代理系统的开发者被单体流程的复杂度折磨、想找一条更清晰路径的工程师以及单纯对这个方向好奇、想知道多代理到底是不是银弹的技术决策者。2. 代理划分的粒度为什么一个代理干一件事经常是错的2.1 粒度太细带来的隐性成本几乎所有讲多代理架构的文章都会告诉你职责单一原则一个代理只做一件事。这话本身没错但很多人把它执行成了一个代理只做一步操作结果就是代理数量爆炸。我见过一个项目光是读取文件和解析文件内容就拆成了两个代理中间还要经过一次消息传递。这种拆法在纸面上看起来很架构清晰实际跑起来问题一大堆。首先是通信开销。每多一个代理就多一次输入输出的序列化与反序列化多一次上下文传递多一次错误可能发生的节点。当代理数量从3个涨到10个系统的端到端延迟可能翻好几倍而其中大部分时间花在了代理之间互相等待上而不是真正的计算。其次是调试难度。代理越多链路越长当最终结果不对时你很难快速定位是哪个环节出了问题。单体流程至少你还能打断点一步步跟多代理系统里每个代理可能是异步的、可能在不同进程甚至不同机器上排查成本指数级上升。我的经验法则是如果一个代理的输入输出可以用一句话描述清楚且它内部不包含任何需要判断的分支逻辑那它大概率不应该是一个独立代理而应该是一个函数。代理的价值在于决策不在于执行。读取文件是执行判断这个文件该用哪种解析策略才是决策。2.2 一个实用的划分检验清单在实际操作中我用下面这几个问题来判断一个代理该不该独立存在检验问题如果答案是否如果答案是是这个单元是否需要独立做判断或选择合并到调用方可以考虑独立它的输出是否会被多个下游复用合并独立价值高它是否需要独立的失败重试策略合并独立它是否需要独立的资源配额或权限合并独立它的执行时间是否与其他单元差异巨大合并独立便于并行这张表的核心逻辑是代理的边界应该由决策边界和资源边界决定而不是由操作步骤决定。一个代理可以内部执行很多步操作只要这些操作服务于同一个决策目标。2.3 从真实场景看划分的取舍举个具体例子。假设你要做一个自动整理会议纪要的系统。直觉上可能会拆成录音转文字代理、摘要提取代理、待办事项识别代理、格式化输出代理。这个拆法看起来合理但实际跑起来你会发现摘要提取和待办事项识别其实共享同一份上下文理解拆开之后两边都要重新读一遍全文反而浪费。我后来改成的划分是理解代理负责转写后的语义理解输出结构化的会议要素、决策代理基于理解结果判断哪些是摘要、哪些是待办、优先级如何、呈现代理负责按不同格式输出。三个代理每个都有明确的决策职责通信次数从原来的至少4次降到2次整体延迟下降了将近40%。注意代理划分没有标准答案但有一个可靠的判断标准——如果你发现两个代理总是在传递几乎相同的数据那它们大概率应该合并。3. 代理间通信消息传递的三种模式与选型逻辑3.1 直接调用、消息队列与共享状态多代理系统里代理之间怎么说话是绕不开的问题。目前主流有三种模式各有各的适用场景。第一种是直接调用代理A直接调用代理B的接口同步等待结果。这种方式最简单链路清晰适合代理数量少、调用关系固定的场景。缺点是耦合度高A必须知道B的存在和接口而且B挂了A也会跟着挂。第二种是消息队列代理之间通过队列异步通信A把消息丢进队列就不管了B从队列里取。这种方式解耦彻底天然支持削峰填谷和失败重试。缺点是引入了额外的中间件依赖而且调试时很难追踪一条消息的完整流转路径。第三种是共享状态所有代理读写同一份状态存储比如一个共享的上下文对象或数据库代理之间不直接通信而是通过状态的变化来感知彼此。这种方式在需要多个代理协作处理同一份数据的场景下非常自然但并发控制会变得复杂。我自己的选型逻辑是这样的代理数量少于5个、调用关系是线性的直接用调用别过度设计。代理需要并行执行、或者某个代理可能耗时很长上消息队列。多个代理需要反复读写同一份数据共享状态但一定要加锁或版本控制。3.2 上下文传递的最小必要原则不管用哪种通信模式有一个坑我踩过不止一次上下文传递得太多。刚开始做的时候我习惯把整个对话历史、所有中间结果都塞给下一个代理觉得信息越多判断越准。结果就是token消耗爆炸而且代理经常被无关信息干扰做出奇怪的判断。后来我定了一条规矩每个代理只接收它做出当前决策所必需的最小上下文。具体怎么做在定义代理接口时明确列出它需要哪些字段多余的字段一律不传。如果某个代理确实需要历史信息那就单独设计一个上下文摘要字段由上游代理负责压缩后再传递。这个原则带来的好处是双重的一是成本可控二是代理的判断质量反而更高因为干扰信息少了。实测下来把上下文从全量传递改成最小必要之后某个代理的决策准确率从七成出头提升到了接近九成。3.3 通信协议的设计细节如果你决定用消息传递有几个细节值得提前想清楚消息格式建议用结构化格式如JSON并且给每条消息加上trace_id方便全链路追踪。超时策略每个代理调用都要设超时不能无限等待。超时时间根据下游代理的P99耗时来定一般设成P99的1.5倍。幂等性消息可能重复投递代理的处理逻辑要保证幂等否则会出现重复执行的问题。死信处理处理失败的消息不能直接丢掉要进死信队列方便后续人工介入或自动重试。这些细节在系统规模小的时候感觉不到痛一旦代理数量上去、流量上来没有这些机制会非常难受。4. 状态管理与失败兜底多代理系统真正的难点4.1 状态该放在哪里多代理系统最让人头疼的不是代理本身而是状态。一个任务从开始到结束中间会产生大量中间状态已经完成了哪些步骤、当前进行到哪、每个代理的输出是什么、有没有出现异常。这些状态放在哪里直接决定了系统的可靠性和可恢复性。常见的做法有三种第一种是状态存在内存里整个任务的生命周期在一个进程内完成。这种方式最快但进程一挂状态就全没了适合短任务、可重跑的场景。第二种是状态持久化到数据库每个代理完成一步就写一次库。这种方式可靠进程挂了可以从上次的状态恢复但写库有开销而且并发控制要做好。第三种是状态存在专门的状态机服务里由状态机来驱动整个流程的流转。这种方式最规范但引入了额外的复杂度适合流程复杂、状态转换多的场景。我的建议是如果任务执行时间超过30秒或者涉及外部不可控的调用一定要做状态持久化。否则一旦中途失败前面所有的计算都白费了。持久化的粒度不用太细按代理级别存就行每个代理完成后存一次快照。4.2 失败重试的三种策略代理失败是常态关键是怎么处理。我总结下来有三种策略对应不同的失败类型瞬时失败比如网络抖动、下游限流直接重试配合指数退避。重试次数一般设3次退避时间从1秒开始翻倍。逻辑失败比如输入数据格式不对、代理判断出错重试没用需要把失败信息回传给上游由上游决定是修正输入还是走降级路径。系统性失败比如依赖的服务整体不可用不要重试直接快速失败触发告警等依赖恢复后再重新调度。这里有个容易忽略的点重试必须配合幂等。如果一个代理的操作不是幂等的重试会导致重复执行可能产生脏数据。所以在设计代理时要么保证操作幂等要么在重试前先做一次状态检查。4.3 降级与兜底的设计再好的系统也会有代理彻底失败的时候这时候需要有兜底方案。兜底不是简单地返回一个错误而是尽可能给用户一个可用的结果。举个例子在一个多代理的内容生成系统里如果润色代理挂了系统可以降级为直接返回初稿代理的输出虽然质量差一点但至少用户拿到了东西。如果校验代理挂了可以跳过校验直接输出但要在结果里标注未经校验。这种降级设计的关键是提前定义好每个代理的可跳过性和降级替代方案。哪些代理是必须成功的哪些是可以跳过的哪些失败了可以用简化版替代这些要在设计阶段就想清楚而不是等出问题了临时决定。提示降级方案一定要在测试环境验证过否则真到线上出问题时降级路径本身可能也是坏的。5. 什么时候你不该用多代理架构5.1 单体流程能搞定的事别硬拆这是我最想强调的一点。多代理架构不是免费的它带来了通信开销、调试复杂度、状态管理成本、部署复杂度。如果你的任务本身逻辑简单、步骤固定、不需要动态决策那用一个单体流程完全够用硬拆成多代理只会让事情变复杂。我见过不少项目本来一个函数就能解决的问题非要拆成三四个代理结果代码量翻了三倍性能还下降了。这种为了架构而架构的做法在实际工程中是要付出代价的。判断标准很简单如果你的流程里没有任何需要根据情况选择不同路径的决策点那就不需要多代理。多代理的核心价值在于处理不确定性如果流程是确定的用确定性的代码去实现就好。5.2 延迟敏感的场景要慎重多代理系统的端到端延迟天然比单体高因为多了代理间的通信和调度。如果你的场景对延迟极其敏感比如实时交互那多代理可能不是好选择或者你需要把代理数量压到最低并且用最快的通信方式。我做过一个对比测试同一个任务单体实现平均耗时200毫秒拆成三个代理后平均耗时450毫秒其中超过一半的时间花在了代理间的数据传递和调度上。对于实时场景来说这个差距是致命的。5.3 团队能力与运维成本的现实考量多代理系统的运维复杂度远高于单体应用。你需要考虑代理的部署和扩缩容、消息队列的运维、分布式追踪、状态存储的高可用等等。如果团队没有相应的运维能力贸然上多代理架构很可能会陷入系统天天出问题但没人能修的困境。我的建议是先从单体开始当单体确实遇到了瓶颈比如复杂度失控、无法并行、无法独立扩缩容再考虑拆成多代理。演进式的架构比一开始就设计一个复杂的多代理系统要稳妥得多。6. 我在实际项目里踩过的几个坑6.1 代理之间的责任真空有一次我设计了一个流程代理A负责判断这个任务该走哪条路径然后把任务分发给代理B或代理C。结果上线后发现有一类边界情况A判断不出来既没分给B也没分给C任务就卡在那里了。这就是典型的责任真空——每个代理都觉得自己不用负责的情况最后没人负责。解决办法是在流程设计时明确每个决策点的默认路径。如果A判断不出来必须有一个默认的兜底路径而不是让任务悬空。这个兜底路径可以是交给人工处理也可以是走最保守的那条分支但绝不能是什么都不做。6.2 上下文污染导致的连锁误判另一个坑是上下文污染。某个代理在处理时往共享上下文里写了一个错误的中间结果下游代理基于这个错误结果继续处理错误被逐级放大最后输出完全离谱。而因为每个代理单独看都逻辑正确排查起来非常困难。后来我加了一条规则每个代理写入共享上下文的数据必须经过格式和范围校验。比如一个表示置信度的字段必须在0到1之间超出范围直接拒绝写入并告警。这个校验成本很低但能拦住大部分污染问题。6.3 代理版本升级的兼容性问题当系统跑了一段时间你需要升级某个代理的逻辑时兼容性问题就来了。新版本的代理可能改变了输入输出的格式而上下游代理还是老版本直接就对不上了。我的做法是代理接口必须版本化升级时先让新旧版本并行运行一段时间确认没问题再下线老版本。同时代理之间的消息格式要向后兼容新增字段可以但不能删除或改变已有字段的含义。这些看起来是小事但在系统演进过程中能省掉大量麻烦。7. 一套可落地的最小多代理骨架聊了这么多理念和坑最后给一套我自己常用的最小骨架方便你快速起步。这套骨架不依赖任何特定框架用最朴素的方式实现你可以根据自己的技术栈替换其中的组件。核心思路是一个调度器 若干代理 一个状态存储。调度器负责按顺序或按条件调用代理代理只负责处理自己的那部分逻辑状态存储负责持久化中间结果。# 伪代码示意展示核心结构 class Agent: def __init__(self, name, input_schema, output_schema): self.name name self.input_schema input_schema self.output_schema output_schema def run(self, context): # 1. 校验输入 self.validate_input(context) # 2. 执行核心逻辑 result self.process(context) # 3. 校验输出 self.validate_output(result) return result class Orchestrator: def __init__(self, agents, state_store): self.agents agents self.state_store state_store def execute(self, task): context self.state_store.load(task.id) or {} for agent in self.agents: try: result agent.run(context) context.update(result) self.state_store.save(task.id, context) except TransientError: # 重试逻辑 self.retry(agent, context) except FatalError: # 降级或告警 self.handle_failure(agent, context) return context这套骨架的关键设计点每个代理有明确的输入输出契约、状态每步持久化、失败有分类处理。你可以在此基础上逐步增加消息队列、并行执行、分布式追踪等能力但核心结构不用变。实际用下来这套骨架能覆盖大部分中小规模的多代理场景。等你的代理数量超过十个、或者需要跨机器部署时再考虑引入更重的框架也不迟。架构是演进出来的不是一开始就设计出来的。
