接手这个项目的时候我心里其实挺没底的。市面上讲Agent搭建的文章一抓一大把但大部分都在讲单个Agent怎么搞或者怎么用LangChain、LlamaIndex这类框架拼出一个Demo。可真正到了要把三五个、七八个Agent放一起协同干活的时候问题就全冒出来了谁该处理这个请求、A调用B的接口超时了怎么办、上下文散得到处都是、日志根本串不起来。我花了两个多星期折腾各种直连方案最后还是自己动手搭了一个轻量的Agent统一触达层——也就是这个项目的雏形后来整理成了一套可以直接上手的东西。这篇博文不讲大道理就围绕Agent-Reach这个核心把我从设计思路、核心抽象、到落地实操、再到生产环境踩坑的完整过程掰开揉碎讲清楚。无论你是刚开始接触多Agent编排还是已经在生产环境里被调用链路折磨过这篇内容应该都能给你一些直接能用的参考。1. 多Agent协作的通信乱局为什么要做统一触达层1.1 三个Agent一起干活为什么反而比一个人干更累我最初接手的任务不算复杂做一个客服工单的自动分类与初步响应系统。按照常规思路我拆了三个Agent——一个负责意图识别一个负责从知识库检索相似案例还有一个负责生成回复草稿。起初我用最简单的方式意图识别Agent输出一个JSON然后我用Python的requests库直接去调检索Agent的HTTP接口拿到结果再往生成Agent那边传。听着挺顺的是吧但实际跑起来三天我的时间就全烧在调试上了。问题出在几个地方。第一每个Agent是我按自己的习惯写的接口参数命名、返回格式全凭当时的想法A返回的是case_listB那边却期望接收similar_cases中间得写一堆胶水代码做字段映射。第二其中一个Agent升级了模型版本返回结构里多了一层嵌套我的胶水代码就直接炸了而调用方根本不知道这个变化。第三一旦链路里多加一个Agent调用关系就从一条直线变成了一张网任何一处的超时或错误排查起来都像是在玩扫雷。这其实是多Agent系统里最常见的组织困境单看每个Agent都很清晰组合在一起就开始失控。根本原因不是Agent本身质量差而是Agent之间缺少一个约定的、能自主管理的通信基础设施。你总不能让每个Agent都知道其他所有Agent的存在那样耦合度会随着Agent数量呈指数级膨胀。1.2 从网状的点到点调用收敛为星型的统一触达我当时也有过很天真的想法觉得用消息队列把链路改成异步的不就解耦了吗于是试过用Kafka做中转。消息倒是不丢了但新的问题更让人头疼同步交互本质上被异步化之后工单请求方需要等待多个Agent的结果才能往下走你得自己实现回调、轮询、超时匹配一堆逻辑。更要命的是消息队列里流转的是裸的数据结构根本没有这个能力该由哪个Agent处理的语义运维起来并不轻松。对比之后我确定了自己真正需要的东西一个统一触达层它不取代Agent本身也不强制Agent内部的实现方式而是在所有Agent之上做三件事——注册、路由、上下文传递。所有上游服务不需要知道具体Agent的地址和接口规范只需要把请求交给触达层由触达层根据请求意图找到合适的Agent再把结果带回来。这个思路很像给一栋楼统一装了配电箱每个房间还是用自己的电器但电从哪里来、怎么分配、哪里跳闸了都归配电箱管。负责业务的上游不用再关心谁来处理工单分类只需要说帮我把这个工单分类。所谓Agent-Reach这个名字核心就是Agent被触达的方式。它把Agent的通信模型从人肉维护的网状调用收敛成了由一个中枢统一调度。我用这个模型重构之后加新Agent的成本从一个改多个调用方、变成只注册一个服务、配置一条路由规则。1.3 Agent-Reach不做什么同样重要想明白要做什么还得想清楚不做什么。我在设计之初就给自己划了几条红线这些边界后来帮我避免了很多不必要的时间投入。Agent-Reach不做Agent本身。它不需要你把自己的业务逻辑改造成某种特定的Agent框架你现有的一套Python脚本也好、微服务也好、OpenAI的Function Calling也好只要提供一个可调用的接口就能接入。这让它天然对各种异构实现友好。Agent-Reach不做业务编排。也就是说它不会替你想这个工单应该先走意图识别再走检索最后走生成这种业务流程。编排逻辑留在你的上层应用里触达层只负责路由和传递。为什么这么设计因为编排常常带强业务属性把业务规则硬塞进一个通用组件里最后只会让组件变成一个什么都做、什么都做不深的怪物随后的每次业务变更都牵一发动全身。Agent-Reach不做状态存储。话术生成过程中的中间状态、会话历史应该由业务方自己去管。触达层只在一次请求的生命周期内维持必要的上下文请求结束就释放。这样可以极大地简化触达层的实现与运维也让你可以在不同的会话策略之间自由切换不用被基础设施绑定。这个做什么和不做什么的界定我认为是整个项目里最重要的设计决策。很多类似的框架项目方向走偏不是因为功能不够而是因为边界没划清楚。2. Agent-Reach的核心抽象注册、路由、上下文三板斧2.1 服务注册每个Agent都带着能力名片报到Agent-Reach的第一个核心部件是Agent Registry注册中心。每个Agent在启动时会向Registry提交一条注册信息。我收到过不止一次疑问这不就是Consul或者Nacos做的事吗功能上确实有一部分重叠但关键区别在于Agent注册的不只是一个网络地址而是一张能力名片。我设计的注册信息结构大致长这样{ agent_id: intent-classifier-v3, group: nlp-service, address: http://10.0.4.12:8080, protocol: http, capabilities: [ { name: intent_classify, description: 识别用户咨询的真实意图输出标准意图代码, input_schema: intent_classify_v1.schema.json, output_schema: intent_classify_result_v1.schema.json, priority: 10, tags: [nlp, classification] } ], health_check: /healthz, weight: 100, timeout_ms: 3000, max_concurrency: 20 }其中input_schema和output_schema是两个JSON Schema文件的标识。这个设计当时让我犹豫了一阵子要不要把契约说明做这么重。后来发现在多Agent场景里这玩意能省下大量扯皮的功夫。每个Agent的能力输入输出都有明确的Schema约束调用方不用猜触达层也能在路由前做一次参数合法性检查。配合注册中心的元数据版本管理机制Agent升级时如果修改了Schema老版本调用方会立刻收到明确的告警信息。这点我后面在踩坑章节会专门展开因为想靠人肉同步契约在多Agent协作里是一条走不通的路。注册信息里还有几个关键字段。priority用来处理多个Agent具备相似能力的场景比如通用意图分类和基于领域规则的分类器都能处理退货意向的意图那我可以让规则分类器的优先级更高优先走成本更低的路径。weight则是负载均衡权重适合把流量在多个部署副本之间按比例分配。health_check是触达层定期主动探测Agent健康状态时用的地址避免把一个请求路由到一个已经挂掉的进程上。2.2 路由策略按意图找Agent而不是靠硬编码注册中心解决的是有哪些Agent可用的问题Router解决的是这次请求该找谁的问题。Agent-Reach的路由模型基于意图描述匹配而不是传统的按服务名精确匹配。当一个请求进入触达层它带了一个目标描述例如{capability: intent_classify, input: {text: 我想退掉昨天买的衣服}}。Router会拿着这个capability去Registry里查询所有声明了该能力的Agent列表再根据优先级、当前负载、健康状态、路由规则四重过滤后返回最合适的候选集合并执行调用。路由规则配置我完全采用声明式YAML便于版本管理和动态更新。下面是我项目里最常用的一组配置示例routes: - name: classify-then-retrieve match: # 从请求中提取意图标识 field: capability value: intent_classify strategy: # 两个Agent具备同一能力时先看优先级再看weight type: weighted_random fallback: # 主路由指定的agent调用失败后自动尝试备选agent enable: true max_fallback_attempts: 2 limits: max_requests_per_second: 150 max_concurrent_requests: 30这里我要着重提一下fallback机制。我当时做客服系统时知识库检索Agent有两个版本一个是基于Elasticsearch的旧系统一个是基于向量检索的新系统。我不希望每次升级都全量切换而是想逐步把流量引到新系统上同时保留旧系统作为后备。在路由配置里我把新系统设为primary、旧系统设为fallback。这样即使新系统的模型推理偶尔超时触达层也能自动把请求降级到旧系统对上游完全透明。这种路由模型的收益是显而易见的新增一个Agent处理既有能力时只需要注册并调整路由权重完全不需要通知上游改动任何代码。我粗略估算过引入这套机制之后系统里新增Agent的平均接入时间从原来的几个小时降到了20分钟左右。2.3 上下文传递让每个Agent拿到该拿的那一份多Agent协作里有个特别容易在前期被忽略、后期被折磨疯的话题——上下文管理。一开始我天真地以为只要把整个会话历史、用户画像、前序Agent的输出结果统统塞进每个请求里反正大模型上下文窗口挺大传过去就完事了。实际跑起来才发现这会造成上下文冗余和多种数据污染。检索Agent收到一大堆和检索无关的闲聊历史之后会对关键词权重产生干扰生成Agent收到前序Agent完整的长篇输出后很容易被带偏。上下文不是越多越好关键是精准投递。Agent-Reach为此设计了Context Bus的概念。它不是一个独立的存储中间件而是触达层在处理每个请求时构建的一个临时上下文对象生命周期与请求一致。这个对象由普通字段和一个标签组成。标签携带全局追踪ID、用户ID、安全令牌、会话ID普通字段则按不同Agent的需求做裁剪。举个实操例子。在工单系统里一次请求会经过意图识别、相似工单检索、回复生成三个Agent。意图识别需要的是原始用户文本加标签。检索Agent需要的是结构化意图代码和用户所在的业务线这样它可以在对应的工单子集里做向量检索。生成Agent需要的是检索出的相似工单列表和标签以及一条系统提示词。每个Agent拿到的上下文集合互不相同但又不缺失必要信息。触达层的Context Bus在内部维护一张上下文映射表标识每一个Agent能消费哪些上下文键。它靠Agent注册时声明的能力元数据自动构建初始映射业务方也可以在配置里手工覆盖。我在初期把这张表做得很简单用的就是KV结构等Agent数量增长后再引入更细的命名空间隔离。这套机制的完整实现代码不算复杂核心是约束好能看什么和能改什么两条边界。3. 落地实操一个三Agent协同任务的完整搭建过程3.1 环境准备与最低配置理论讲得再多不如直接搭一个能跑的例子。我建议你照着下面的步骤在本地环境里完整过一遍半小时左右就能跑通第一版。先说环境要求我的开发机是Ubuntu 22.04配置比较朴素8核CPU加16G内存Python 3.10。整个Agent-Reach依赖的核心库很少不需要重型基础设施你不需要装Kafka不需要装Redis甚至不需要单独的数据库。开始之前先装Agent-Reach本身以及一个轻量的任务队列库我用来做一些异步结果回调的演示pip install agent-reach pip install fastapi uvicornAgent-Reach默认内置了一个基于ASGI的轻量服务端可以让三个Agent和触达层全部在本地进程里跑起来非常适合开发调试。如果要把Agent部署到不同节点只需要保证它们能通过HTTP访问到Agent-Reach的服务端地址就行部署模型和本地完全一致。3.2 定义一个Agent服务从业务函数到可触达节点Agent-Reach接入Agent的门槛很低最低配置就是一个普通Python函数加两行装饰器声明。我们先假设知识库检索这个Agent的业务逻辑是这样的给定一个意图代码和用户ID从工单历史库里找出最相似的5张历史工单。from agent_reach import agent_endpoint, AgentContext agent_endpoint( namehistorical-ticket-retriever-v1, capabilitysimilar_ticket_retrieve, input_schema{ intent_code: {type: string, required: True}, user_id: {type: string, required: True} }, output_schema{ similar_tickets: {type: array, items: {type: object}}, retrieval_score: {type: number} } ) def retrieve_similar_tickets(ctx: AgentContext): intent_code ctx.get_input(intent_code) user_id ctx.get_input(user_id) # 这里替换成你的实际检索逻辑 tickets query_ticket_database(intent_code, user_id, top_k5) return { similar_tickets: tickets, retrieval_score: 0.87 }装饰器里的name和capability定义了这张能力名片的关键字段。函数入参被收敛到一个AgentContext对象里Agent通过ctx.get_input读取触达层投递的上下文。这样设计的好处是Agent不需要直接依赖HTTP框架、不关心中间件、不用解析请求体触达层把所有通信细节都封装好了Agent开发者只需要关心业务逻辑本身。启动这个Agent只需一行命令它就会自动向Agent-Reach完成注册agent-reach run agent:retrieve_similar_tickets --registry http://localhost:98003.3 配置路由规则与上下文投递三个Agent都注册好之后下一步是配置路由和上下文映射。我在项目里维护了一份reach_config.yaml它的作用就是把哪个Agent能处理什么请求以及每个Agent能看哪些上下文固化下来方便审查和调整。registry: endpoint: http://localhost:9800 auto_sync: true routes: - name: intent_route match: capability: intent_classify strategy: type: weighted_random fallback: enable: true max_fallback_attempts: 2 - name: retrieve_route match: capability: similar_ticket_retrieve strategy: type: highest_priority - name: draft_route match: capability: reply_generate strategy: type: weighted_random context_policy: - agent: historical-ticket-retriever-v1 visible_keys: [intent_code, user_id, trace_id] writable_keys: [retrieval_results] - agent: reply-generator-v1 visible_keys: [similar_tickets, trace_id, user_message] writable_keys: [drafted_reply]这个配置重点关注两处。一是context_policy分Agent定义了可见键和可写键这直接决定上下文隔离的边界避免Agent之间串数据二是每条路由的strategy各不相同有的按权重分发有的按优先级选Agent这样可以在不同业务场景里试验不同的路由效果。配置完成后重启触达层它会自动加载路由表和上下文策略。你可以通过Agent-Reach自带的控制台观察当前已注册Agent的数量与健康状态这个在调试阶段非常有用。3.4 发起一次完整调用并拿到结构化结果触达层就绪之后业务侧接入就简单了。上游只需要调用Agent-Reach暴露的统一网关接口传入能力标识和参数剩下的路由、调度、上下文组装、超时重试全由触达层代理完成。from agent_reach import ReachClient client ReachClient(gatewayhttp://localhost:9800) # 第一步意图识别 intent_result client.invoke( capabilityintent_classify, payload{text: 我想退掉昨天买的衣服}, timeout_ms3000 ) print(intent_result.intent_code) # return_request # 第二步相似工单检索 retrieve_result client.invoke( capabilitysimilar_ticket_retrieve, payload{ intent_code: intent_result.intent_code, user_id: user_20250112 }, timeout_ms5000 ) # 第三步生成回复草稿 draft_result client.invoke( capabilityreply_generate, payload{ similar_tickets: retrieve_result.similar_tickets, user_message: 我想退掉昨天买的衣服 }, timeout_ms8000 )这里的invoke方法是同步阻塞的适合大多数在线推理场景。如果你某个环节需要异步处理比如生成回复的时间特别长可以换用invoke_async并传入一个回调地址触达层完成调用后会把结果POST到回调地址。两种模式在路由和上下文机制上是完全一致的业务方按需选择就好。我第一次跑通这个流程时从启动所有Agent到控制台看到完整的调用链追踪信息大约花了40分钟。其中大部分时间花在调整路由配置和理解Schema校验语法上真正写Agent业务逻辑反而是最快的一部分。4. 我在生产环境踩过的坑超时、重试与协议边界4.1 两类超时混在一起导致线上错误率陡增上线后第一周我就踩了一个隐蔽的大坑。那段时间工单系统的整体错误率突然从1%以下飙到8%排查了很久无果最后开着监控面板盯着调用链逐步看才发现问题出在超时配置上。Agent-Reach在整体触达层和单个Agent调用之间分别设了两层超时端到端超时和单次Agent调用超时。我当时在配置端到端超时为10秒单次Agent调用超时也是10秒表面看起来一致实际逻辑里完全不同。如果请求需要顺序调用三个Agent每个Agent都跑满8秒单次调用都在限额内但整个链路用时已经远超端到端10秒的预期了。结果就是触达层整体判定超时向上游返回错误码但下游三个Agent全都完成了自己的任务造成了重复计算和资源浪费。更麻烦的是上游看到错误后按照通用策略发起重试这等于又往触达层里打进了一轮新的流量进一步加重了Agent的负载。漏修的那几天系统的实际吞吐量只有设计值的一半左右还有大量Agent在空转做一些没意义的计算。我的教训是超时配置必须分层设计并且要明确每层超时的语义。下面的表格是我事后整理的标准模式之后所有Agent接入都按这个基准来层级含义我推荐的基准值说明端到端超时一次业务请求整体完成时限10秒包含路由、所有Agent调用、上下文组装单次Agent调用超时单个Agent从请求到响应的最长等待3-5秒根据Agent的计算复杂度调整重试间隔失败后到再次尝试的等待按指数退避1s/2s/4s防止瞬时恢复后的请求拥挤队列等待超时请求在触达层等待路由的时间1秒超过说明系统接近瓶颈4.2 重试风暴幂等键才是真正的救命稻草说到重试这是另一个容易翻车的地方。Agent-Reach自带失败重试机制初衷是为了提升单次Agent调用的成功率但如果在设计阶段不引入幂等机制重试反而会变成事故放大器。我当时有一个知识库写入Agent用于把新工单同步到向量库。某天向量数据库短暂抖动触达层触发了重试。正常情况下重试一两次也就过去了但我没有给请求设计幂等键每次重试都是一次全新的插入请求。数据库抖动恢复之后发现同一张工单被插入了四遍。在检索场景里重复数据导致的直接后果就是相似工单结果里出现大量同一单号的重复项非常尴尬。在这之后我给所有写类型的Agent调用强制加上了幂等键机制。触达层在Context Bus里内置一个idempotency_key字段由业务方在发起调用时传入或者由触达层根据请求体Hash自动生成。底层的Agent在接收请求时检查幂等键如果发现已经处理过相同键的请求直接返回上一次的结果不再重复执行。agent: name: knowledge-base-writer-v1 idempotency: enabled: true key_source: request.body.idempotency_key result_cache_ttl: 3600 # 结果缓存1小时供重试时复用这个配置上线之后重试相关的数据错乱问题彻底消失了。你要记住一点重试机制解决的是传输链路的不可靠而幂等键解决的是业务执行的不可靠两者必须同时存在。4.3 Schema契约的边界一个Agent改返回格式整个链路跟着遭殃第三个坑涉及到我在前文提到的Schema机制。有一个升级版本的生成Agent工程师为了给回复补充来源引用在返回JSON里新增了一个字段并且把原本的drafted_reply字段类型从字符串改成了对象。按理说改动不复杂对吧但问题在于这个Agent的上游调用方我的路由编排层是按旧的Schema来解析结果的完全忽略了新增字段还把drafted_reply按字符串直接拼接进了最终回复里。生产环境一下子出现了一批格式错乱的工单回复。这个问题不是Agent-Reach能替你解决的它不会阻止你把一个对象当成字符串拼接但它提供了一套前置校验机制在调用返回时对结果做Schema合规性检查。我后来在触达层打开了严格校验开关validation: response_validation: strict # 若Agent返回结果不符合output_schema触达层直接丢弃结果并记录结构型错误 on_schema_mismatch: return_error # 支持 log_only 模式和 return_error 模式建议前期用log_only熟悉业务打开严格校验之后升级Agent如果破坏契约触达层会立刻返回一个标准的结构错误码而不会把这个坏结果继续往上传递。与此同时Agent的注册元信息里保留了历史Schema版本触达层可以把请求降级到旧版本Agent上。这样的话版本升级可以采取灰度发布的形式推进不会因为一个字段类型的小改动导致整个客服链路崩溃。说实话Schema校验机制确实是Agent-Reach里前期投入成本比较高的部分因为每个Agent都要定义输入输出契约并维护版本但这些成本换来的是我在后续所有迭代里都可以放心改动单个Agent这在收益上非常划算。5. 从Demo到生产Agent-Reach的扩展思路与取舍5.1 可观测性调用链追踪不做好生产环境就是摸黑开船我在前文不止一次提到调用链追踪信息这里展开说说Agent-Reach的可观测性设计。当一个请求穿越多个Agent的时候最痛苦的事情就是出了问题不知道在哪一个环节。Agent-Reach的做法是给每一个请求分配一个全局唯一的trace_id并在Context Bus里自动注入。所有Agent在处理过程中打出的日志、上报的指标、返回的错误都会自动带上这个trace_id。但日志带上ID只是最基础的一层。我自己的生产实践里还会在触达层周围围一圈监控指标包括Agent调用成功率、响应延迟的P50/P95/P99分位数、每个Agent的排队深度、路由失败次数。这些指标最终汇聚到Grafana面板上任何奇怪的波动都能快速定位到具体Agent。需要特别记录在案的一个洞察是不要只在出问题时才去看监控面板。我把监控面板当时钟用每天早中晚各快速扫一眼。追踪信息和指标就像是系统的心电图和血压你提前知道哪里不对劲总比病人倒下之后再推去抢救要从容得多。5.2 安全边界从可信内网走向多租户场景时的必要升级如果你的Agent触达层只是在公司内网里供自己的服务调用安全设计可以相对粗放。但一旦要让外部业务方或者说多个租户共享同一套Agent资源就要考虑更严格的安全模型。Agent-Reach在初期版本里内置了最简单的Bearer Token认证我可以给不同的上游调用方签发不同的Token并在触达层配置Token对应的访问权限范围。比如A业务方只能触达intent_classify和similar_ticket_retrieve不允许触达reply_generate这在配置里用一条ACL规则就能实现。到了更强调合规的场景我建议在Agent节点之间启用双向mTLS认证。简单说就是不光触达层要证明自己是谁每个Agent也需要向触达层出示自己的证书构建双向信任。这套方案我之前在金融项目里落地过虽然配置稍微复杂一点但安全级别高出一个档次并且能对接已有的Kubernetes证书管理能力。再往上一层是数据脱敏。客服工单里经常包含用户手机号、住址这类敏感信息这些数据不能在系统间以明文形式随意流转。我建议在触达层的Context Bus上做一个可插拔的脱敏组件对出站请求内容自动做字段级脱敏比如手机号保留前3后4。这个组件我在生产环境里是必开的因为出事的成本远比这一点点算力开销高。5.3 性能与成本的平衡连接池、批量路由与结果缓存最后聊聊性能。Agent-Reach的HTTP通信层基于异步事件驱动理论上可以支撑较高的并发触达。但实际瓶颈通常不在触达层本身而在下游Agent的处理能力上限。所以要想提升整体吞吐方向要放在对下游Agent的访问策略上。我实测下来最有用的优化手段有三个。第一个是连接复用Agent-Reach的HTTP客户端默认启用了连接池但我把最大连接数设置得太保守在高峰期出现过连接等待。后来把每个Agent的目标连接数从5调整到50同时开启Keep-Alive延迟直接降了一个量级。第二个是批量路由。有些请求并不是需要立即返回结果的比如夜深人静时批量归类历史工单。Agent-Reach支持把一批同类型请求聚合到一个调起批次里统一发给下游Agent批量处理。这对那些每次计算开销很大的Agent来说能大幅摊薄单条成本吞吐量可以提升好几倍。第三个是结果缓存。对于固定问题、固定参数的请求比如这个用户的历史工单里有多少条退货申请如果短时间内重复触达同一个Agent其实没有必要反复执行。我在触达层给Agent注册元数据里加了一个cacheable标记命中缓存就直接返回记录的结果。注意这个开关要谨慎打开只有那些对实时性要求不高的只读型能力才适合。性能优化的原则永远是先找到真正卡住你的那个瓶子再对症下药而不是一上来就上各种缓存和中间件。我见过不少团队把系统堆得很重结果真正瓶颈不过是某个Agent的单线程处理慢而已。用Agent-Reach把各环节延迟指标打出来再判断要先优化哪一环比盲目调参要高效得多。最后分享两个小技巧文章写到这里我再分享两个实际使用中发现的小技巧。第一个是关于Schema文件的组织方式。很多Agent的能力是渐进成长的一开始可能只支持一两种输入后面会加参数。我建议把Schema文件按照能力名_版本号的方式独立存放在Agent注册信息里只引用文件名而不内嵌Schema内容。这样每次升级能力只需要新增一个Schema文件并指向它旧版本文件还留着将来做灰度回退特别方便。第二个是在路由配置里善用诊断模式。Agent-Reach有一个dry_run参数打开之后触达层不会真正调用任何Agent只返回路由决策结果以及上下文投递计划。我在给新Agent接入时都会先跑一遍dry_run确认路由选中的是预期的Agent、上下文键都在可见列表里再切换到真实调用。这招可以有效避免配置看起来对、跑起来炸的尴尬局面。多Agent协作的复杂度是真实存在的它的复杂度来源于分布式通信固有的不确定性和Agent间契约关系的动态演化。Agent-Reach这样一套触达层不可能消灭所有复杂度但它的价值在于把那些高频复杂操作收敛成几件简单、有边界的标准动作——注册、路由、上下文传递、可观测。把你的注意力从Agent之间的通信细节上解放出来放到真正的业务流程里。如果你也在搭建自己的多Agent系统希望这篇文章能帮你少走一段弯路。