最近几个月一直在折腾多代理系统从最初几个独立 Agent 各干各的到后来发现它们根本没法协同工作再到最终沉淀出 Agent-Reach 这套框架整个过程踩了不少坑。简单说Agent-Reach 解决的核心问题是如何让多个 AI 代理在复杂任务中稳定、高效地相互协作并且真正“触达”外部工具和数据源而不是各自为战、答非所问。这篇文章把我从架构选型到落地实现、再到排查故障的完整过程都记录下来适合那些正在搭建多代理系统、或者准备从单 Agent 转向多 Agent 架构的开发者参考。1. 项目定位与整体设计思路1.1 Agent-Reach 到底解决了什么问题先说说我为什么非要自己动手做这个框架。当时我在做一个企业内部的知识管理助手初期方案很简单一个 Agent 挂上知识库检索、再加上几个 API 工具看起来够用了。但实际跑起来之后问题一个接一个冒出来。首先是单代理的上下文瓶颈。一个 Agent 带着全部工具定义、历史对话、检索结果去调用模型Token 消耗巨大不说模型还经常在多个工具之间“迷路”。比如用户问“帮我查一下上季度销售数据然后生成一份摘要发到群里”这个任务涉及数据库查询、文本摘要、消息推送三个环节单代理要在一个 Prompt 里同时管理这三件事经常出现工具调用顺序错乱或者中途丢失意图的情况。其次是工具调用的可靠性问题。在真实业务场景里工具不是理想化的“输入-输出”黑盒。数据库可能超时第三方 API 可能返回异常结构消息推送可能因为权限不足被拒绝。单代理架构下这些异常一旦发生整个会话就断了用户只能重新描述需求。Agent-Reach 的核心价值就是把这些问题拆开解决。它做的是三件事用路由层做意图分发用执行层做工具调用用协调层管理多代理之间的状态同步。每个 Agent 只专注一个领域路由层负责判断任务该交给谁执行层负责和外部系统打交道协调层负责把各环节的结果拼装成完整的响应。这样单个 Agent 的负担大幅降低系统整体的容错能力也上来了。还有一个很实际的痛点是多代理之间的信息传递。很多人在搭建多代理系统时最简单粗暴的做法是让 Agent A 的输出直接拼进 Agent B 的输入。这在任务链很短的时候勉强能用但一旦链路超过三层上下文里的信息会迅速膨胀而且噪音越来越多Agent B 根本分不清哪些是有效信息、哪些是中间过程的垃圾输出。Agent-Reach 里专门做了一个状态管理模块每个环节只传递结构化数据过滤掉中间的推理过程和调试信息效果提升非常明显。1.2 为什么没直接用现成的多代理框架说实话市面上的多代理框架并不少。LangGraph、AutoGen、CrewAI 我都认真评估过也做过一些原型验证。之所以最终选择自研一个偏轻量的框架主要有几个原因。一是可控性。现成框架封装层次太高出了问题很难排查。我记得用某个框架跑一个四代理协作的任务日志打印出来有几十层嵌套调用定位一个工具返回格式错误花了整整半天。Agent-Reach 的设计原则是“每层只干一件事每件事都能被观测”这在排障时带来的效率提升是巨大的。二是依赖控制。企业环境里对依赖版本、安全扫描、部署方式都有严格要求。有些框架的依赖树非常重光装依赖就要拉下来几百个包这在内网环境部署时会很痛苦。Agent-Reach 的核心部分我只用了三个依赖OpenAI SDK、Pydantic 做数据校验、以及一个轻量的异步任务队列其他全部用标准库实现。三是灵活性。现成框架往往预设了特定的 Agent 协作模式比如“规划-执行”或者“讨论-共识”。但实际业务里的协作模式五花八门有的任务适合串行流水线有的需要并行投票有的要动态编排。自己写框架可以根据任务类型灵活切换协作模式而不是被框架限制住。当然这不是说现成框架不好。如果你的需求比较简单、团队规模大、愿意花时间学习框架的约定用现成框架完全合理。但如果你像我一样需要深度定制、对性能和可观测性有严格要求自研一个轻量框架其实是更务实的选择。2. 架构设计与核心模块拆解2.1 基础层模型接入与统一抽象Agent-Reach 最底层是模型接入层。这个层的设计原则是不绑定任何单一模型厂商。我在最开始就把模型调用封装成了一个统一的接口上层代码只认model.chat(messages)这个抽象不关心底层是 GPT 系列、Claude 还是开源的本地模型。具体实现上我定义了一个BaseLLMClient基类各个模型厂商的适配器继承它实现chat、embed、stream_chat三个核心方法。from abc import ABC, abstractmethod from typing import List, Dict, Any, AsyncIterator class BaseLLMClient(ABC): 统一模型接入抽象 abstractmethod async def chat( self, messages: List[Dict[str, Any]], tools: List[Dict[str, Any]] | None None, temperature: float 0.2 ) - Dict[str, Any]: 非流式对话 pass abstractmethod async def stream_chat( self, messages: List[Dict[str, Any]], tools: List[Dict[str, Any]] | None None ) - AsyncIterator[str]: 流式对话 pass abstractmethod async def embed(self, text: str) - List[float]: 文本向量化 pass这个抽象层看起来简单但实际踩过不少坑。比如不同模型对工具调用的返回格式规范不完全一致有的用function_call有的用tool_calls有的在系统提示词里对工具描述的敏感度也不同。在适配层把这些问题统一处理掉上层的路由和执行逻辑就能保持干净。另一个容易被忽视的点是异常处理策略。模型服务经常会返回限流错误、超时错误、或者偶尔的 5xx 错误。我在适配层里实现了一套分级重试机制限流错误等一段时间再试超时错误直接降级到非流式调用连续失败几次就熔断切换到备用模型。这套逻辑在真实环境中救过我好几次。2.2 路由层意图识别与任务分发路由层是 Agent-Reach 的“大脑”。它的职责是接收用户的输入判断这个任务的性质然后决定应该交给哪个 Agent 处理或者是否需要拆分任务。我最早尝试过用规则匹配做路由但效果很差。用户输入的自然语言千变万化“帮我查一下数据”和“那个报表能不能拉一下”可能是同一种意图纯正则根本搞不定。后来换成了基于语义的路由方式每个 Agent 在注册时提供一份能力描述路由层调用模型对用户输入和各个 Agent 的能力描述做匹配度打分选出最合适的处理者。async def route(self, user_input: str) - RouteDecision: # 收集所有注册代理的能力描述 agent_descriptions [ {id: agent.id, description: agent.capability_description} for agent in self.agent_registry.get_all() ] # 让模型做意图匹配 prompt f 用户输入: {user_input} 可用代理: {agent_descriptions} 请从可用代理中选择最适合处理该输入的代理ID。 如果任务需要多个代理协作请用一个适合串联的多代理流程。 只输出JSON不要输出解释。 result await self.llm.chat([{role: user, content: prompt}]) decision parse_route_result(result) # 路由置信度过低时进入人工澄清流程 if decision.confidence 0.5: decision.requires_clarification True return decision路由层还有一个重要职责是任务拆分。有些用户请求天然是多步骤的比如“对比这两个方案的优劣并给出建议”严格来说既涉及检索、又涉及分析、还要生成建议。Agent-Reach 里有一个简单的任务分解器它会在路由阶段判断这是一个单步骤任务还是多步骤任务。多步骤任务会被拆成一个有向无环图每个节点对应一个子任务节点之间的依赖关系决定了执行顺序。关于任务拆分我试过几种方案。最早是让路由模型直接输出复杂 JSON 格式的流程图定义但模型的输出经常格式不稳导致解析失败。后来改为两步走先让模型用简单文本描述步骤顺序和依赖关系再用代码解析成结构化的任务图。这样即使模型输出有些偏差解析逻辑也能兜底不会直接崩溃。2.3 执行层工具调用与状态管理执行层是 Agent-Reach 里最重的一层它负责真正干活。每个 Agent 在收到任务后需要根据任务内容决定调用哪些工具、以什么顺序调用、以及如何处理工具返回的结果。工具调用的核心设计是一个统一的工具注册机制。任何外部能力——数据库查询、HTTP API、文件读写、消息推送——都被包装成一个工具函数注册到工具表里。每个工具声明自己的名称、参数 Schema、描述信息这样 Agent 能通过模型的原生函数调用能力去匹配和调用工具。from pydantic import BaseModel from typing import Any, Callable, Dict class ToolDefinition(BaseModel): name: str description: str parameters: Dict[str, Any] # JSON Schema 格式 executor: Callable[..., Any] timeout_seconds: int 30 retry_on_failure: bool True class ToolRegistry: def __init__(self): self._tools: Dict[str, ToolDefinition] {} def register(self, tool: ToolDefinition): 注册工具到全局工具表 if tool.name in self._tools: raise ValueError(f工具 {tool.name} 已存在禁止重复注册) self._tools[tool.name] tool def get_schemas_for_model(self) - List[Dict[str, Any]]: 生成模型函数调用所需的工具 Schema return [ { type: function, function: { name: t.name, description: t.description, parameters: t.parameters, } } for t in self._tools.values() ]这里有一个特别重要的设计细节工具执行结果必须经过结构化封装后再送回给模型。很多人在做工具调用时直接把工具返回的原始文本塞回对话上下文里这是大忌。比如一个数据库查询返回了 200 行的查询结果你全塞回去Token 瞬间爆炸而且模型也不一定能从中提取出用户真正关心的那几条。我的做法是给工具结果加一个处理器Result Processor每个工具注册时可以附带一个处理函数负责把原始输出精简成“要点摘要 结构化数据”两部分。要点摘要用于模型理解结构化数据用于需要精确数值的下游逻辑。状态管理也是执行层的一个重头戏。多代理协作时每个代理都在独立执行任务它们之间的状态同步如果处理不好很容易出现数据不一致。Agent-Reach 设计了一个TaskStateStore使用内存 可选的 Redis 持久化存储每个任务节点的输入、输出、执行状态、错误信息。任务节点之间通过显式的数据传递来共享信息而不是直接读写共享内存这样大大降低了出错的概率。3. 核心实现与实操细节3.1 从零搭建一个可用的 Agent 节点先从一个最简单的 Agent 节点说起。Agent-Reach 里一个 Agent 就是一个独立的处理单元它接收输入、执行任务、返回输出。为了让这个 Agent 具备基本的工作能力需要给它配备系统提示词、工具集、以及模型配置三样东西。class Agent: def __init__( self, agent_id: str, system_prompt: str, tools: List[ToolDefinition], llm_client: BaseLLMClient, memory_window: int 10 ): self.agent_id agent_id self.system_prompt system_prompt self.tools {t.name: t for t in tools} self.llm llm_client self.memory [] self.memory_window memory_window async def run(self, task_input: str) - AgentResult: 执行代理任务的主入口 messages [ {role: system, content: self.system_prompt}, *self.memory[-(self.memory_window * 2):], {role: user, content: task_input} ] tool_schemas [ { type: function, function: { name: t.name, description: t.description, parameters: t.parameters } } for t in self.tools.values() ] # 模型对话 工具调用循环 for _ in range(self.max_iterations): response await self.llm.chat(messages, toolstool_schemas) if response.get(tool_calls): messages.append(response[message]) for tool_call in response[tool_calls]: tool_result await self._execute_tool(tool_call) messages.append({ role: tool, tool_call_id: tool_call[id], content: tool_result }) else: # 模型不再调用工具任务完成 final_content response[content] self.memory.append({role: user, content: task_input}) self.memory.append({role: assistant, content: final_content}) return AgentResult.success(final_content) return AgentResult.timeout(代理执行达到最大迭代次数)这段代码的核心逻辑是一个“对话-调用-继续对话”的循环。模型每轮要么返回工具调用请求要么返回最终回答。如果返回工具调用执行层就去执行对应的工具把结果以tool角色的消息塞回消息序列然后再次调用模型让模型基于工具结果继续推理。循环直到模型不再请求调用工具为止。有几个细节值得展开说说。AI 迭代次数上限。我默认设置为 8 次也就是说一个任务最多允许模型调用 8 轮工具。这个限制是为了防止模型陷入无限循环——比如某个工具返回错误模型反复尝试同一个工具调用。如果在生产环境跑这个值可以根据任务的复杂度调整但我强烈建议设置上限而不是让循环无限跑下去。工具执行超时。每个工具都有独立的超时时间。数据库查询这种操作我给 30 秒HTTP 请求给 10 秒文件读写给 5 秒。工具执行超时需要在上层捕获并转换为“工具执行超时”的错误信息返回给模型让模型知道这个工具暂时不可用转而尝试其他方案。这个设计让系统具备了一定的自我纠错能力。记忆窗口管理。这里的memory_window10表示保留最近 10 轮对话作为上下文。为什么要限制记忆窗口因为模型上下文窗口是有限的无限追加历史会让 Token 很快打满。我试过用总结压缩的方式保留更久的历史但在工具调用场景下压缩后的摘要会丢失重要的结构化信息比如精确的数值、ID、时间戳所以现阶段采用简单的窗口截断策略超过窗口的消息直接丢弃。对于需要长期记忆的场景我的做法是把关键信息写入一个独立的状态存储需要时再通过工具检索回来。3.2 多代理协作从串行到动态编排单代理能解决的问题有限Agent-Reach 真正的价值在于多代理协作。在我的实现里有三种协作模式串行流水线、并行分发、动态编排分别适用于不同的任务场景。串行流水线最直观适合作业步骤顺序明确的场景。比如一个“周报生成”任务可以拆成三个步骤数据收集代理 A、内容分析代理 B、报告生成代理 C。A 的输出是 B 的输入B 的输出是 C 的输入。这种模式实现起来最简单只要在任务图中维护一个 FIFO 队列依次执行即可。async def run_serial_pipeline(self, steps: List[str], initial_input: str) - str: current initial_input for step_id in steps: agent self.agent_registry.get(step_id) result await agent.run(current) current result.output # 记录每个节点的执行结果方便追踪 self.state_store.record(step_id, result) return current并行分发适合多个子任务之间没有依赖关系的场景。比如用户问“对比这三款产品的参数”那三个产品的信息检索任务完全互不依赖可以并行执行最后再把结果合并。并行模式带来的性能提升非常明显但要注意一个问题并行任务返回的结果如何合并成一个统一的输出。我的做法是设置一个聚合节点它把多个代理的输出拼装成一个结构化的“多源结果集”再送进下一阶段的处理逻辑。动态编排是最灵活也最难实现的模式。它不预设执行路径而是让路由层先决定任务图然后执行层按照任务图逐步推进。任务图中允许出现条件分支比如“如果检索结果为空则走知识库查询分支否则走搜索引擎分支”。在实现上我用的是简单的状态机推进每个节点执行完后根据其输出判断下一个节点是哪个。目前这套逻辑还不够智能分支判断还是依赖硬编码的规则但已经能覆盖大部分真实场景了。做一个简单的对比表来说明三种模式的适用场景协作模式适用场景优点缺点串行流水线步骤明确的固定流程实现简单、稳定可靠执行时间长不支持并行并行分发子任务互相独立吞吐高、延迟低结果合并逻辑复杂动态编排任务路径不固定灵活、适应性强实现复杂、排障困难3.3 工具链设计把外部系统变成代理的“双手”Agent-Reach 的整个架构里工具链的设计决定了这个框架到底能触达多少外部系统。工具链不只是简单的 API 封装它需要考虑到权限、认证、限流、审计等一系列生产环境里绕不开的问题。先说认证信息的处理。我见过太多人把 API Key 直接写死在工具代码里这在生产环境里是一个灾难。Agent-Reach 的做法是把所有敏感凭据放在一个独立的密钥管理中心工具执行时通过环境变量或者配置中心动态获取而且每次调用都会记录使用日志方便审计。这里不需要什么复杂的密钥管理系统哪怕是简单的 Vault 或者云厂商的 Secrets Manager 都可以关键是养成“代码里不出现明文密钥”的习惯。再说工具执行的限流策略。外部系统的 API 通常有调用频率限制多代理并行时很容易打爆限流。我在工具执行器外层包了一个简单的令牌桶限流器确保对同一个外部 API 的并发访问不超过设定阈值。这个设计在后来的压测中帮了大忙否则多个 Agent 同时调用同一个搜索引擎 API 时超时和 429 错误几乎不可避免。工具链还涉及异常语义的整理。外部系统的错误五花八门数据库返回SQLSTATE错误码HTTP API 返回状态码加错误 JSON文件系统返回异常栈。如果不加处理就原样丢回给模型模型很可能被这些杂乱的错误信息带偏。我给每个工具定义了五类标准错误ToolNotFound、AuthFailed、RateLimited、ExecutionTimeout、InternalError工具内部会把原始异常翻译成标准错误再返回给模型。模型看到RateLimited就知道稍后再试看到AuthFailed就知道需要提醒用户检查权限配置。4. 常见问题排查与避坑实录4.1 模型不按预期调用工具怎么办这是我被问过最多的问题模型明明注册了工具但就是不调用而是直接用自己训练数据里的知识回答。比如用户问“查一下最新的库存数据”模型可能直接编一个库存数字出来根本不触发库存查询工具。排查这个问题我的路径是这样的。第一步检查工具描述是否足够清晰。模型的函数调用能力非常依赖工具描述的质量。我见过最典型的反面教材是这样的描述获取库存信息。这个描述太含糊了模型不知道什么时候该用、需要传什么参数。正确的写法应该是当用户询问库存数量时调用此工具查询实时库存。参数 product_id 是商品的唯一标识必填。此工具返回 JSON 格式的库存列表。{ type: function, function: { name: query_inventory, description: 查询商品实时库存。当用户询问某件商品的库存数量或可用性时调用此工具。参数 product_id 是商品的唯一标识符以字母 P 开头。返回 JSON 数组每项包含 product_id、stock_count、updated_at 字段。, parameters: { type: object, properties: { product_id: { type: string, description: 商品ID以字母P开头 } }, required: [product_id] } } }第二步检查系统提示词里是否给了模型“使用工具的自由”。很多系统提示词里写了“你是一个智能助手”但没有明确告诉模型“当需要获取实时数据时必须使用工具不要依赖训练数据”。我在调试过几次之后在系统提示词里加了一句话“如果你需要的信息需要通过工具获取请务必调用相应的工具。不要根据训练数据中可能过时的信息进行猜测。”就这么一句话工具调用率从不到 60% 直接提升到了 95% 以上。第三步检查参数 ScheMa 是否过于复杂。模型对复杂的嵌套参数结构支持得并不好。我之前定义过一个包含多层嵌套数组、枚举、条件必填的工具参数 Schema模型频繁出错。后来我把参数结构扁平化一部分可选参数干脆删掉让工具在执行时用默认值代替调用成功率显著上升。4.2 Token 消耗失控和上下文爆炸多代理系统在跑了几个回合之后Token 消耗往往会变得惊人。我实测过的一个案例一个 8 步的流水线任务每步模型对话平均消耗 4000 Token加上工具定义每次都打进请求里一轮完整任务下来至少 10 万 Token。这个成本在重度使用时完全不可接受。控制 Token 消耗我采用了几个策略。策略一给工具 Schema 做缓存复用。多代理系统的工具 Schema 通常是固定的没必要每轮请求都原样发送。我的优化是在模型接入层做了一层 Schema 快照缓存只有当工具注册表发生变化时才重新生成完整的工具 Schema。这个优化在跑长流程时能省掉大约 20% 的 Token。策略二工具结果即时截断。前面说过工具执行的原始结果必须经过摘要在塞回上下文。我进一步把这个摘要做成了按需的如果工具返回的是表格型数据只保留前 5 行加一个“共 N 行”的说明如果返回的是文本截取前 800 个字符。对于需要完整数据的下游环节通过结果处理器中的结构化数据部分传递不会影响精确性。策略三历史消息压缩。在一个长对话中如果用户不断追问同一个任务的不同方面对话历史会越来越长。我实现了一个简单的压缩器当对话轮次超过记忆窗口时把早期的对话调用模型凝练成摘要只保留摘要和最近几轮完整对话。压缩摘要的标准格式是“用户问了什么 - 做了什么 - 结论是什么”这样既保留了上下文线索又大幅削减了 Token 消耗。4.3 多代理协作中的数据错乱问题多代理系统最隐蔽的坑是数据串扰。我曾经遇到过一个很诡异的问题用户同时触发了两个不同类型的任务一个是查询销售数据另一个是查询员工信息两个任务并行跑。结果销售数据的 Agent 在调用员工信息工具时竟然传入了销售报表里的一个数字作为员工 ID导致工具报错。查了半天才发现问题出在共享状态存储上——两个并行执行的 Agent 往同一个状态字典里写数据读取时拿到了对方的中间变量。解决这个问题的方法很彻底Agent-Reach 中每个任务节点执行时输入参数是从任务图定义的“数据槽位”里明确引用的不允许代理从全局状态中任意读取。每个代理的输入输出都通过一个独立的执行上下文传递并行的任务之间在物理上隔离了数据访问路径。还有一个相关的问题是工具调用的幂等性。如果某个工具执行超时系统自动重试但这个工具实际上已经在后端执行成功了比如消息推送已经发出去了重试就会导致重复推送。处理办法是给工具调用绑定一个全局唯一的request_id工具实现中检查这个 ID 是否已经处理过如果处理过就直接返回之前的执行结果。这个模式叫做“幂等键”我在所有副作用型的工具推送、支付、写入中都强制绑定了这个逻辑。4.4 一个具体案例的完整排查过程分享一个真实的排查过程。当时系统上线后用户反馈“有时回答被截断有时根本不回答”。我拉出日志发现模型返回的内容里出现了Tool execution error的错误消息但工具调用的结果是成功的。深入排查后发现问题出在工具结果封装的格式上。日志显示工具执行的原始返回值是一个元组(True, {data: ...})我在封装时直接把这个元组转成了字符串模型拿到的内容变成了(True, {data: ...})。字符串里的单引号和括号把模型绕晕了模型误解了返回结构以为工具执行失败。修复方式简单又关键封装工具结果时必须用 JSON 序列化而非直接字符串化而且要保证序列化后的格式干净、可读、无歧义。def format_tool_result(raw_result: Any) - str: 工具结果格式化的正确姿势 # 统一转成 JSON 字符串 try: return json.dumps(raw_result, ensure_asciiFalse, defaultstr) except TypeError: # 兜底无法序列化的对象提取关键信息 return json.dumps({ success: True, summary: str(raw_result)[:500] }, ensure_asciiFalse)还有一个教训永远在正式调用模型之前做一次工具 Schema 的本地校验。有些工具的参数 Schema 写得不合法模型厂商的接口在收到后会静默忽略掉不合法的字段导致模型看到的工具是不完整的。我后来在工具注册时加了一个本地校验器用 JSON Schema 的标准校验逻辑检查每个工具的定义不合法就直接拒绝注册。这个小改动极大减少了“模型不调用工具”这类问题的根源。5. 一些实操心得和后续方向5.1 多代理系统的性能调优经验性能调优这块我踩过最深的一个坑是串行执行的惯性思维。刚做完串行流水线版本时我测了一个三个节点的任务总耗时大概 12 秒。后来分析发现其中两个节点完全没有依赖关系只是我在任务图里定义成了串行执行。改成并行之后总耗时直接降到 6 秒左右提升了一倍。所以我现在做任务图设计时的第一原则就是先画依赖图把没有依赖的节点全部并行化能并行就别串行。模型调用的性能也很关键。模型的响应时间短则几百毫秒长则几十秒这直接影响整体用户体验。我做的优化是把不同模型的调用按照“快模型优先、强模型兜底”的策略分档。比如意图路由这种对推理要求不高的环节用快速小模型任务计划生成这种复杂推理环节用强模型。整体系统的响应速度和成本的平衡得到了明显改善。5.2 关于可观测性的几个建议多代理系统比单代理系统难调试得多因为一次任务可能涉及多次模型调用、多次工具执行、多个代理之间的数据传递。如果没有可观测性设计出了问题就像在黑箱里找针。我在 Agent-Reach 里从头设计了三个层级的观测能力。第一层是结构化日志。每个任务节点都输出一个包含task_id、agent_id、tool_name、duration_ms、status的 JSON 日志配合日志系统可以按task_id一条线串起来看整个任务的执行全过程。第二层是执行轨迹追踪。我把每个任务节点执行前后的输入输出快照存放在状态存储里调试时直接提取某个节点的快照不用重跑任务。第三层是统计面板。统计每个 Agent 的工具调用成功率、平均延迟、Token 消耗量这些指标直接决定优化方向。这三层观测能力投入的成本不高但收益巨大。我强烈建议任何准备做多代理系统的团队在一开始就把可观测性设计进去而不是等项目跑出问题再亡羊补牢。5.3 Agent-Reach 后续可能的扩展方向现在这个版本跑通了核心链路但还有很多值得深耕的地方。一个方向是自适应任务分解。目前的任务图还依赖预设规则后续打算让模型根据任务复杂度动态决定拆分成多少步骤、每步用什么工具真正实现端到端的自动化编排。另一个方向是代理记忆的持久化和跨会话复用。现在 Agent 的记忆窗口只在单次对话内有效用户下次重新问同样的问题系统没有任何记忆。我计划把记忆层接入向量数据库把每次对话的关键结论抽象成向量存储下来后续用户触及相关话题时通过相似度检索自动把历史经验注入到上下文里。还有一个我很感兴趣的方向是多代理的自我评估机制。现在每个代理的输出直接流向下游没有人检查质量。后续我打算加一个评估代理负责审查主线代理的输出检查它是否完整回应了用户需求、是否出现了事实性错误、是否需要追加信息。这个机制在复杂任务场景下应该能显著提升输出质量。做 Agent-Reach 这段时间我自己最深的体会是多代理系统的复杂度不是来自于单个代理的智能程度而是来自于代理之间协作的可靠性。只要把路由、执行、状态管理、可观测性这几根柱子打稳再难的任务编排都能跑得起来。如果你也在做类似的项目希望这篇文章里记录的这些方案和踩坑经验能帮你少走一些弯路。哪怕只省下你排查半天问题的时间也算值得了。