1. Agent-Reach到底解决什么问题当Agent各自为战时系统就变成了灾难先讲一个我自己的故障现场。之前团队做了一个多Agent客服系统模块拆得很漂亮意图识别Agent、订单查询Agent、售后策略Agent、情绪安抚Agent加起来七个各自的Prompt和工具调用都调得不错。结果一联调灾难来了——用户问了一句“我上周买的那个东西能退吗”意图识别Agent判断是售后问题把任务丢给了售后策略Agent售后策略Agent去查订单发现订单接口需要订单号但订单号只有订单查询Agent手里有。于是售后策略Agent带着半截上下文去问订单查询Agent订单查询Agent查完回来售后策略Agent已经忘了用户问的是什么。最后用户等了三分钟收到一句“对不起我还在为您查询”。这不是个别Agent写得不好这是系统级的失败。后来我复盘那段时间踩的所有坑发现一个问题反复出现单体应用时代我们处理的是模块间的函数调用调用关系是编译期就确定的但在多Agent系统里每个Agent都是独立决策的“活人”你没法像调函数一样调Agent。你需要一套机制让Agent之间能互相找到、能正确接力、能在超时后优雅降级——这就是Agent-Reach这个项目最初的动机。Agent-Reach本质上是一个Agent间可触达协调层它不做业务推理不抢Agent的活它只解决三件事让请求能路由到正确的Agent、让Agent之间能安全地传递控制权、让失败和超时不会拖垮整条链路。打个比方如果每个Agent是一家公司里的部门Agent-Reach就是那个把需求转给正确部门、并盯着工期和交付质量的PMO办公室。为什么说“能互相找到”这件事在Agent场景下比想象中难因为Agent不是APIAPI有固定的路径和参数签名Agent接受的是自然语言或半结构化意图同一个请求换个说法可能就路由到了错误的Agent。而且Agent之间的依赖往往是动态的A处理到一半发现需要B的能力这种“中途找人”在没有基建的情况下只能靠Prompt硬编结果就是Agent的Prompt越写越长、越来越脆弱最终变成一堆互相矛盾的规则。这大概就是对Agent-Reach最朴素的需求定义它不是某个Agent的升级而是Agent之间那层缺失的基础设施。接下来的内容我会把我从设计到落地这套协调层的完整思路、代码结构、压测结果和踩坑记录都展开说希望对正在被多Agent协同折磨的团队有点帮助。2. Agent-Reach的设计取舍为什么放弃“全广播”和“中心化编排”两条看似简单的路多Agent路由和协作市面上大致有三条路全广播、中心化编排、去中心化自协商。Agent-Reach选的是第三条的改良版但我在做技术选型时前两条路都完整地试过也踩出了非常具体的结论这里直接讲清楚。2.1 全广播最直观但成本是指数级的最早我做的方案很粗暴用户请求进来复制十份同时发给所有Agent谁觉得自己能处理谁就回话谁先回话谁拿控制权。听起来很像“抢答器”很分布式很优雅实际上线就被打脸。第一Token成本不可控。七个Agent同时收到完整上下文每个Agent都要做一次完整推理即使最终只有一个人回答用户其他六个的推理成本也白花了。实测下来同样的请求量全广播方案的LLM调用费用是单路由方案的4到7倍这还是用便宜模型测的。如果你的Agent背后接的是长上下文模型这个倍数会更难看。第二一致性灾难。多个Agent同时认为自己“能处理”的场景极其常见尤其是意图边界模糊的请求。售后策略Agent和订单查询Agent经常同时抢单结果用户收到两条互相矛盾的回答。你得再写一个“最终答案选择器”那这个选择器本质上又变成了一个中心化决策节点绕了一圈回到原点。第三不可控的连带效应。一个Agent抢到单之后还要依赖另一个Agent但被依赖的Agent可能在处理别的请求没人知道它什么时候空闲整条链路卡死。所以全广播只适合一种场景Agent数量极少两三个、互相之间没有依赖、而且实时性要求不高。作为通用方案它在成本和可观测性上都是灾难。2.2 中心化编排能解决问题但把系统变成了“一个会说话的超级单体”既然全广播不行那就回到老路写一个总控AgentOrchestrator它负责理解用户意图决定调哪个Agent然后把结果拼装返回。这条路是大多数团队的默认选择也确实能跑通Demo。但跑到生产环境你会发现一个恶心的本质问题总控Agent的Prompt会无限膨胀。每接入一个新Agent你都要在主Prompt里补充这个Agent的能力描述、触发条件、输入输出格式、错误处理规则。当你接入到第八个Agent时总控Prompt已经超过6000个token而总控Agent在长Prompt下的意图漂移问题开始频繁出现——它经常把“查天气”的请求路由到“写文案”的Agent上因为Prompt后面的规则覆盖了前面的规则。另外一个隐蔽问题是总控Agent本身也是一个LLM它也会出错也会超时。一旦总控Agent不可用整个系统全挂它成了最高优先级的单点故障。而且中心化编排意味着所有的请求都要经过一条长链路链路越长单次请求的时延就越难看。我实测过三层嵌套总控调子Agent子Agent再调子Agent的情况下单轮对话的P95延迟能到8秒以上用户早走了。2.3 去中心化自协商理论上很美工程上是一场灾难那让Agent之间自己商量呢A发现自己处理不了主动去问BB再决定接不接。这消除了单点也减少了不必要的路由跳数。但你很快会发现让两个LLM互相协商等于让两个即兴发挥的演员对戏剧本是不存在的。实测中遇到最离谱的一次售后Agent问订单Agent“这个用户的订单号是多少”订单Agent反问“这个用户是谁”售后Agent又把用户ID发过去订单Agent说“我没有查过这个ID”两个Agent陷入了鸡同鸭讲的死循环直到我手动kill掉任务。本质原因是LLM之间没有共享的状态协议它们基于自然语言的协商必然会出现上下文断裂、误解、重复确认。还有一个工程噩梦没有中心协调者你根本无法知道一个请求此刻被哪个Agent卡住了排查一次死循环要翻十几个Agent的日志。可观测性变为负数。2.4 Agent-Reach的最终形态语义路由 显式状态机 有限自协商基于这三轮的踩坑Agent-Reach最终收敛为三层结构既不走全广播也不走严格中心化而是取了一个折中点接入层加语义路由器请求进来先经过一个轻量路由模型识别意图只把请求转给最相关的1到2个候选Agent。这个路由器可以是小型Finetune模型也可以是带函数调用能力的大模型关键在于它的上下文窗口只吃“Agent目录”而不吃业务数据因此Prompt短、意图准、时延可控。协调层持有显式状态机每个请求在系统中是一个状态对象从PENDING到ROUTED到WAIT_DEPENDENCY到COMPLETED或FAILED每个Agent在处理前和处理后都要回调状态机。Agent之间不直接对话而是通过状态机传递“控制权”。这解决了自协商的无状态死循环问题。Agent之间允许有限制地对齐如果AgentA真的需要AgentB的数据A不是直接给B发消息而是向状态机注册一个依赖事件状态机负责唤醒B并把A的已有处理结果作为上下文传给B。这个“通过中间人转交”的设计既保留了去中心化的灵活性又避免了两边对牛弹琴。这套设计我跑了三个月路由准确率从全广播时代的不可控升到了96.3%用500条人工标注请求评测端到端P95延迟从8秒降到了2.8秒。下面我拆开讲每个模块的具体实现和参数设计。3. 核心模块拆解语义路由器、依赖事件总线、状态机的代码级实现3.1 语义路由器用“Agent能力目录”而非业务规则做匹配语义路由器是整个系统第一道门也是最容易被人写歪的一个模块。很多人会把路由规则写死在代码里比如“如果用户消息包含/退货//就route到/售后Agent/”。这种关键词路由在测试集上能看一到真实用户五花八门的表达就失灵。Agent-Reach的做法是维护一份Agent能力目录每个Agent在注册时提交三样东西name、description、input_contract。其中description是用纯自然语言描述这个Agent能干什么、不能干什么、什么情况应该拒单。一份快递售后的Agent能力描述是这样写的name: after_sales description: | 处理用户的退款、退货、换货请求。 能查询订单状态、发起退款流程、预估退款到账时间。 如果用户只是想了解物流进度请拒绝并建议路由到 logistics_agent。 如果用户对商品本身有质量投诉但不想退款请拒绝并建议路由到 complaint_agent。 input_contract: required_fields: - user_id - order_id optional_fields: - product_sku - refund_reason路由器本身只做一件事把用户请求和目录里所有Agent的description一起丢给模型让模型输出一个或两个最合适的Agent名字。不要给模型太多上下文不要给它用户的历史聊天记录越少越好因为上下文越长路由抖动越明显。实测参数上是这样调的我对比了不同模型做路由的效果列表如下路由模型意图准确率平均时延成本/千次关键词规则61.8%0ms极低GPT-4o-mini 能力目录94.6%380ms约0.8美元Finetune的6B小模型96.3%90ms约0.05美元全广播多Agent抢答无法稳定评估2-5s约3.5美元关键词规则61.8%的准确率意味着每三次请求就路由错一次日志里全是Agent的拒单回调根本没法用。Finetune的6B小模型效果最好但如果你的团队没有算法资源直接用带函数调用的商业模型做路由也够用毕竟路由器不处理业务只做分流成本可控。这里有一个重要的工程技巧路由结果一定要返回置信度和候选列表。不要只返回一个Agent名字要返回类似[{name: after_sales, confidence: 0.82}, {name: complaint, confidence: 0.31}]的结构。当最高置信度低于0.6时Router不直接把请求转给Agent而是先转给一个澄清Agent去追问用户比如“你是想退货还是只投诉”。这一步能把最终路由准确率提升至少3个百分点。3.2 依赖事件总线让Agent之间通过“挂件-订阅”协作而不是互相喊话Agent-Reach里最关键的一个模块是依赖事件总线它解决的是“中途发现需要另一个Agent帮助”的场景。最初的自协商方案里AgentA发现需要AgentB的数据时会直接给B发消息。现在我彻底禁止了这种做法所有的跨Agent协助都走总线。流程是这样的1. AgentA 处理请求到一半发现自己缺order_id。 2. AgentA 不停止当前任务而是把已积累的上下文快照summarized_context发布到总线的依赖事件区声明我在等待 order_id来源候选是 logistics_agent。 3. 总线检查 order_id 只能由 logistics_agent 产出于是将 AgentA 的状态置为 WAIT_DEPENDENCY并把 AgentA 的上下文快照作为输入唤醒 logistics_agent。 4. logistics_agent 查完订单将 order_id 写回总线。 5. 总线将 order_id 合并回 AgentA 的上下文把 AgentA 状态置为 READY唤醒 AgentA 继续处理。这个模式本质上是把“Agent间调用”变成了“Agent与总线间的事件交互”两边不直接对话自然就不会出现鸡同鸭讲。代码实现上我推荐用一个轻量级的Redis Stream或者SQLite单机版作为事件存储层配一个简单的事件回调。核心订单状态转移我用Python的枚举实现长这样import enum import hashlib import time from dataclasses import dataclass, field class RequestState(enum.Enum): PENDING pending ROUTED routed PROCESSING processing WAIT_DEPENDENCY wait_dependency READY ready COMPLETED completed FAILED failed TIMEOUT timeout dataclass class AgentRequest: request_id: str target_agent: str state: RequestState RequestState.PENDING context: dict field(default_factorydict) dependency_waiting_for: str created_at: float field(default_factorytime.time) updated_at: float field(default_factorytime.time) def update_state(self, new_state: RequestState): self.state new_state self.updated_at time.time() def register_dependency(self, missing_field: str, provider_agent: str): self.dependency_waiting_for missing_field self.state RequestState.WAIT_DEPENDENCY # 这里会把 context 序列化后写入事件总线 event_bus.publish( event_typedependency_requested, payload{ request_id: self.request_id, missing_field: missing_field, actor_agent: self.target_agent, provider_agent: provider_agent, context_snapshot: self.context, } )事件总线的消费端逻辑有两点值得特别注意第一个是幂等性。事件总线里的消息可能被重复投递网络抖动、消费者重启所以每个Agent在处理事件之前必须检查事件消息里的event_id是否处理过。我在总线的生产者里用md5(context timestamp)生成event_id消费者用一个Redis Set去重。这个坑是线上踩过的某次事件总线消费者重启积压的消息重复投递结果订单Agent把同一笔订单的退款请求重复提交了三遍直接产生连带账单问题。第二个是上下文快照的剪裁。AgentA传给B的上下文不能是完整对话历史必须是AgentA归纳后的结构化摘要否则会有一个token膨胀的恶性循环A把长上下文传给BB处理完又把自己的长上下文传回给A几次循环后上下文长度指数增长最终突破窗口导致报错。我在总线里内置了一个summarizer它只保留当前处理状态、关键业务字段、和尚未解决的需求列表其余的原始对话历史全部丢弃或归档到外部存储。实际效果是一次跨Agent协作的上下文峰值从4500 token降到了1100 token左右。3.3 状态机把“执行流程”变成“可观测的有限状态图”Agent-Reach里每个请求都有一份状态对象贯穿始终状态机的核心作用是让整个系统的执行变得可观测、可干预、可恢复。一个典型的带依赖的请求状态转移路径长这样PENDING - ROUTED - PROCESSING - WAIT_DEPENDENCY - READY - PROCESSING - COMPLETED任何一步失败都会进入FAILED而任何一步超过设定的TTL都会进入TIMEOUT。这两个终态都会被一个兜底守护进程捡起来做降级处理比如给用户回一句“系统繁忙请稍后再试”然后记录告警日志。状态机的存储我选的是PostgreSQL每行一个请求记录递归查询当前状态。为什么不全部丢在Redis里因为Redis数据容易丢生产环境你总得回答审计问题“这个请求为什么失败了”PostgreSQL里留着完整的历史轨迹排查问题的时候一条SQL就能拉出来整个链路的每一次状态变更时间和处理Agent。状态机最重要的价值是可重放。假设AgentB在处理时崩溃了状态机里该请求停在WAIT_DEPENDENCY。重启后守护进程发现所有停留在非终态的请求会按照状态机的历史轨迹重新触发一次。这个重放必须满足幂等性即使AgentA已经处理过这个请求再次触发也不能产生副作用。我的做法是给每个请求分配一个request_id业务Agent的函数签名强制要求带上这个ID所有外部系统调用订单接口、退款接口都缓存request_id - 对应结果重复请求直接返回缓存值。4. 不可靠环境下的保命设计超时、重试、熔断与降级做Agent系统你要默认一个前提LLM调用一定会超时外部API一定会抖动Agent的推理结果一定会有错。Agent-Reach在生产环境能稳定跑下来靠的并不是大模型能力变强了而是保命设计做得足够多。4.1 三层超时LLM调用、Agent狂奔、整条链路超时设置是我最早被坑的地方。最开始我只给整条链路设了一个30秒的总超时结果一个子Agent卡在LLM调用上整条链路都跟着陪葬而且你根本不知道卡在哪一环。Agent-Reach的做法是三层超时各管一段第一层单次LLM调用超时设置为10秒。超过10秒直接截断视作该Agent本次调用失败。第二层单Agent处理超时从Agent收到上下文到它返回结果上限25秒。这个时间覆盖了多次LLM调用和内部工具调用。第三层整条请求链路TTL上限60秒。到60秒还没进入终态状态机会强制置为TIMEOUT并返回兜底话术。参数不是拍脑袋定的我是根据压测数据的P95延迟来反推的。压测时纯单Agent处理P95是6秒加了跨Agent依赖后变成11秒再算上排队缓冲和底层模型抖动余量25秒单Agent超时是合理的。如果你们的Agent链路更复杂可以相应放宽但原则是总TTL必须大于单Agent超时N轮依赖的最大理论时间否则正常的慢请求会被误杀。4.2 重试策略只有幂等操作才能重试重试这件事大多数团队犯的错误是无脑重试。LLM调用失败重试没问题但Agent调完一个退款接口返回超时你无法判断接口到底有没有扣款成功贸然重试就是搞出重复扣款。Agent-Reach的规则很简单LLM生成失败返回非200、解析失败→ 直接重试最多3次每次退避2秒、4秒、8秒。外部只读工具调用失败查订单、查物流→ 直接重试最多2次。外部写操作失败退款、改地址、提交工单→ 不自动重试把请求置为FAILED进入人工处理队列或者返回用户“正在处理中”并异步核对核对成功后再通知用户。这个表格我建议直接贴在墙上操作类型是否自动重试理由LLM文本生成是最多3次幂等重试无副作用只读API调用是最多2次幂等重试无副作用写操作API调用否非幂等重试可能产生额外订单/扣款跨Agent依赖事件是最终一致通过request_id去重保证幂等4.3 熔断当一个Agent连续报错把它摘出去晾一会Agent也会“生病”。某个Agent的底层模型服务商宕机、或者它的Prompt被误改导致开始疯狂拒单、或者某段时间流量暴涨导致它自身超时率飙升。如果不加熔断这个坏Agent会拖垮所有依赖它的请求。Agent-Reach里有一个简单的熔断器以Agent为粒度统计最近1分钟的错误率错误率超过50%错误次数/总调用次数且调用次数大于10次 → 触发熔断。熔断状态持续30秒期间所有指向该Agent的请求直接返回降级结果不再发起实际调用。30秒后进入半开状态放1个测试请求过去试试水成功则关闭熔断失败则再断30秒。熔断器的核心价值是防止故障蔓延。举个例子订单查询Agent挂了如果没熔断所有涉及订单的请求都会卡在它身上然后排队然后超时然后整体雪崩。熔断后用户请求会快速收到“订单系统正在升级稍后再试”用户流失少其他Agent也免受连带影响。4.4 降级方案当Agent不可用时系统如何体面地失败降级不是直接把用户晾在那而是系统自动选择一个成本更低、能力更弱但不会出错的方案。我在Agent-Reach里内置了三档降级优先级第一档换模型。如果目标Agent用的是大参数模型触发超时熔断后自动切到小参数模型走同一套Prompt可能效果略差但不至于直接失败。第二档规则兜底。如果连小模型也不可用则从Agent注册的fallback_intents里寻找有没有规则模板能匹配用户意图。比如售后Agent挂了规则引擎检测到“退货”关键词直接返回一条固定的售后流程指引文案。第三档转人工。前两档都失败则把请求转到一个二级队列由值班运营接手。这一步看似“失败”但它保证了用户不会得到一个AI胡说八道的答案。这个设计让我在线上避免过一次事故某次模型服务商大规模故障核心Agent全挂但用户侧看到的是流畅的“由于系统维护退款请求已为您转接人工处理预计1小时内联系您”而不是一串错误码。5. 从“能跑”到“能战”压测数据、上下文断裂修复和可观测性建设5.1 压测结果不是变快了一点是链路完全可控了Agent-Reach上线前我用一套模拟的电商售后场景数据集压了一轮对比了“裸多Agent自协商”和“Agent-Reach协调”两种模式指标差别非常明显指标裸多Agent自协商Agent-Reach路由准确率无法稳定评估96.3%跨Agent协作成功率82.5%16%请求在半路迷失97.8%P95端到端时延8.6s2.8s单请求平均Token消耗超出Agent-Reach约3.1倍基准死循环/挂起请求占比4.2%0.03%故障恢复率崩溃重启后低无法定位高状态重放自动恢复自协商模式那16%的“半路迷失”请求大部分消失在这种场景AgentA成功处理完自己的部分想把结果传给AgentB但AgentB因为上下文格式不匹配直接拒绝接收。Agent-Reach的状态机总线转发方式相当于把“格式不匹配”这个致命问题提前在接入协议层解决掉了。5.2 上下文断裂一个我花了两周才彻底解决的隐形Bug在Agent-Reach开发过程中最让我头疼的问题不是路由而是上下文断裂。场景是这样的用户问“我家那个蓝色耳机能退货吗”售后Agent先通过用户ID查到了订单确认耳机在退货期内然后它需要调用退款Agent去发起退款。退款Agent收到的上下文是用户: 我家那个蓝色耳机能退货吗 你的任务是: 发起退款但退款Agent根本没有“蓝色耳机是哪个订单的、金额多少、用户是谁”的信息因为售后Agent只传了任务指令没传处理结果。这在人跟人的协作里是不会发生的——人类会自然而然地补一句“这是订单号#1024金额299元的那个耳机”——但LLM不会你不显式告诉它传什么它就只传“用户原话任务描述”。修复方案是给总线加了一个result_schema的强制约束。每个Agent在处理完业务后必须把自己的输出按结构化格式写入上下文而不只是返回一段自然语言。售后Agent的输出必须是{ handled: true, order_info: {order_id: 1024, total_amount: 299.00, product_name: blue_headphones}, decision: refund_eligible, next_step_suggestion: proceed_refund }有了这个结构化快照退款Agent才能拿到完整的上下文开始干活。如果Agent没按schema输出状态机直接拒绝它的事件发布强制要求补全。这做法的本质是不要让Agent之间用自然语言“对话”而要让他们用共享Schema“交换数据”。人类的自然语言适合谈判不适合系统集成这句话我写进了项目README的第一行。5.3 可观测性没有全链路追踪你根本不知道是哪句话毁掉了整条链路多Agent系统的排障难度比普通后端系统高一个数量级。普通后端你查日志就能定位到是哪个服务报错但Agent系统里同一个请求会经过好几个Agent每个Agent在做决策时都会调用LLM、调用工具、返回中间结果你必须在毫秒级理解“这个Agent在思考什么、它基于什么上下文做出了这个决策”。Agent-Reach把全链路追踪作为一等公民设计每个请求从进入路由器开始就生成一个trace_id所有Agent的事件、状态变更、LLM调用记录、工具调用记录都带上这个trace_id写入日志和事件总线。我用OpenTelemetry做链路追踪把每段Agent的执行过程拆成SpanSpan里记三样东西InputContext这个Agent当时收到的完整上下文通常从总线拿不是原始对话而是结构化快照。LLMCallInfo调用的模型、Prompt摘要、输出、耗时、Token消耗。DecisionRationaleAgent自己声明的决策原因。这套日志有一个特别实用的功能回放Agent的思考路径。出了问题我不需要猜直接看渲染好的追踪视图一行一行还原“它为什么做这个决定”。有一次线上会话被错误路由到投诉Agent排查时追踪链路显示路由模型把用户提到的“这个耳机戴着耳朵疼”误判成了“身体健康投诉”这是模型语义理解的边界但如果没追踪你大概率会以为是规则写错了然后改了一通无关的代码。可观测性的另一个实用技巧是Agent每次决策后都打印一条“我做了什么为什么”的结构化日志。这句话看着朴素但你让Agent在返回结果之前强制做一次“日志记录动作”会显著降低Agent的幻觉——当它需要把自己的决策逻辑写出来时它会更容易发现自己的逻辑漏洞。6. 部署形态与工程落地的几个细节Agent-Reach的部署形态很灵活它不绑定特定的Agent框架。我用LangGraph写过复杂Agent也用纯OpenAI函数调用写过轻量Agent都能平滑接入Agent-Reach。核心原因是它只依赖三个外部组件事件总线、状态存储、路由器模型服务器。单机小规模场景我用SQLite加内存事件总线就能跑生产环境我用了PostgreSQL加Redis Stream。配置文件长这样agent_reach: state_store: provider: postgres dsn: postgresql://user:passlocalhost:5432/agent_reach event_bus: provider: redis_stream redis_url: redis://localhost:6379/0 router: model: custom-finetuned-6b confidence_threshold: 0.6 clarify_agent: clarify max_candidates: 2 timeout: llm_call_seconds: 10 agent_total_seconds: 25 request_ttl_seconds: 60 circuit_breaker: error_threshold: 0.5 min_calls: 10 open_state_seconds: 30 half_open_test_requests: 1有一个部署细节必须提醒路由器和业务Agent不要共用同一个模型服务账号。如果业务Agent流量高峰把模型服务的限流配额打满路由器也跟着失败那整个系统的入口就瘫痪了。我把路由器单独部署在一个小实例上用独立的API Key和业务流量隔离。另一个容易踩的坑是Agent的冷启动问题。新Agent接入Agent-Reach时如果它的能力描述写得含糊路由器的命中率会很低。我常用的方法是接入初期先让新Agent接收10%的流量同时采集真实请求的历史命中数据迭代能力描述和输入schema等路由准确率稳定在90%以上再全量放开。这个“灰度路由”机制本质上是对路由器模型和新Agent能力边界双方都不确定的一种风险对冲。7. 我在这个项目上最深的几条体会如果只让我分享三条经验我会选这三条。第一条Agent系统的问题本质上是工程问题不是模型问题。最早我也迷信“模型强了一切都会好”。实际上我遇到的绝大多数故障都不是因为LLM理解能力不够而是因为链路设计脆弱、上下文传递断裂、超时策略缺失、故障无隔离。哪怕你换GPT-4级别的大模型这些工程问题依然存在。Agent-Reach这套协调机制最大的价值不是提升了单个Agent的智商而是让整个系统的失败变得可预期、可控制。第二条能用结构化解决的绝不用自然语言解决。这是我在这个项目里流了最多血之后得到的准则。Agent之间的信息传递、状态共享、依赖协商凡是能用JSON Schema、状态机、事件总线解决的就不要让LLM用自然语言去“随机应变”。自然语言是给用户交互用的不是给系统集成用的。你的Agent系统会因此失去一些“灵活性”但会换来大量稳定性和可维护性这笔交易非常划算。第三条可观测性就是生产力。初期我为了赶进度跳过了全链路追踪的建设结果每次出问题团队都要花半天时间捞日志、猜上下文、翻模型调用记录。后来补上追踪系统排障时间从小时级降到了分钟级。这件事怎么强调都不过分在Agent系统里不能观测就不能优化更不能止血。Agent-Reach目前还在持续演进下一步我在做的是把路由器的候选集训练样本积累成自动化数据集让路由准确率能随着线上数据的积累自动提升同时也在探索把状态机从集中式改成分布式共识方案让系统在高并发下具备更强的横向扩展能力。这又是一段长路后面有结论了再来分享。
