AI Agent 这个词在过去一年里被反复提及但真正动手搭过的人都知道从能跑通 Demo到能扛住真实业务之间隔着一道巨大的鸿沟。我见过太多团队兴冲冲地接上大模型、挂几个工具结果上线三天就被各种边界情况打穿——循环停不下来、工具调用参数错乱、上下文越滚越长最后直接爆掉。问题的根源往往不在于模型本身不够强而在于对 Agent 的工程结构缺乏系统认知。这篇文章想做的事情很具体把 AI Agent 从概念拆到零件从七个核心要素讲到七个关键决策点让正在做 Agent 开发的人能对照自己的项目找到短板也让刚入门的人少走几个月的弯路。全文围绕 LLM、工具调用、循环机制、记忆管理、编排框架这些关键词展开不堆术语只讲能落地的东西。1. 先搞清楚 Agent 和普通 LLM 调用的本质区别1.1 一次调用和持续决策的分水岭很多人第一次接触 Agent 的时候会觉得不就是让大模型多调几次工具吗。这个理解不算错但漏掉了最关键的一层普通 LLM 调用是单轮映射输入一段文本输出一段文本结束。Agent 是持续决策循环它需要在每一轮根据当前状态判断我下一步该干什么然后执行、观察结果、再判断直到任务完成或者触发终止条件。这个区别看起来只是多几轮的问题但工程上的复杂度是指数级上升的。单轮调用你只需要关心 prompt 质量和输出格式持续循环你要关心状态管理、终止条件、错误恢复、上下文预算、工具调用的幂等性、并发安全等等。我经常用一个类比来解释普通 LLM 调用像是你问一个顾问一个问题他给你一个答案Agent 像是你雇了一个实习生你给他一个目标他自己去查资料、打电话、填表格、发邮件中间可能出错、可能卡住、可能理解偏了你得设计一套机制让他能自己跑完并且不出大乱子。所以当你决定要做 Agent 的时候第一个要问自己的问题不是用哪个框架而是我的任务是否真的需要多步自主决策。如果任务本身是确定性的、步骤固定的那用工作流引擎或者简单的链式调用就够了硬上 Agent 反而增加不稳定因素。这个判断决定了后面所有的架构选择。1.2 七要素拆解Agent 到底由哪些零件组成把 Agent 拆开来看我认为核心要素有七个。这七个不是学术定义是我从实际项目里总结出来的工程视角的拆解。第一个是 LLM 本身也就是决策大脑。它负责理解任务、规划步骤、选择工具、生成参数、判断是否完成。选模型的时候不要只看 benchmark 分数要看它在函数调用格式遵循和多步推理稳定性上的表现。有些模型单轮问答很强但一到需要输出结构化工具调用参数的时候就频繁出错这种就不适合做 Agent 的主控模型。第二个是工具集。工具就是 Agent 能调用的外部能力可以是搜索、数据库查询、API 调用、代码执行、文件操作等等。工具的设计质量直接决定 Agent 的上限。一个常见的错误是把工具做得太粗粒度比如一个处理订单的工具内部藏了十几个步骤Agent 根本没法在中间做判断正确的做法是把工具拆到合适的粒度让 Agent 有足够的决策空间但又不能太细碎导致调用轮次爆炸。第三个是记忆系统。记忆分短期和长期。短期记忆就是当前对话的上下文长期记忆是跨会话持久化的信息。很多 Agent 项目一开始不重视记忆等到上下文塞满了才开始补救这时候架构已经定型了改起来很痛苦。第四个是循环控制机制。这是 Agent 的发动机决定了它怎么迭代、什么时候停、出错了怎么办。循环控制做不好要么死循环烧钱要么过早终止任务没完成。第五个是提示词与指令体系。Agent 的 system prompt 比普通对话的 prompt 复杂得多它需要定义角色、能力边界、工具使用规范、输出格式、异常处理策略等等。这是一套完整的员工手册不是一句话的事。第六个是状态与上下文管理。Agent 在执行过程中会产生大量中间状态已经调用了哪些工具、得到了什么结果、当前进展到哪一步。这些状态怎么存储、怎么裁剪、怎么在下一轮注入是工程实现的核心难点之一。第七个是安全与护栏。包括输入过滤、输出校验、工具调用的权限控制、敏感操作的二次确认等等。这一块在 Demo 阶段经常被忽略但上线之后是保命的。这七个要素不是孤立的它们之间有大量的交互和耦合。比如记忆系统会影响上下文管理策略工具粒度会影响循环控制的复杂度提示词体系又和状态管理紧密相关。理解这些耦合关系是做好 Agent 工程实现的前提。1.3 为什么能跑和能扛之间差了一整个架构我见过不少项目Demo 阶段非常惊艳演示的时候流畅得不行但一上真实流量就各种问题。根本原因在于 Demo 阶段的输入是精心挑选的、环境是理想化的、并发是一。真实场景下用户输入千奇百怪、外部 API 会超时、模型会抽风、并发上来之后状态会串。从能跑到能扛需要补的课包括错误重试与降级策略、超时控制、并发隔离、上下文预算管理、工具调用的幂等设计、可观测性建设。这些东西在 Demo 里一个都不需要但在生产环境里一个都不能少。所以我在做 Agent 项目的时候从来不会把 Demo 跑通当作里程碑真正的里程碑是在模拟真实流量的压测下稳定运行。2. 七个决策点搭建 Agent 时必须做的架构选择2.1 决策点一自主程度——从固定流程到完全自主的光谱第一个要做的决策是你的 Agent 到底要多自主这不是一个二元选择而是一个光谱。最左端是固定工作流步骤完全预设LLM 只在每个步骤内部做具体的文本处理。这种最稳定但灵活性最差。往右一点是有限分支LLM 可以在预设的几个分支里做选择。再往右是动态规划LLM 自己决定步骤顺序和工具选择。最右端是完全自主LLM 自己定义目标、自己拆解、自己执行、自己判断完成。大部分生产级 Agent 应该落在中间偏右的位置。完全自主听起来很酷但实际项目中你会希望有明确的边界和检查点。我的经验是核心流程用固定编排保证稳定性在需要灵活性的节点上放权给 LLM 做决策。这样既保证了主流程可控又保留了应对复杂情况的弹性。具体怎么判断看你的任务是否有明确的成功标准。如果有那就在关键节点设置验证LLM 的自由度限制在怎么达到而不是达到什么。如果任务本身是开放式的比如帮我调研一下这个市场那就需要更高的自主度但同时也要设置更多的中间检查点来防止跑偏。2.2 决策点二循环终止条件的设计循环终止条件是 Agent 工程里最容易被低估、也最容易出事的地方。终止条件设计不好轻则浪费 token重则死循环把账单烧穿。终止条件通常有这几类任务完成信号LLM 输出一个特定的完成标记最大轮次限制硬性截断防止无限循环超时控制从时间维度兜底重复检测如果连续几轮的动作和结果高度相似说明卡住了强制终止预算控制token 消耗或者工具调用次数超过阈值就停。这几类要组合使用不能只靠一种。我一般会设置三层防护第一层是 LLM 自己判断完成第二层是最大轮次通常设 10 到 15 轮具体看任务复杂度第三层是超时和预算硬限制。三层任何一层触发都会终止循环然后进入结果整理阶段。这里有个实操细节最大轮次不要设得太小。我见过有人设 5 轮结果复杂任务根本跑不完。也不要设太大20 轮以上基本就是在空转了。10 到 15 轮是一个比较合理的区间具体根据你的任务平均需要多少步来调整。另外重复检测的相似度阈值也需要调太松了检测不出来太紧了正常的多步操作会被误判。2.3 决策点三工具调用的粒度与编排方式工具怎么设计是 Agent 开发里最考验工程判断力的地方。粒度太粗Agent 没有决策空间粒度太细调用轮次爆炸成本和延迟都受不了。我的经验法则是一个工具只做一件事但这件事要有业务意义。比如查询用户订单列表是一个好工具查询数据库就太泛了执行 SQL更是危险。工具的参数设计也要讲究尽量用结构化参数而不是让 LLM 拼字符串这样校验和错误处理都好做。工具编排方式有两种主流思路。一种是LLM 自主选择把所有工具的描述塞进 prompt让模型自己决定调哪个。这种方式灵活但工具数量多了之后 prompt 会很长而且模型容易选错。另一种是分层路由先用一个轻量级的分类器或者规则把请求路由到工具子集再让 LLM 在子集里选。这种方式适合工具数量超过 10 个的场景。还有一个容易被忽略的点工具的返回结果格式。返回给 LLM 的结果要尽量简洁、结构化不要塞一大堆无关信息。我见过有人把整个 API 响应原封不动返回几千个 token 塞进去LLM 根本抓不住重点。正确的做法是在工具层做一次信息提取和压缩只返回 LLM 决策需要的关键字段。2.4 决策点四记忆的存储与检索策略记忆系统决定了 Agent 能不能记住之前发生的事情。短期记忆相对简单就是维护一个消息列表但难点在于上下文窗口有限消息不能无限增长。常见的处理策略有几种。滑动窗口是最简单的只保留最近 N 条消息但会丢失早期重要信息。摘要压缩是把早期消息用 LLM 总结成一段话保留关键信息但丢失细节。向量检索是把历史消息存进向量库每轮根据当前上下文检索最相关的几条注入。实际项目中这三种往往是组合使用的。长期记忆的设计更复杂。你需要决定存什么、怎么存、怎么检索、什么时候更新。我的建议是长期记忆只存那些跨会话仍然有价值的信息比如用户偏好、历史决策结论、重要的实体关系。不要把每轮对话都往长期记忆里塞那样检索质量会急剧下降。检索策略上纯向量检索在 Agent 场景下往往不够用因为 Agent 需要的是当前这一步需要的信息而不是语义上最相似的信息。我通常会加上时间衰减、重要性评分、类型过滤等维度来做混合排序。这块的调优空间很大值得花时间。2.5 决策点五错误处理与重试机制Agent 执行过程中出错是常态不是异常。工具会超时、API 会限流、模型会输出格式错误、外部服务会挂掉。错误处理机制的设计直接决定了 Agent 的鲁棒性。首先要区分错误类型。可重试错误比如网络超时、临时限流这种可以自动重试但要设置退避策略和最大重试次数。不可重试错误比如参数校验失败、权限不足这种重试也没用应该把错误信息返回给 LLM让它调整策略。致命错误比如认证失败、服务下线这种应该直接终止并上报。把错误信息返回给 LLM 让它自己调整这是 Agent 相比传统程序的一个优势。但前提是错误信息要清晰、结构化LLM 才能理解。我一般会把错误包装成{error_type, error_message, suggestion}这样的格式返回实测下来 LLM 的自我修复成功率会高很多。还有一个实操技巧对于关键工具调用做幂等性设计。因为重试的时候可能会重复执行如果工具不是幂等的就会产生副作用。比如创建订单这种操作重试之前要先检查是否已经创建成功。2.6 决策点六上下文预算的分配与管理上下文窗口是 Agent 最稀缺的资源。System prompt、工具描述、历史消息、工具返回结果、当前用户输入全都要塞进同一个窗口里。预算分配不好要么关键信息被挤掉要么直接超出限制报错。我的分配策略是这样的System prompt 和工具描述占 20% 到 30%这部分是固定的要尽量精简。历史消息占 30% 到 40%通过摘要和检索来控制。工具返回结果占 20% 到 30%在工具层做压缩。剩余 10% 到 20% 留给当前轮次的推理和输出。这个比例不是死的要根据任务特点调整。如果任务需要大量历史信息就多分给历史如果工具返回结果很关键就多分给工具结果。关键是要有一个明确的预算意识而不是等到报错了才想起来裁剪。裁剪策略上我推荐优先级裁剪而不是简单的截断。给每类信息打上优先级标签超预算的时候从低优先级的开始裁。比如工具返回结果里的原始数据可以裁但错误信息不能裁历史消息里的寒暄可以裁但决策结论不能裁。2.7 决策点七可观测性与调试能力建设Agent 是个黑盒出了问题如果不做可观测性你根本不知道是哪一步出的错。可观测性建设包括三个层面日志、追踪、指标。日志要记录每一轮的完整输入输出包括 LLM 的原始响应、工具调用的参数和结果、状态变化。追踪要把一次完整的 Agent 执行串起来能看到每一步的耗时和依赖关系。指标要统计成功率、平均轮次、平均耗时、token 消耗、工具调用分布等等。我特别想强调的是Agent 的调试和传统程序调试完全不同。传统程序你可以打断点、单步执行Agent 的行为是概率性的同样的输入可能走出不同的路径。所以你需要的是回放能力——把一次执行的完整轨迹存下来可以重新播放、可以修改某一步的输入看后续怎么变。这个能力在排查问题时价值巨大。另外建议在开发阶段就把每一步的中间状态可视化出来。我一般会做一个简单的 Web 界面展示每一轮的思考过程、工具调用、返回结果这样调试效率会高很多。3. 循环机制Agent 的心脏怎么跳3.1 ReAct 循环的工程化落地ReAct 是目前最主流的 Agent 循环模式核心思想是推理加行动交替进行。LLM 先输出一段思考然后决定调用什么工具工具返回结果后再进入下一轮思考。这个模式在论文里看起来很简洁但工程落地的时候有很多细节要处理。第一个细节是思考过程的格式约束。你需要定义清楚 LLM 输出的结构比如用特定的标记区分思考、工具调用、最终答案。我一般会用类似Thought: ... Action: ... Action Input: ...这样的格式然后在解析层做严格的校验。格式不对的时候要能自动纠正或者重试。第二个细节是工具调用结果的注入方式。工具返回的结果要以什么角色、什么格式注入到下一轮对话里通常是用一个特殊的角色比如 tool 或者 function但不同模型的 chat 模板对这个的支持不一样需要适配。第三个细节是多工具并行调用的处理。有些模型支持一次输出多个工具调用这时候要决定是并行执行还是串行执行。并行快但有依赖问题串行稳但慢。我的做法是无依赖的工具并行有依赖的串行依赖关系通过工具描述里的前置条件来声明。3.2 什么时候该让 Agent 停下来终止判断是循环机制里最微妙的部分。让 LLM 自己判断任务完成了听起来简单实际上很容易出问题。模型有时候会过早认为完成了有时候又会陷入再检查一下的循环。我的做法是多信号综合判断。除了 LLM 自己输出的完成标记还要看是否所有子目标都已达成、是否还有未处理的错误、最近几轮是否有实质性进展。这几个信号综合起来判断比单纯依赖 LLM 的自我评估可靠得多。还有一个技巧在 system prompt 里明确定义完成的标准。不要只说完成任务后输出 DONE要说清楚什么算完成。比如当用户的所有问题都得到回答且没有待处理的工具调用时输出 FINISH。标准越明确模型的判断越准。3.3 循环中的状态快照与恢复长任务执行到一半失败了怎么办如果每次都从头开始成本和体验都受不了。所以需要状态快照和恢复机制。快照要存什么至少包括当前的消息历史、已完成的步骤、待处理的步骤、工具调用的中间结果。存储介质可以是内存、Redis、数据库看你的持久化需求。恢复的时候把快照加载回来从断点继续执行。这里有个坑快照的粒度。太粗了恢复后要重做很多工作太细了存储和序列化开销大。我一般是在每个有副作用的操作之前做快照比如调用外部 API、写数据库之前。这样恢复的时候最多重做一步而且不会产生重复副作用。3.4 并发场景下的循环隔离单个 Agent 跑得好好的一上并发就出问题这是很常见的。核心原因是状态共享。如果多个请求共用同一个 Agent 实例消息历史、工具状态、上下文都会串。解决方案是每个请求一个独立的 Agent 上下文。Agent 的配置system prompt、工具定义可以共享但运行时状态必须隔离。实现上可以用请求级别的上下文对象或者干脆每个请求创建一个轻量级的 Agent 实例。还有一个并发相关的问题是资源竞争。如果工具有限流多个 Agent 同时调用会互相影响。这时候需要做请求排队和限流在 Agent 层面控制并发度。我一般会在工具调用层加一个信号量或者令牌桶保证不会超过外部服务的限制。4. 工具调用Agent 的手脚怎么用4.1 工具描述怎么写才能让 LLM 选对工具描述是 LLM 选择工具的唯一依据写得好不好直接决定调用准确率。我见过很多工具描述就一句话查询用户信息这种 LLM 根本不知道怎么用、什么时候用。好的工具描述应该包含这几个部分功能说明一句话说清楚这个工具做什么使用场景什么情况下应该用这个工具参数说明每个参数的类型、含义、是否必填、取值范围返回说明返回什么格式的数据示例一个典型的调用示例。参数说明尤其重要。LLM 最容易出错的地方就是参数格式。如果参数是枚举类型一定要把所有可能的值列出来。如果参数有格式要求一定要给例子。我一般会在参数描述里加上例如xxx这样的提示实测能显著降低参数错误率。还有一个技巧在工具描述里写明什么时候不要用这个工具。比如当用户只是打招呼时不要调用此工具。这种负向说明能有效减少误调用。4.2 参数校验与自动修复即使工具描述写得再好LLM 输出的参数还是可能出错。类型不对、格式不对、缺少必填项、值超出范围这些都很常见。所以参数校验层是必须的。校验层要做的事情检查必填参数是否存在、检查参数类型是否正确、检查参数值是否在允许范围内、检查参数之间的依赖关系。校验失败的时候不要直接报错终止而是把错误信息返回给 LLM 让它重新生成。这个重试通常一到两次就能成功。对于常见的格式错误还可以做自动修复。比如 LLM 输出了字符串 123 但参数要求是整数自动转换一下。日期格式不对尝试用常见的几种格式解析。这些自动修复能减少很多不必要的重试轮次。4.3 工具返回结果的压缩与结构化工具返回结果的处理是很多人忽略的优化点。原始的工具返回往往包含大量冗余信息直接塞给 LLM 既浪费 token 又干扰判断。我的做法是在工具层做一次信息提取和结构化。比如一个搜索工具返回了 20 条结果每条都有标题、摘要、URL、时间戳但 LLM 决策可能只需要标题和摘要。那就只返回这两个字段并且限制条数。返回格式上我推荐用简洁的 JSON 或者 Markdown 表格。JSON 结构化好解析Markdown 表格可读性好。避免返回大段的自然语言文本LLM 抓重点的效率会低很多。还有一个细节错误结果的返回格式要和成功结果区分开。我一般用{success: false, error: ...}这样的结构让 LLM 一眼就能看出这次调用失败了。4.4 工具调用的安全边界工具是 Agent 和外部世界交互的通道也是安全风险最集中的地方。几个必须做的防护权限控制每个工具都要有明确的权限要求不能什么都能调参数白名单对于敏感参数比如文件路径、SQL 语句要做严格的白名单校验频率限制防止 Agent 疯狂调用某个工具敏感操作二次确认对于删除、支付这类不可逆操作要有人工确认或者额外的验证步骤。我特别想强调文件路径和命令执行这两个高危场景。如果 Agent 有文件操作能力一定要限制在特定的目录下并且做路径穿越检查。如果有命令执行能力那风险更高建议只在沙箱环境里开放并且做严格的命令白名单。5. 记忆与上下文Agent 的记性怎么管5.1 短期记忆的窗口管理策略短期记忆就是当前会话的上下文管理目标是在有限的窗口里保留最有用的信息。前面提到的滑动窗口、摘要压缩、向量检索三种策略实际用的时候要根据场景组合。我的默认配置是这样的最近 5 轮对话保留原文保证当前交互的连贯性5 轮之前的对话做摘要每 5 轮压缩成一段话关键信息比如用户明确说的偏好、重要的决策结论单独提取出来始终保留。这样既控制了长度又不会丢失关键信息。摘要的生成时机也有讲究。不要每轮都重新摘要那样开销太大。我一般是在消息数量超过阈值的时候触发一次摘要把最老的一批消息压缩掉。摘要本身也要控制长度一般不超过原文的 20%。5.2 长期记忆的写入与召回时机长期记忆不是什么都存要有选择。我判断的标准是这条信息在未来其他会话里是否还有价值。用户说今天天气不错这种不用存用户说我偏好用 Python 而不是 Java这种要存。写入时机上我一般是在会话结束时做一次批量提取而不是每轮都写。提取的时候用 LLM 做一次总结把值得长期保留的信息抽出来结构化之后存入向量库或者关系库。召回时机上不是每轮都召回而是在任务开始时和需要做决策时召回。召回的时候用当前任务描述做查询取最相关的几条注入上下文。召回数量不要太多3 到 5 条就够了多了反而干扰。5.3 上下文压缩的几种实用手段除了摘要还有几种压缩手段值得一试。实体提取把对话里提到的关键实体人名、地名、产品名提取成结构化列表比保留原文省很多 token。决策日志把 Agent 做过的关键决策和理由记录下来替代冗长的推理过程。工具结果缓存相同的工具调用结果缓存起来下次直接引用不用重新返回。这些手段可以组合使用效果比单一的摘要好很多。但要注意压缩是有信息损失的关键信息不能压。我一般会维护一个不可压缩列表里面的信息无论多长都要保留。5.4 记忆污染与错误传播的防范记忆系统有个隐蔽的风险一旦错误信息进入记忆会被反复召回导致错误持续传播。比如 Agent 某一次理解错了用户意图这个错误理解被存进长期记忆后面每次召回都会带出这个错误。防范措施有几个。写入前校验长期记忆写入之前做一次事实性检查明显错误的不要存。定期清理定期回顾长期记忆把过时的、错误的清理掉。来源标记每条记忆标记来源和置信度召回的时候低置信度的要谨慎使用。用户纠错通道允许用户纠正 Agent 的记忆纠正后更新或删除对应的记忆条目。6. 从 Demo 到生产那些必须补的课6.1 压测与混沌工程在 Agent 上的应用Agent 的压测和传统服务不太一样。传统服务压测主要看 QPS 和延迟Agent 压测还要看任务成功率、平均轮次、token 消耗这些指标。我一般会准备一批真实场景的任务集覆盖简单任务、复杂任务、边界情况、异常输入。然后模拟并发执行观察各项指标。重点关注成功率是否随并发上升而下降、平均轮次是否异常增加、是否有请求卡死。混沌工程方面要主动注入故障工具超时、模型返回格式错误、外部服务不可用、网络抖动。观察 Agent 能不能正确处理这些故障是优雅降级还是直接崩溃。这一步能暴露很多平时发现不了的问题。6.2 成本控制token 消耗的优化路径Agent 的 token 消耗是普通对话的好几倍因为每一轮都要把历史上下文重新发一遍。成本控制是必须做的。优化路径有几条。减少轮次通过更好的 prompt 和工具设计让 Agent 更快完成任务。压缩上下文前面讲的那些手段都用上。缓存system prompt 和工具描述这些固定内容用 prompt caching 缓存起来。模型分级简单决策用便宜的小模型复杂推理才用大模型。结果复用相同或相似的任务结果缓存起来。这几条组合起来通常能把成本降到原来的三分之一到一半。具体能降多少取决于你的任务特点。6.3 灰度发布与回滚策略Agent 的行为是概率性的同样的代码可能因为模型更新、工具变化而产生不同的行为。所以灰度发布是必须的。我的做法是新版本先在小流量上跑对比成功率和关键指标。如果指标没有明显下降逐步扩大流量。如果出现问题立即回滚。回滚要能快速生效所以配置和代码要分离模型版本、prompt 版本、工具版本都要能独立切换。还有一个细节保留旧版本一段时间。因为有些问题可能在灰度期间没暴露全量之后才出现。保留旧版本可以快速切回去。6.4 用户反馈的收集与闭环Agent 的效果最终要靠用户来检验。所以反馈收集机制是必须的。显式反馈比如点赞点踩隐式反馈比如用户是否采纳了 Agent 的结果、是否重新提问、是否中途打断。收集到反馈之后要形成闭环。bad case 分析定期回顾失败案例找出共性问题。prompt 迭代根据 bad case 优化 prompt。工具优化如果发现某个工具经常出错就要改进工具设计。测试集更新把新的 bad case 加入测试集防止回归。这个闭环跑起来之后Agent 的效果会持续提升。我见过做得好的团队每周都会做一次 bad case review迭代速度非常快。7. 一些踩坑之后的个人体会做 Agent 这几年踩过的坑比写过的代码还多。有几个体会特别深分享出来给正在这条路上的人参考。第一个体会不要追求一步到位的完美架构。我早期做 Agent 的时候总想设计一个能应对所有情况的通用架构结果复杂度失控调试都调不动。后来学乖了先做一个能跑通核心场景的最小版本然后根据实际问题逐步演进。Agent 的架构是长出来的不是设计出来的。第二个体会可观测性要第一天就做。我吃过亏项目跑了两周才发现某个工具调用一直在静默失败因为没做日志。从那以后我所有 Agent 项目的第一件事就是搭日志和追踪哪怕功能还没写完。第三个体会prompt 是要持续迭代的。不要指望一次写出完美的 prompt。我现在的做法是把 prompt 当成代码来管理有版本、有测试、有 review。每次改动都要跑回归测试确保没有引入新的问题。第四个体会工具的质量比模型的能力更重要。我见过太多团队花大量时间调模型却忽略了工具设计。实际上一个设计良好的工具集配合中等能力的模型效果往往好过一个粗糙工具集配顶级模型。第五个体会要有兜底方案。Agent 再稳定也会有失败的时候关键是要有兜底。可以是转人工、可以是返回默认结果、可以是提示用户重试。没有兜底的 Agent 上线就是灾难。最后分享一个实用的小技巧在开发阶段把 Agent 的每一轮思考过程都打印出来。不要只看最终结果要看它是怎么一步步走到结果的。很多时候问题就藏在中间的某一步推理里只看结果根本发现不了。这个习惯帮我定位了无数个隐蔽的 bug。