做自主决策AI代理系统这件事，我前前后后折腾了将近一年。从最初只是给大模型套一层工具调用，到后来做成能自主规划、自我纠错、甚至多个代理之间互相协作的完整系统，踩过的坑比写过的代码还多。这个项目不是某个课程作业，也不是论文里的Demo，而是真正跑在业务场景里的系统。它解决的核心问题很简单：让AI不是"你问一句它答一句"，而是给它一个目标，它能自己拆解任务、调用工具、评估结果、修正方向，直到把活干完。这篇文章我会从零开始，把整个系统从基础架构到多智能体协同的完整实践过程梳理一遍。内容包括单智能体的核心设计、自主决策循环的实现方式、多智能体之间的通信与协作机制，以及我在实际调参和排错过程中积累的经验。适合三类读者：准备把大模型接入业务系统的工程师、已经在做Agent但总感觉效果不稳定的开发者、以及对多智能体协作机制感兴趣的架构师。先说一句实话：网上关于Agent的教程很多，但大多数停留在"用LangChain调几个工具"的层面。真正生产级的Agent系统，难点根本不在调用模型，而在于决策框架怎么设计、状态怎么管理、错误怎么恢复、多个代理之间怎么不打架。这些才是本文想讲清楚的东西。1. 整体架构设计与核心概念拆解1.1 自主决策AI代理的本质是什么先把概念捋清楚。一个自主决策AI代理，本质上是一个"感知-决策-行动"的闭环系统。它接收一个目标输入，通过大模型的推理能力拆解出执行计划，然后调用外部工具或API执行具体操作，再根据执行结果评估进展，最后决定是继续、调整还是结束。这个闭环和传统软件的工作方式有本质区别。传统程序是开发者预先写死所有分支逻辑，而Agent系统把"下一步做什么"的决策权交给了模型。这意味着同一套系统在面对不同输入时，可能走出完全不同的执行路径。这个特点既是Agent最大的价值——灵活、通用、能处理非预期情况，也是它最难搞的地方——不可预测、难调试、容易失控。我在设计系统时首先明确了一个原则：不要把Agent做成"黑盒"。虽然决策由模型做出，但整个决策过程必须是可观测、可干预、可回放的。这个原则贯穿了后续所有架构决策。1.2 系统分层架构设计整个系统我分成了四层，每一层职责单一，层与层之间通过明确定义的接口通信。这四层分别是接口层、决策层、执行层和记忆层。接口层负责与外部世界对接，包括用户输入解析、最终结果格式化输出、以及各种外部服务的接入。决策层是核心，包含任务规划器、工具选择器和自我反思模块。执行层封装所有Agent能调用的工具，包括搜索、代码执行、数据库查询、API调用等。记忆层管理短期对话上下文和长期知识存储。这个分层设计的核心考量是可替换性。比如决策层用的模型，从早期的GPT-3.5换到后来的GPT-4，再到开源模型，只需要替换决策层内部的模型适配器，其他层完全不动。工具层更是如此，每接入一个新工具只需要实现统一的工具接口，注册进去就行，决策层不需要做任何修改。┌─────────────────────────────────┐ │ 接口层：用户输入解析 / 结果输出 │ ├─────────────────────────────────┤ │ 决策层：任务规划 / 工具选择 / 反思 │ ├─────────────────────────────────┤ │ 执行层：工具注册 / 执行 / 错误处理 │ ├─────────────────────────────────┤ │ 记忆层：上下文管理 / 长期存储 │ └─────────────────────────────────┘有人可能会问，为什么不直接用一个大的提示词把所有功能都塞进去？我也试过。最开始确实是一个巨大的Prompt搞定所有事，但随着功能增多，Prompt越来越难维护，改一个地方影响一片，而且模型经常在复杂任务中"迷失方向"。分层之后，每层的Prompt可以独立优化和测试，出了问题也能快速定位。这是第一个值得分享的经验：Agent系统里，架构清晰比功能丰富更重要。1.3 技术选型的底层逻辑技术选型这块，我走了不少弯路，这里把最终方案和选择理由说清楚。大模型底座选了支持函数调用(function calling)的模型，这是做Agent的基础能力。如果没有原生函数调用支持，就需要在Prompt里手动规定输出格式然后用解析器去抠，效果差很多。当时对比了多个模型，最终选了能稳定返回结构化工具调用参数的方案，这一点对后续系统可靠性影响巨大。Agent框架方面，我没有直接用现成的LangChain或AutoGen，而是在其基础上做了大量自研封装。原因有三个：第一，现成框架抽象层次太高，出了问题很难追踪到底层逻辑；第二，框架自带的工具调用机制不够灵活，我需要自定义决策循环；第三，生产环境的特殊需求——如超时控制、并发限制、审计日志——框架原生支持都不到位。我的做法是参考LangChain的设计思想，自己实现了一套轻量级的核心逻辑，只保留必要的抽象。向量数据库选了支持HNSW索引的轻量级方案，用来存长期记忆和工具使用经验。选它主要是因为部署运维简单，性能对业务规模足够了。数据量大的场景可以换成更重的方案，核心接口保持一致就行。这也是为什么我一直强调接口抽象的重要性——技术栈随时可以换，架构不能轻易动。2. 自主决策机制的核心实现2.1 决策循环：从ReAct到自定义改进自主决策的核心是一个循环，业界标准的参考模式是ReAct(Reasoning + Acting)，也就是"推理-行动-观察"交替进行。模型先思考当前状态，决定采取什么行动，执行行动后观察结果，再基于新状态继续推理。我基于ReAct做了两处关键改进。第一处是增加了明确的计划阶段。原始ReAct模式中模型每一步只做局部决策，没有全局规划。我在循环开始前让模型先生成一份完整的任务清单，然后每一步对照清单执行。这样既保留了ReAct的灵活性，又避免了模型走一步看一步导致的路径漂移。第二处改进是强制反思机制。每执行完一个子任务，模型必须回答三个问题：结果是否符合预期？如果不符合，原因是什么？下一步应该如何调整？这个反思结果会写入短期记忆，作为下一步决策的参考。实测下来，加入强制反思后，复杂任务的完成率提升了大约30%，效果非常明显。下面是核心决策循环的简化代码实现：class DecisionLoop: def __init__(self, model, tools, memory): self.model = model self.tools = {t.name: t for t in tools} self.memory = memory self.max_iterations = 15 # 防止死循环 self.max_reflection_retries = 3 def run(self, task): plan = self.model.plan(task) # 第一步：生成全局计划 self.memory.add("plan", plan) for step in plan.steps: result = None for _ in range(self.max_reflection_retries): action = self.model.decide(step, self.memory.context) if action.type == "call_tool": result = self.execute_tool(action) self.memory.add("observation", result) elif action.type == "finish": return self.finalize(result) elif action.type == "need_help": return self.escalate(step, action.reason) reflection = self.model.reflect(step, result) self.memory.add("reflection", reflection) if reflection.status == "success": break # 反思结果不理想则修正后重试 step = self.model.revise(step, reflection.analysis) return self.finalize(self.memory.get("final_result"))这段代码看起来简单，但在实际项目中我花了很多时间调迭代次数上限、反思重试次数这些参数。迭代次数设置太小，复杂任务完不成；设置太大，不仅浪费token，而且模型可能在错误路径上越走越远。我最终用的是15次上限加3次反思重试的组合，这是几组不同配置对比测试后的结果。2.2 工具调用与参数化执行工具是Agent的"手"。没有工具的Agent只能聊天，有了工具才能做事。我的工具层设计核心是一个统一的注册机制，每个工具只需要实现三个方法：描述（给模型看的工具说明和参数schema）、执行（实际调用逻辑）、校验（对参数的合法性检查）。工具描述的质量直接影响模型的选择准确率。这里有个关键经验：工具描述要写清楚"什么时候用"和"什么时候不用"，而不仅仅是"这个工具能做什么"。比如代码执行工具，如果不加限制条件，模型可能在需要简单数学计算时也去执行一段Python代码，白白增加延迟和出错概率。我在描述里明确写了"仅当需要复杂计算或数据处理时使用，简单四则运算可直接计算"。参数Schema方面，我强烈建议使用JSON Schema格式，并且字段说明要具体。一个典型的问题是模型会把参数类型搞错，比如把数字传成字符串。解决办法是在Schema的description里给出明确的格式示例，比如"age: 整数类型，例如 25，不要加引号"。实践证明，给出正确示例比反复强调类型约束有效得多。工具执行时的错误处理也非常重要。我遇到过工具抛异常时整个Agent循环崩溃的情况，后来加了统一的异常捕获和错误信息格式化。任何工具执行失败，都要把错误信息转成模型能理解的文本，放回上下文让模型自己决定是重试、换参数还是换工具。这一步看似简单，却是Agent能否"自主"处理异常的关键。2.3 记忆管理与上下文窗口优化上下文窗口是Agent系统最硬的资源约束。大模型上下文长度有限，而Agent在执行过程中会不断产生中间结果、工具返回值、反思记录，如果不加控制，很快就会塞满上下文，而且塞满后模型表现会急剧下降。我的记忆管理策略分为三层。第一层是核心上下文，包含系统提示词、当前任务目标、最近的3轮决策记录，这部分始终保留。第二层是工作记忆，包含计划和反思结构，但采用滑动窗口，只保留最近的有效条目。第三层是长期存储，把重要的执行经验、领域知识存入向量数据库，需要时通过语义搜索召回。长期记忆这块踩过不少坑。最初我把所有执行历史都存入向量库，结果召回质量很差，因为存入了太多噪音。后来改为只存储两类内容：成功的决策路径和失败的教训。成功路径用于类似任务时的参考，失败教训用于避免重蹈覆辙。存储动作本身也由模型判定——每完成一个子任务，模型判断这段经验是否值得存入长期记忆。这样长期记忆的质量明显提升，召回的准确率也高了。关于上下文优化，还有一个实用的技巧：工具返回结果做摘要而不是全量塞入。比如搜索工具返回10条链接，全文可能几千字，但真正有用的可能就是每条链接的标题和摘要。我在工具层加了一个可选的"结果压缩"功能，让模型对原始结果先做摘要，再放入上下文。这样既保留了关键信息，又大幅节省了token。代价是多了一次模型调用，但延迟增加很小，绝对值。3. 多智能体协同机制深入解析3.1 为什么需要多智能体而不是一个超级Agent单Agent能解决简单任务，但面对复杂业务场景就力不从心。我在实践中感受到三个瓶颈。第一是上下文碎片化。一个Agent要同时处理多线程任务时，上下文很容易被不同任务的中间状态瓜分，导致每个任务都"记不清"。第二是职责耦合。比如一个系统既要做信息检索又要做代码生成，两个能力放在同一个Agent里，Prompt互相干扰，模型经常在错误的场景下调用错误的技能。第三是单点不可扩展。一个Agent的推理链越长，出错的概率越高，而且错误会在长链路中不断累积放大。多智能体架构的核心思想是分而治之：把复杂任务拆成多个子任务，分配给专门的Agent执行，通过协作机制把结果汇总。这个思路和软件工程里的微服务架构本质上是一样的——每个服务负责一件事，通过明确接口通信。只不过Agent之间的"接口"更灵活，它是一段自然语言消息。3.2 协作模式选型：编排式与对等式多智能体协作有两种主流模式，各有适用场景。编排式(Orchestrator模式)有一个中央控制器负责任务分解和结果汇总，工作Agent只执行自己的子任务并汇报结果。对等式(Peer-to-Peer模式)没有中央控制，Agent之间直接通信协商，适合需要多方博弈或逐步达成共识的场景。我在生产系统中用的是编排式为主、局部对等式为辅的混合架构。为什么？因为纯对等模式在真实业务中容易失控。Agent之间自由对话协商很酷，但对话可能发散、跑题，而且没有明确的收敛条件，任务可能永远完不成。编排式的好处是流程可控、步骤可追踪，每个子任务都有明确的负责人和截止状态。混合架构的落地方式是：主控Agent负责任务分解和调度，属于管理面；执行面分为检索Agent、分析Agent、生成Agent等多个角色，它们之间在某些特定环节可以直接通信。比如分析Agent发现检索结果不足，可以直接向检索Agent发起补充请求，不需要每次都经过主控中转。这减少了约40%的通信开销，同时保持了整体流程的可控性。混合架构的落地方式是：主控Agent负责任务分解和调度，属于管理面；执行面分为检索Agent、分析Agent、生成Agent等多个角色，它们之间在某些特定环节可以直接通信。比如分析Agent发现检索结果不足，可以直接向检索Agent发起补充请求，不需要每次都经过主控中转。这减少了约40%的通信开销，同时保持了整体流程的可控性。3.3 多Agent通信协议设计多Agent通信不能靠"自然语言随便聊"，必须有结构化的消息协议。我设计的消息格式包含五个核心字段：{ "msg_id": "msg_20250115_001", "sender": "orchestrator", "receiver": "agent_search", "msg_type": "task_assign", "content": { "task_id": "task_03", "instruction": "检索2024年AI代理技术综述论文", "constraints": {"max_results": 5, "time_range": "2024-01-01~2024-12-31"}, "context_refs": ["memory_ctx_27"] }, "timestamp": "2025-01-15T10:30:00Z" }这个结构的核心设计意图有三个。一是消息可追踪，每条消息有唯一ID，发送方和接收方明确，方便日志分析和问题回溯。二是内容结构化，指令、约束、上下文引用分开，避免模型把各种信息混在一起理解。三是上下文引用机制，通过context_refs引用共享上下文中的特定片段，不需要把大段上下文复制到每条消息里，省token也省时间。还有一个重要的设计决策：Agent之间的消息要不要经过LLM处理？我的答案是分情况。任务分配类消息，主控Agent生成时已经经过LLM，接收方直接解析即可；但状态查询、结果汇报这类轻量消息，我尽量用结构化格式直接传递，不经过LLM，降低延迟和成本。实测下来，这种"重消息走LLM，轻消息走协议"的混合方式，整体效率比全走LLM高了很多。3.4 共享工作区与状态一致性多Agent协同最大的技术难点是状态一致性问题。多个Agent并行工作时，每个Agent都有自己的上下文视图，它们对"当前任务进行到哪里了"的认知可能不一致。比如检索Agent认为已经返回了结果，但分析Agent没收到，或者收到了两个不同版本的结果。解决思路是引入共享工作区(Shared Workspace)。工作区里存放任务的全局状态、每个子任务的执行进度、以及各Agent产出的中间结果。所有Agent在工作区中读写数据，而不是通过消息把数据传来传去。消息里只传递引用和指令，不携带大段数据。class SharedWorkspace: def __init__(self, storage_backend): self.workspace_id = None self.storage = storage_backend self.lock = threading.RLock() def create_workspace(self, task): """创建任务专属工作区""" self.workspace_id = f"ws_{uuid.uuid4().hex[:8]}" self.storage.set(f"{self.workspace_id}:status", { "task": task, "progress": 0.0, "subtasks": {}, "created_at": time.time() }) return self.workspace_id def update_subtask(self, subtask_id, status, result): """原子更新子任务状态""" with self.lock: key = f"{self.workspace_id}:subtask:{subtask_id}" current = self.storage.get(key) or {} current.update({"status": status, "result": result, "updated_at": time.time()}) self.storage.set(key, current) def query_subtask(self, subtask_id): """查询子任务状态""" return self.storage.get(f"{self.workspace_id}:subtask:{subtask_id}")状态一致性这里有一个容易忽略的问题：写入冲突。两个Agent同时更新同一个子任务状态时，后写的会把先写的覆盖掉。我的解决方案是引入基于Redis的分布式锁，每个子任务更新前先获取锁，更新完释放。虽然增加了少量延迟，但避免了数据竞争导致的隐性bug。这个坑在单机测试时根本不会暴露，一上多线程或多实例就原形毕露，我花了整整两天排查才定位到。4. 实操过程与核心环节实现4.1 环境准备与技术栈清单如果你决定自己动手实现一套Agent系统，先准备好环境。我的技术栈如下，仅供参考，不必完全照搬：组件选型说明LLM底座支持function calling的大型模型可用OpenAI兼容API适配，也可接开源模型核心语言Python 3.10+Agent生态最成熟的生态Agent框架自研轻量框架参考LangChain设计，保留核心抽象消息队列Redis Stream多Agent通信与事件分发向量存储轻量向量数据库长期记忆与经验存储任务编排自研DAG执行器支持并行子任务调度可观测性结构化日志+调用链追踪决策过程全记录这个组合有一个核心考量：所有关键组件都选可替换的。比如向量存储，我封装了统一的接口，后面数据量大了随时可以换成其他更重量级的方案，业务代码一行都不用改。给Agent系统做技术选型，我强烈建议把"可替换性"放在优先级前列，因为Agent技术本身还在快速演进，今天的主流方案明天可能就被淘汰了。4.2 单Agent从零搭建的核心步骤从零搭建一个能用的单Agent，核心步骤有五步。第一步，定义工具接口和注册机制。每个工具继承统一基类，实现get_schema()和execute()方法。工具注册就是在启动时把所有工具实例放进一个注册表，决策循环通过名称索引。第二步，编写系统提示词。提示词要包含角色定位、决策规则、输出格式约定、安全约束。我的实践经验是提示词越具体越好，但不要写成死板模板。比如"你是数据分析助手"太笼统，模型不知道边界；而"你负责数据探索和可视化，不负责模型训练，当用户提出训练模型的需求时应明确说明能力边界"就清晰得多。第三步，实现决策循环框架。按照前面代码所示，实现计划、决策、执行、反思四个环节的状态机。这个阶段不要急着加复杂功能，先把最简闭环跑通。第四步，接入外部能力。我第一个接入的是搜索API，然后是代码执行器，再是数据库查询。每接入一个新工具，都要单独做测试，验证模型能否正确选择、传参和使用该工具。测试用统一的评测集跑，不靠人工试几个例子就收工。第五步，建立日志和追踪。从第一行代码开始就把每次决策的输入、模型输出、工具调用、执行结果全部记录下来。不要等到出了问题再补日志，Agent系统的调试难度远高于传统系统，没有完整日志几乎是没法排查问题的。4.3 多Agent系统装配与联调多Agent系统不是把几个单Agent堆在一起就行，装配过程有几个关键环节。我的实施顺序是：先搭主控Agent，跑通任务分解和结果汇总的基础流程。主控Agent本质上也是一个模型循环，只不过它的工具变成"分配子任务"和"查询子任务状态"。这个阶段先让主控能单独完成任务，不涉及真正的执行Agent。然后是注册执行Agent。每个执行Agent实例化后注册到Agent注册中心，主控能看到所有可用的Agent列表和它们的能力描述。这里和工具注册的逻辑一模一样，只是把"工具"换成了"Agent"。能力描述的重要性同样不言而喻——主控依据描述决定怎么分解和分配任务。接下来是通信联调。用固定的测试用例跑多Agent协作流程，重点检查：消息能否正确路由、任务状态能否正确更新、返回结果能否正确汇总。先串行跑通，再并行跑，最后加异常场景测试。联调阶段最常遇到的问题有两个。第一个是任务分配不合理——主控把本应该由一个Agent干完的活拆成了多个子任务，或者反过来把一个应该并行拆解的复杂任务留给了单个Agent。解决方法是优化子任务分解的提示词，并在评测集中加入专门的"任务拆解质量"测试项。第二个是Agent之间"踢皮球"——A Agent认为问题应该由B解决，B又推回给A。我的解决方案是每条消息都带上明确的deadline和责任人，超时未完成就上报给主控重新调度。4.4 评测体系与效果量化Agent系统不能只靠"感觉效果好"来验收，必须量化评测。我建了一套三层评测体系。第一层是任务成功率。给每个任务类型定义"完成"的标准，比如检索任务的标准是返回结果数量符合预期且包含必需字段；生成任务的标准是文本长度达标且主题相关度达到阈值。测试集包含50个典型任务和20个边界任务，自动跑完后统计成功率。第二层是决策质量评估。不只看结果，还看过程。工具调用次数是否合理？有没有不必要的重复调用？有没有在错误的场景用了错误的工具？这些指标用规则自动提取，结合人工抽样评估。决策质量是Agent系统长期性能的关键，很多系统任务成功率看着还行，但token浪费严重、效率低下，问题就出在这里。第三层是鲁棒性测试。故意给系统注入干扰——包括模糊指令、包含误导信息、工具返回异常结果。看系统能否正确应对而不是直接崩溃或跑偏。这一层测试最容易暴露问题，我第一次跑的时候成功率直接掉了一半，全是各种没预料到的边界情况。评测数据出来之后，优化方向就有了依据。我最常用也最有效的优化手段是失败案例回放：把失败案例的完整日志拉出来，看是哪个环节出的问题，然后针对性地改提示词、调参数或修逻辑。每轮优化后重新跑全套评测，防止"修了东墙补西墙"。5. 常见问题与排查技巧实录5.1 Agent陷入死循环的排查思路最让人头疼的问题是Agent陷入死循环——不停重复同样的行动、得到同样的结果、再做同样的决策。这个问题的根源通常是反思机制失效，模型没有意识到"当前状态没有变化"。我的排查路径是：先看日志中连续的迭代记录，确认循环的具体模式。如果是在同一个工具调用上循环，多半是工具返回的结果被模型误判为"还需要再调一次"。解决方法是给工具结果加明确的完成标志字段，让模型能一眼判断任务是否已完成。如果是决策环节循环，比如模型反复修改计划但越改越乱，就需要提高反思的判别标准，让系统更快地触发"停止并上报"分支。我在决策循环里加了一个布隆过滤器，记录已经尝试过的行动组合，如果新行动重复率超过阈值，直接强制终止并上报警主。这是保底机制，宁可让任务失败上报，也不能让系统无限空转烧token。5.2 工具选择错误的定位与修复模型选错工具是另一个高频问题。典型情况：应该用代码执行器算一个复杂公式，模型却去调搜索API；应该查数据库的，模型却试图从搜索结果里找答案。定位方法很简单：翻日志看模型在决策时的原始输出内容——它"想"了什么导致选错工具。如果是工具描述不够清晰导致的误解，修工具描述；如果是模型的推理过程暴露了它对任务类型的错误理解，修系统提示词中关于任务分类的引导。注意不要动不动就换模型或加规则，大部分工具选择错误都是信息不足或信息误导造成的，改善信息供给通常就能解决。5.3 上下文污染的识别与处理上下文污染指的是与当前任务无关的历史信息干扰了模型判断。症状是模型的行动开始"跑偏"，做的事和当前子任务目标关联变弱，甚至开始引用不相干的旧信息。识别方法：在日志里给每个决策步骤标注"决策依据的信息来源"，如果决策依据频繁来自很久以前的历史而不是当前状态，说明被污染的上下文在带偏模型。处理方法有两个方向：一是更激进地清理上下文，核心上下文只保留当前子任务的相关信息，历史经验放到长期记忆中按需召回；二是给上下文分段打标签，模型决策时强制引用指定标签的上下文片段，不相关的片段直接排除。5.4 多Agent消息超时与结果丢失处理多Agent协作中，消息超时和结果丢失是迟早会遇到的问题。尤其是在引入并行执行后，多个消息同时收发，很容易出现一方等结果超时、另一方任务实际已完成但结果没送达的情况。我采用的方案是"状态查询兜底"。每次等待子Agent结果时，不单纯阻塞等待消息返回，而是同时启动一个状态的周期性轮询。如果等了预期时间没收到消息，就主动查询共享工作区中的子任务状态，看是不是结果写入成功了但消息传递失败。实测这个兜底机制把协作流程的异常率降低了60%以上，因为大部分"消息丢失"其实是消息延迟而不是真的丢了。5.5 成本控制与token优化实操Agent系统的成本主要消耗在大量模型调用上。一个复杂任务跑下来动辄几十次调用，token消耗很大。我在成本优化上做了三件事。第一件事是减少不必要的模型调用。能用规则判断的就不让模型判断，比如工具参数类型校验、数值范围检查，这些在工具层用代码做，成本几乎为零。第二件事是合理选择模型规格。简单任务用轻量模型，复杂推理用强模型。我做了模型路由模块，根据任务复杂度预估动态选择模型，整体成本大约节省了40%。第三件事是结果缓存。相同或高度相似的查询直接复用历史结果，不用重新调用模型。缓存命中率在检索类任务里能达到30%左右，效果显著。6. 实操经验总结与扩展方向做这套系统的过程中，我最大的体会是：Agent系统的难点不在AI算法，而在工程化。模型推理能力只是地基，真正的挑战是把不可预测的模型行为嵌入到需要稳定可靠的业务系统中。这意味着你要在设计每一个环节时都问自己：模型这步如果出错了，系统会怎样？有没有兜底？能不能追踪到？几个具体的经验分享给正在实践的人。第一个经验是关于迭代顺序的。不要一上来就追求多Agent，先把单Agent做到足够稳定。我见过太多团队单Agent还一塌糊涂就匆忙上多Agent，结果问题翻倍，调试难度几何级增长。单Agent的决策循环、工具调用、记忆管理都跑通了，再考虑协作层的设计。第二个经验是评测集要尽早建。我第一次建评测集是在系统V1完成之后，导致早期迭代缺少量化反馈，走了不少弯路。如果重新来做，我会在系统雏形阶段就建一个20条左右的冒烟测试集，每次改动都跑一遍，作为回归测试。第三个经验是日志设计要极致。Agent系统的每一次决策都是一次不可复现的事件，因为模型输出有随机性。这意味着事后日志几乎是唯一的排查依据。我的日志规范是：每个决策步骤记录时间戳、输入上下文摘要、模型输出全文、工具调用和结果、反思结论。宁可在日志上多花存储成本，也不能在排查问题时抓瞎。这个系统的后续扩展方向，我个人看好的有三个。第一是多Agent能力的动态扩展。当前的Agent角色是预先定义好的，下一步是让系统能根据任务需要动态创建新的Agent角色，这需要把Agent的角色定义也变成可推理、可生成的内容。第二是更强的人类反馈机制。当前系统主要靠自动评测和预设规则纠偏，后续想加入人在回路(Human-in-the-Loop)机制，在关键决策节点引入人工审批或修正，这对业务系统的安全性提升会很明显。第三是跨会话的学习能力。目前的长期记忆还是偏向经验存储，下一步要做好经验的自动归纳和抽象，让系统从"记住具体案例"升级为"掌握通用方法"。最后再分享一个我踩过最深的坑：别迷信模板和现成框架。我最初也是从现成框架起步，觉得省事，但越到后期越觉得被框架束缚，很多针对业务场景的优化根本无从下手。后来下决心重写核心逻辑，虽然前期花了不少时间，但换来的是完全可控、可扩展的自研系统。在Agent这个快速演进的领域，深入理解底层机制、保持架构自主，可能比用哪个框架更重要。
做自主决策AI代理系统这件事，我前前后后折腾了将近一年。从最初只是给大模型套一层工具调用，到后来做成能自主规划、自我纠错、甚至多个代理之间互相协作的完整系统，踩过的坑比写过的代码还多。这个项目不是某个课程作业，也不是论文里的Demo，而是真正跑在业务场景里的系统。它解决的核心问题很简单：让AI不是"你问一句它答一句"，而是给它一个目标，它能自己拆解任务、调用工具、评估结果、修正方向，直到把活干完。这篇文章我会从零开始，把整个系统从基础架构到多智能体协同的完整实践过程梳理一遍。内容包括单智能体的核心设计、自主决策循环的实现方式、多智能体之间的通信与协作机制，以及我在实际调参和排错过程中积累的经验。适合三类读者：准备把大模型接入业务系统的工程师、已经在做Agent但总感觉效果不稳定的开发者、以及对多智能体协作机制感兴趣的架构师。先说一句实话：网上关于Agent的教程很多，但大多数停留在"用LangChain调几个工具"的层面。真正生产级的Agent系统，难点根本不在调用模型，而在于决策框架怎么设计、状态怎么管理、错误怎么恢复、多个代理之间怎么不打架。这些才是本文想讲清楚的东西。1. 整体架构设计与核心概念拆解1.1 自主决策AI代理的本质是什么先把概念捋清楚。一个自主决策AI代理，本质上是一个"感知-决策-行动"的闭环系统。它接收一个目标输入，通过大模型的推理能力拆解出执行计划，然后调用外部工具或API执行具体操作，再根据执行结果评估进展，最后决定是继续、调整还是结束。这个闭环和传统软件的工作方式有本质区别。传统程序是开发者预先写死所有分支逻辑，而Agent系统把"下一步做什么"的决策权交给了模型。这意味着同一套系统在面对不同输入时，可能走出完全不同的执行路径。这个特点既是Agent最大的价值——灵活、通用、能处理非预期情况，也是它最难搞的地方——不可预测、难调试、容易失控。我在设计系统时首先明确了一个原则：不要把Agent做成"黑盒"。虽然决策由模型做出，但整个决策过程必须是可观测、可干预、可回放的。这个原则贯穿了后续所有架构决策。1.2 系统分层架构设计整个系统我分成了四层，每一层职责单一，层与层之间通过明确定义的接口通信。这四层分别是接口层、决策层、执行层和记忆层。接口层负责与外部世界对接，包括用户输入解析、最终结果格式化输出、以及各种外部服务的接入。决策层是核心，包含任务规划器、工具选择器和自我反思模块。执行层封装所有Agent能调用的工具，包括搜索、代码执行、数据库查询、API调用等。记忆层管理短期对话上下文和长期知识存储。这个分层设计的核心考量是可替换性。比如决策层用的模型，从早期的GPT-3.5换到后来的GPT-4，再到开源模型，只需要替换决策层内部的模型适配器，其他层完全不动。工具层更是如此，每接入一个新工具只需要实现统一的工具接口，注册进去就行，决策层不需要做任何修改。┌─────────────────────────────────┐ │ 接口层：用户输入解析 / 结果输出 │ ├─────────────────────────────────┤ │ 决策层：任务规划 / 工具选择 / 反思 │ ├─────────────────────────────────┤ │ 执行层：工具注册 / 执行 / 错误处理 │ ├─────────────────────────────────┤ │ 记忆层：上下文管理 / 长期存储 │ └─────────────────────────────────┘有人可能会问，为什么不直接用一个大的提示词把所有功能都塞进去？我也试过。最开始确实是一个巨大的Prompt搞定所有事，但随着功能增多，Prompt越来越难维护，改一个地方影响一片，而且模型经常在复杂任务中"迷失方向"。分层之后，每层的Prompt可以独立优化和测试，出了问题也能快速定位。这是第一个值得分享的经验：Agent系统里，架构清晰比功能丰富更重要。1.3 技术选型的底层逻辑技术选型这块，我走了不少弯路，这里把最终方案和选择理由说清楚。大模型底座选了支持函数调用(function calling)的模型，这是做Agent的基础能力。如果没有原生函数调用支持，就需要在Prompt里手动规定输出格式然后用解析器去抠，效果差很多。当时对比了多个模型，最终选了能稳定返回结构化工具调用参数的方案，这一点对后续系统可靠性影响巨大。Agent框架方面，我没有直接用现成的LangChain或AutoGen，而是在其基础上做了大量自研封装。原因有三个：第一，现成框架抽象层次太高，出了问题很难追踪到底层逻辑；第二，框架自带的工具调用机制不够灵活，我需要自定义决策循环；第三，生产环境的特殊需求——如超时控制、并发限制、审计日志——框架原生支持都不到位。我的做法是参考LangChain的设计思想，自己实现了一套轻量级的核心逻辑，只保留必要的抽象。向量数据库选了支持HNSW索引的轻量级方案，用来存长期记忆和工具使用经验。选它主要是因为部署运维简单，性能对业务规模足够了。数据量大的场景可以换成更重的方案，核心接口保持一致就行。这也是为什么我一直强调接口抽象的重要性——技术栈随时可以换，架构不能轻易动。2. 自主决策机制的核心实现2.1 决策循环：从ReAct到自定义改进自主决策的核心是一个循环，业界标准的参考模式是ReAct(Reasoning + Acting)，也就是"推理-行动-观察"交替进行。模型先思考当前状态，决定采取什么行动，执行行动后观察结果，再基于新状态继续推理。我基于ReAct做了两处关键改进。第一处是增加了明确的计划阶段。原始ReAct模式中模型每一步只做局部决策，没有全局规划。我在循环开始前让模型先生成一份完整的任务清单，然后每一步对照清单执行。这样既保留了ReAct的灵活性，又避免了模型走一步看一步导致的路径漂移。第二处改进是强制反思机制。每执行完一个子任务，模型必须回答三个问题：结果是否符合预期？如果不符合，原因是什么？下一步应该如何调整？这个反思结果会写入短期记忆，作为下一步决策的参考。实测下来，加入强制反思后，复杂任务的完成率提升了大约30%，效果非常明显。下面是核心决策循环的简化代码实现：class DecisionLoop: def __init__(self, model, tools, memory): self.model = model self.tools = {t.name: t for t in tools} self.memory = memory self.max_iterations = 15 # 防止死循环 self.max_reflection_retries = 3 def run(self, task): plan = self.model.plan(task) # 第一步：生成全局计划 self.memory.add("plan", plan) for step in plan.steps: result = None for _ in range(self.max_reflection_retries): action = self.model.decide(step, self.memory.context) if action.type == "call_tool": result = self.execute_tool(action) self.memory.add("observation", result) elif action.type == "finish": return self.finalize(result) elif action.type == "need_help": return self.escalate(step, action.reason) reflection = self.model.reflect(step, result) self.memory.add("reflection", reflection) if reflection.status == "success": break # 反思结果不理想则修正后重试 step = self.model.revise(step, reflection.analysis) return self.finalize(self.memory.get("final_result"))这段代码看起来简单，但在实际项目中我花了很多时间调迭代次数上限、反思重试次数这些参数。迭代次数设置太小，复杂任务完不成；设置太大，不仅浪费token，而且模型可能在错误路径上越走越远。我最终用的是15次上限加3次反思重试的组合，这是几组不同配置对比测试后的结果。2.2 工具调用与参数化执行工具是Agent的"手"。没有工具的Agent只能聊天，有了工具才能做事。我的工具层设计核心是一个统一的注册机制，每个工具只需要实现三个方法：描述（给模型看的工具说明和参数schema）、执行（实际调用逻辑）、校验（对参数的合法性检查）。工具描述的质量直接影响模型的选择准确率。这里有个关键经验：工具描述要写清楚"什么时候用"和"什么时候不用"，而不仅仅是"这个工具能做什么"。比如代码执行工具，如果不加限制条件，模型可能在需要简单数学计算时也去执行一段Python代码，白白增加延迟和出错概率。我在描述里明确写了"仅当需要复杂计算或数据处理时使用，简单四则运算可直接计算"。参数Schema方面，我强烈建议使用JSON Schema格式，并且字段说明要具体。一个典型的问题是模型会把参数类型搞错，比如把数字传成字符串。解决办法是在Schema的description里给出明确的格式示例，比如"age: 整数类型，例如 25，不要加引号"。实践证明，给出正确示例比反复强调类型约束有效得多。工具执行时的错误处理也非常重要。我遇到过工具抛异常时整个Agent循环崩溃的情况，后来加了统一的异常捕获和错误信息格式化。任何工具执行失败，都要把错误信息转成模型能理解的文本，放回上下文让模型自己决定是重试、换参数还是换工具。这一步看似简单，却是Agent能否"自主"处理异常的关键。2.3 记忆管理与上下文窗口优化上下文窗口是Agent系统最硬的资源约束。大模型上下文长度有限，而Agent在执行过程中会不断产生中间结果、工具返回值、反思记录，如果不加控制，很快就会塞满上下文，而且塞满后模型表现会急剧下降。我的记忆管理策略分为三层。第一层是核心上下文，包含系统提示词、当前任务目标、最近的3轮决策记录，这部分始终保留。第二层是工作记忆，包含计划和反思结构，但采用滑动窗口，只保留最近的有效条目。第三层是长期存储，把重要的执行经验、领域知识存入向量数据库，需要时通过语义搜索召回。长期记忆这块踩过不少坑。最初我把所有执行历史都存入向量库，结果召回质量很差，因为存入了太多噪音。后来改为只存储两类内容：成功的决策路径和失败的教训。成功路径用于类似任务时的参考，失败教训用于避免重蹈覆辙。存储动作本身也由模型判定——每完成一个子任务，模型判断这段经验是否值得存入长期记忆。这样长期记忆的质量明显提升，召回的准确率也高了。关于上下文优化，还有一个实用的技巧：工具返回结果做摘要而不是全量塞入。比如搜索工具返回10条链接，全文可能几千字，但真正有用的可能就是每条链接的标题和摘要。我在工具层加了一个可选的"结果压缩"功能，让模型对原始结果先做摘要，再放入上下文。这样既保留了关键信息，又大幅节省了token。代价是多了一次模型调用，但延迟增加很小，绝对值。3. 多智能体协同机制深入解析3.1 为什么需要多智能体而不是一个超级Agent单Agent能解决简单任务，但面对复杂业务场景就力不从心。我在实践中感受到三个瓶颈。第一是上下文碎片化。一个Agent要同时处理多线程任务时，上下文很容易被不同任务的中间状态瓜分，导致每个任务都"记不清"。第二是职责耦合。比如一个系统既要做信息检索又要做代码生成，两个能力放在同一个Agent里，Prompt互相干扰，模型经常在错误的场景下调用错误的技能。第三是单点不可扩展。一个Agent的推理链越长，出错的概率越高，而且错误会在长链路中不断累积放大。多智能体架构的核心思想是分而治之：把复杂任务拆成多个子任务，分配给专门的Agent执行，通过协作机制把结果汇总。这个思路和软件工程里的微服务架构本质上是一样的——每个服务负责一件事，通过明确接口通信。只不过Agent之间的"接口"更灵活，它是一段自然语言消息。3.2 协作模式选型：编排式与对等式多智能体协作有两种主流模式，各有适用场景。编排式(Orchestrator模式)有一个中央控制器负责任务分解和结果汇总，工作Agent只执行自己的子任务并汇报结果。对等式(Peer-to-Peer模式)没有中央控制，Agent之间直接通信协商，适合需要多方博弈或逐步达成共识的场景。我在生产系统中用的是编排式为主、局部对等式为辅的混合架构。为什么？因为纯对等模式在真实业务中容易失控。Agent之间自由对话协商很酷，但对话可能发散、跑题，而且没有明确的收敛条件，任务可能永远完不成。编排式的好处是流程可控、步骤可追踪，每个子任务都有明确的负责人和截止状态。混合架构的落地方式是：主控Agent负责任务分解和调度，属于管理面；执行面分为检索Agent、分析Agent、生成Agent等多个角色，它们之间在某些特定环节可以直接通信。比如分析Agent发现检索结果不足，可以直接向检索Agent发起补充请求，不需要每次都经过主控中转。这减少了约40%的通信开销，同时保持了整体流程的可控性。混合架构的落地方式是：主控Agent负责任务分解和调度，属于管理面；执行面分为检索Agent、分析Agent、生成Agent等多个角色，它们之间在某些特定环节可以直接通信。比如分析Agent发现检索结果不足，可以直接向检索Agent发起补充请求，不需要每次都经过主控中转。这减少了约40%的通信开销，同时保持了整体流程的可控性。3.3 多Agent通信协议设计多Agent通信不能靠"自然语言随便聊"，必须有结构化的消息协议。我设计的消息格式包含五个核心字段：{ "msg_id": "msg_20250115_001", "sender": "orchestrator", "receiver": "agent_search", "msg_type": "task_assign", "content": { "task_id": "task_03", "instruction": "检索2024年AI代理技术综述论文", "constraints": {"max_results": 5, "time_range": "2024-01-01~2024-12-31"}, "context_refs": ["memory_ctx_27"] }, "timestamp": "2025-01-15T10:30:00Z" }这个结构的核心设计意图有三个。一是消息可追踪，每条消息有唯一ID，发送方和接收方明确，方便日志分析和问题回溯。二是内容结构化，指令、约束、上下文引用分开，避免模型把各种信息混在一起理解。三是上下文引用机制，通过context_refs引用共享上下文中的特定片段，不需要把大段上下文复制到每条消息里，省token也省时间。还有一个重要的设计决策：Agent之间的消息要不要经过LLM处理？我的答案是分情况。任务分配类消息，主控Agent生成时已经经过LLM，接收方直接解析即可；但状态查询、结果汇报这类轻量消息，我尽量用结构化格式直接传递，不经过LLM，降低延迟和成本。实测下来，这种"重消息走LLM，轻消息走协议"的混合方式，整体效率比全走LLM高了很多。3.4 共享工作区与状态一致性多Agent协同最大的技术难点是状态一致性问题。多个Agent并行工作时，每个Agent都有自己的上下文视图，它们对"当前任务进行到哪里了"的认知可能不一致。比如检索Agent认为已经返回了结果，但分析Agent没收到，或者收到了两个不同版本的结果。解决思路是引入共享工作区(Shared Workspace)。工作区里存放任务的全局状态、每个子任务的执行进度、以及各Agent产出的中间结果。所有Agent在工作区中读写数据，而不是通过消息把数据传来传去。消息里只传递引用和指令，不携带大段数据。class SharedWorkspace: def __init__(self, storage_backend): self.workspace_id = None self.storage = storage_backend self.lock = threading.RLock() def create_workspace(self, task): """创建任务专属工作区""" self.workspace_id = f"ws_{uuid.uuid4().hex[:8]}" self.storage.set(f"{self.workspace_id}:status", { "task": task, "progress": 0.0, "subtasks": {}, "created_at": time.time() }) return self.workspace_id def update_subtask(self, subtask_id, status, result): """原子更新子任务状态""" with self.lock: key = f"{self.workspace_id}:subtask:{subtask_id}" current = self.storage.get(key) or {} current.update({"status": status, "result": result, "updated_at": time.time()}) self.storage.set(key, current) def query_subtask(self, subtask_id): """查询子任务状态""" return self.storage.get(f"{self.workspace_id}:subtask:{subtask_id}")状态一致性这里有一个容易忽略的问题：写入冲突。两个Agent同时更新同一个子任务状态时，后写的会把先写的覆盖掉。我的解决方案是引入基于Redis的分布式锁，每个子任务更新前先获取锁，更新完释放。虽然增加了少量延迟，但避免了数据竞争导致的隐性bug。这个坑在单机测试时根本不会暴露，一上多线程或多实例就原形毕露，我花了整整两天排查才定位到。4. 实操过程与核心环节实现4.1 环境准备与技术栈清单如果你决定自己动手实现一套Agent系统，先准备好环境。我的技术栈如下，仅供参考，不必完全照搬：组件选型说明LLM底座支持function calling的大型模型可用OpenAI兼容API适配，也可接开源模型核心语言Python 3.10+Agent生态最成熟的生态Agent框架自研轻量框架参考LangChain设计，保留核心抽象消息队列Redis Stream多Agent通信与事件分发向量存储轻量向量数据库长期记忆与经验存储任务编排自研DAG执行器支持并行子任务调度可观测性结构化日志+调用链追踪决策过程全记录这个组合有一个核心考量：所有关键组件都选可替换的。比如向量存储，我封装了统一的接口，后面数据量大了随时可以换成其他更重量级的方案，业务代码一行都不用改。给Agent系统做技术选型，我强烈建议把"可替换性"放在优先级前列，因为Agent技术本身还在快速演进，今天的主流方案明天可能就被淘汰了。4.2 单Agent从零搭建的核心步骤从零搭建一个能用的单Agent，核心步骤有五步。第一步，定义工具接口和注册机制。每个工具继承统一基类，实现get_schema()和execute()方法。工具注册就是在启动时把所有工具实例放进一个注册表，决策循环通过名称索引。第二步，编写系统提示词。提示词要包含角色定位、决策规则、输出格式约定、安全约束。我的实践经验是提示词越具体越好，但不要写成死板模板。比如"你是数据分析助手"太笼统，模型不知道边界；而"你负责数据探索和可视化，不负责模型训练，当用户提出训练模型的需求时应明确说明能力边界"就清晰得多。第三步，实现决策循环框架。按照前面代码所示，实现计划、决策、执行、反思四个环节的状态机。这个阶段不要急着加复杂功能，先把最简闭环跑通。第四步，接入外部能力。我第一个接入的是搜索API，然后是代码执行器，再是数据库查询。每接入一个新工具，都要单独做测试，验证模型能否正确选择、传参和使用该工具。测试用统一的评测集跑，不靠人工试几个例子就收工。第五步，建立日志和追踪。从第一行代码开始就把每次决策的输入、模型输出、工具调用、执行结果全部记录下来。不要等到出了问题再补日志，Agent系统的调试难度远高于传统系统，没有完整日志几乎是没法排查问题的。4.3 多Agent系统装配与联调多Agent系统不是把几个单Agent堆在一起就行，装配过程有几个关键环节。我的实施顺序是：先搭主控Agent，跑通任务分解和结果汇总的基础流程。主控Agent本质上也是一个模型循环，只不过它的工具变成"分配子任务"和"查询子任务状态"。这个阶段先让主控能单独完成任务，不涉及真正的执行Agent。然后是注册执行Agent。每个执行Agent实例化后注册到Agent注册中心，主控能看到所有可用的Agent列表和它们的能力描述。这里和工具注册的逻辑一模一样，只是把"工具"换成了"Agent"。能力描述的重要性同样不言而喻——主控依据描述决定怎么分解和分配任务。接下来是通信联调。用固定的测试用例跑多Agent协作流程，重点检查：消息能否正确路由、任务状态能否正确更新、返回结果能否正确汇总。先串行跑通，再并行跑，最后加异常场景测试。联调阶段最常遇到的问题有两个。第一个是任务分配不合理——主控把本应该由一个Agent干完的活拆成了多个子任务，或者反过来把一个应该并行拆解的复杂任务留给了单个Agent。解决方法是优化子任务分解的提示词，并在评测集中加入专门的"任务拆解质量"测试项。第二个是Agent之间"踢皮球"——A Agent认为问题应该由B解决，B又推回给A。我的解决方案是每条消息都带上明确的deadline和责任人，超时未完成就上报给主控重新调度。4.4 评测体系与效果量化Agent系统不能只靠"感觉效果好"来验收，必须量化评测。我建了一套三层评测体系。第一层是任务成功率。给每个任务类型定义"完成"的标准，比如检索任务的标准是返回结果数量符合预期且包含必需字段；生成任务的标准是文本长度达标且主题相关度达到阈值。测试集包含50个典型任务和20个边界任务，自动跑完后统计成功率。第二层是决策质量评估。不只看结果，还看过程。工具调用次数是否合理？有没有不必要的重复调用？有没有在错误的场景用了错误的工具？这些指标用规则自动提取，结合人工抽样评估。决策质量是Agent系统长期性能的关键，很多系统任务成功率看着还行，但token浪费严重、效率低下，问题就出在这里。第三层是鲁棒性测试。故意给系统注入干扰——包括模糊指令、包含误导信息、工具返回异常结果。看系统能否正确应对而不是直接崩溃或跑偏。这一层测试最容易暴露问题，我第一次跑的时候成功率直接掉了一半，全是各种没预料到的边界情况。评测数据出来之后，优化方向就有了依据。我最常用也最有效的优化手段是失败案例回放：把失败案例的完整日志拉出来，看是哪个环节出的问题，然后针对性地改提示词、调参数或修逻辑。每轮优化后重新跑全套评测，防止"修了东墙补西墙"。5. 常见问题与排查技巧实录5.1 Agent陷入死循环的排查思路最让人头疼的问题是Agent陷入死循环——不停重复同样的行动、得到同样的结果、再做同样的决策。这个问题的根源通常是反思机制失效，模型没有意识到"当前状态没有变化"。我的排查路径是：先看日志中连续的迭代记录，确认循环的具体模式。如果是在同一个工具调用上循环，多半是工具返回的结果被模型误判为"还需要再调一次"。解决方法是给工具结果加明确的完成标志字段，让模型能一眼判断任务是否已完成。如果是决策环节循环，比如模型反复修改计划但越改越乱，就需要提高反思的判别标准，让系统更快地触发"停止并上报"分支。我在决策循环里加了一个布隆过滤器，记录已经尝试过的行动组合，如果新行动重复率超过阈值，直接强制终止并上报警主。这是保底机制，宁可让任务失败上报，也不能让系统无限空转烧token。5.2 工具选择错误的定位与修复模型选错工具是另一个高频问题。典型情况：应该用代码执行器算一个复杂公式，模型却去调搜索API；应该查数据库的，模型却试图从搜索结果里找答案。定位方法很简单：翻日志看模型在决策时的原始输出内容——它"想"了什么导致选错工具。如果是工具描述不够清晰导致的误解，修工具描述；如果是模型的推理过程暴露了它对任务类型的错误理解，修系统提示词中关于任务分类的引导。注意不要动不动就换模型或加规则，大部分工具选择错误都是信息不足或信息误导造成的，改善信息供给通常就能解决。5.3 上下文污染的识别与处理上下文污染指的是与当前任务无关的历史信息干扰了模型判断。症状是模型的行动开始"跑偏"，做的事和当前子任务目标关联变弱，甚至开始引用不相干的旧信息。识别方法：在日志里给每个决策步骤标注"决策依据的信息来源"，如果决策依据频繁来自很久以前的历史而不是当前状态，说明被污染的上下文在带偏模型。处理方法有两个方向：一是更激进地清理上下文，核心上下文只保留当前子任务的相关信息，历史经验放到长期记忆中按需召回；二是给上下文分段打标签，模型决策时强制引用指定标签的上下文片段，不相关的片段直接排除。5.4 多Agent消息超时与结果丢失处理多Agent协作中，消息超时和结果丢失是迟早会遇到的问题。尤其是在引入并行执行后，多个消息同时收发，很容易出现一方等结果超时、另一方任务实际已完成但结果没送达的情况。我采用的方案是"状态查询兜底"。每次等待子Agent结果时，不单纯阻塞等待消息返回，而是同时启动一个状态的周期性轮询。如果等了预期时间没收到消息，就主动查询共享工作区中的子任务状态，看是不是结果写入成功了但消息传递失败。实测这个兜底机制把协作流程的异常率降低了60%以上，因为大部分"消息丢失"其实是消息延迟而不是真的丢了。5.5 成本控制与token优化实操Agent系统的成本主要消耗在大量模型调用上。一个复杂任务跑下来动辄几十次调用，token消耗很大。我在成本优化上做了三件事。第一件事是减少不必要的模型调用。能用规则判断的就不让模型判断，比如工具参数类型校验、数值范围检查，这些在工具层用代码做，成本几乎为零。第二件事是合理选择模型规格。简单任务用轻量模型，复杂推理用强模型。我做了模型路由模块，根据任务复杂度预估动态选择模型，整体成本大约节省了40%。第三件事是结果缓存。相同或高度相似的查询直接复用历史结果，不用重新调用模型。缓存命中率在检索类任务里能达到30%左右，效果显著。6. 实操经验总结与扩展方向做这套系统的过程中，我最大的体会是：Agent系统的难点不在AI算法，而在工程化。模型推理能力只是地基，真正的挑战是把不可预测的模型行为嵌入到需要稳定可靠的业务系统中。这意味着你要在设计每一个环节时都问自己：模型这步如果出错了，系统会怎样？有没有兜底？能不能追踪到？几个具体的经验分享给正在实践的人。第一个经验是关于迭代顺序的。不要一上来就追求多Agent，先把单Agent做到足够稳定。我见过太多团队单Agent还一塌糊涂就匆忙上多Agent，结果问题翻倍，调试难度几何级增长。单Agent的决策循环、工具调用、记忆管理都跑通了，再考虑协作层的设计。第二个经验是评测集要尽早建。我第一次建评测集是在系统V1完成之后，导致早期迭代缺少量化反馈，走了不少弯路。如果重新来做，我会在系统雏形阶段就建一个20条左右的冒烟测试集，每次改动都跑一遍，作为回归测试。第三个经验是日志设计要极致。Agent系统的每一次决策都是一次不可复现的事件，因为模型输出有随机性。这意味着事后日志几乎是唯一的排查依据。我的日志规范是：每个决策步骤记录时间戳、输入上下文摘要、模型输出全文、工具调用和结果、反思结论。宁可在日志上多花存储成本，也不能在排查问题时抓瞎。这个系统的后续扩展方向，我个人看好的有三个。第一是多Agent能力的动态扩展。当前的Agent角色是预先定义好的，下一步是让系统能根据任务需要动态创建新的Agent角色，这需要把Agent的角色定义也变成可推理、可生成的内容。第二是更强的人类反馈机制。当前系统主要靠自动评测和预设规则纠偏，后续想加入人在回路(Human-in-the-Loop)机制，在关键决策节点引入人工审批或修正，这对业务系统的安全性提升会很明显。第三是跨会话的学习能力。目前的长期记忆还是偏向经验存储，下一步要做好经验的自动归纳和抽象，让系统从"记住具体案例"升级为"掌握通用方法"。最后再分享一个我踩过最深的坑：别迷信模板和现成框架。我最初也是从现成框架起步，觉得省事，但越到后期越觉得被框架束缚，很多针对业务场景的优化根本无从下手。后来下决心重写核心逻辑，虽然前期花了不少时间，但换来的是完全可控、可扩展的自研系统。在Agent这个快速演进的领域，深入理解底层机制、保持架构自主，可能比用哪个框架更重要。