1. 为什么AI Agent一定会出错三类根因决定三种应对思路先说一个我自己的真实经历。某个周五晚上我部署了一个用来做订单数据整理的AI Agent它需要定时读取邮件附件中的Excel清洗后写入CRM系统。周日早上起来一看CRM里多了几千条脏数据——Agent在解析某个格式异常的表格时把“客户名称”这一列整体读偏了一格然后按“正确”的逻辑批量写了进去。更麻烦的是它在写之前还把原表里的数据格式给改了回滚都费劲。这个场景基本概括了AI Agent出错的全部痛苦不是能不能出错的问题而是出错之后你还有没有办法把系统拉回来。传统的软件出错异常堆栈、错误码、事务回滚套路非常成熟。但AI Agent不一样它的输入是不可控的自然语言它的“逻辑”是概率生成的它的工具调用是动态的这就导致出错的形态千奇百怪而且经常是“逻辑上看起来完全正确实际上全错”。我带过的项目里Agent出错的原因大致可以分为三类每一类对应着不同的防御策略。理解了这三类根因后面讲的校验、暂停、回滚、人工接管你才知道各自该用在什么位置。1.1 不确定输入导致的不确定输出LLM本质上是一个概率模型同一个问题换个说法输出可能就变了。哪怕你给了它非常详细的System Prompt它在处理模糊信息时依然会“自由发挥”。我见过最典型的例子是给Agent的任务是“提取邮件里的发货日期”结果邮件里写了两个日期一个是“下单日期”一个是“期望发货日期”。Agent没有问直接选了其中一个而且每次都选得不一样。这就是不确定输入导致的输出漂移你没办法通过调Prompt彻底消除只能在输出端加校验发现不合预期就拦住它。这类错误的核心特征是它不是一个bug而是模型在“猜测”。既然是猜测就一定会有猜错的时候所以后置校验Post-validation是必须的而不是可选的。1.2 外部环境状态假设Agent最常踩的坑LLM没有“常识”它对外部世界的理解完全来自你给它的上下文。如果你的上下文里没有明确说明“数据库当前连接是否正常”“某个文件是否已经被占用”Agent就会默认一切都是好的。举个例子。我之前做一个文件处理Agent它需要读取某个目录下的文件处理后删除。有一次另一个定时任务临时把文件挪走了Agent读取失败正常情况下应该报错退出但它没有它认为文件读取成功但内容为空然后生成了一个空的数据表并写了进去最后还把源文件删了。事后排查时日志里全是“File not found”但Agent的思维链依然在“正常推进”因为它把“失败”理解成了“空输入”。这类错误的可怕之处在于Agent的每一步都是符合逻辑的但前提假设是错的。所以你需要做的不是在Prompt里反复强调“注意检查文件是否存在”而是在工具调用层加明确的状态校验让错误在第一步就暴露出来。1.3 长期任务中的错误累积小偏差滚成灾难第三类根因是最隐蔽的也是我后来做暂停与回滚机制的核心出发点。一个复杂的Agent任务往往包含几十上百个步骤每一步LP输出的微小偏差在下一步被当成“新的事实”继续使用滚雪球一样越滚越大。比如一个市场分析Agent第一步抓取数据时丢了两个字段第二步清洗时就会把缺失值填充成0第三步做统计时0会被当成真实数值算进平均第四步生成的报告就会得出一个完全错误但看起来无比专业、一整套逻辑自洽的结论。你在最后一步看输出根本看不出来哪里错了因为每一步都是“对的”错的是很早之前的那个起点。对这类累积性错误单纯的“后置校验”是不够的因为错误发生在半路你需要在执行过程中有“暂停点”定期检查中间产物。所以我才强调校验、暂停、回滚三件事要配套使用缺一个都不行。2. 校验在错误进入状态之前拦住它校验是防御体系的第一道门目的是让错误在造成不可逆影响之前就被发现。我给Agent项目落地校验时会把它分成三个层次前置校验、后置校验、工具层校验。三个层次解决的是完全不同的问题。2.1 前置校验任务启动前的三张检查清单前置校验是指在Agent开始执行任务之前先对输入、配置、环境状态做一轮确认。这一层很多团队会忽略觉得“任务指令是用户发的肯定没问题”但实际恰恰相反大量的Agent错误来源于启动时的假设。我习惯在Agent的启动流程里加上三个检查项缺一不可输入完整性检查用户提供的参数、文件、链接是否真实存在格式是否符合预期。比如任务是“处理upload/目录下的最新Excel”那就要先确认这个目录下真的有文件而不是拿到一个空路径就开始跑。配置一致性检查当前环境的配置和Agent运行时依赖的配置是否一致。比如你换了API Key、改了数据库地址、升级了模型版本这些变化是否已经同步到了当前任务。我遇到过Agent按旧的数据库地址写入写完了才发现连的是测试库那种错误恢复起来痛不欲生。权限与资源检查是否有写权限、是否有足够的磁盘空间、网络是否可达。这一步看起来琐碎但能拦住大量“执行到一半才发现干不下去”的情况。前置校验不是让Agent自己用LLM判断而是用确定性代码去检查。LLM的判断是概率性的用来做校验本身就不够可靠。规则明确、结果可预期的事情交给代码。只有代码确认不了的事情才让LLM去判断。2.2 后置校验输出没有毒性才允许进入下一步后置校验是Agent执行完一个步骤之后对产物做检查。这一步的关键在于“检查什么”。我的经验是不要只检查格式和类型更要检查逻辑合理性和约束满足性。举一个实际项目的例子。我当时做一个批量生成商品描述的Agent它每生成一批描述我就做一个四层校验格式校验JSON能解析、字段齐全、类型正确。内容校验描述里没有违反平台违禁词的文案。业务校验商品价格、库存这些数值在合理区间内没有单价变成0.01这种低级错误。一致性校验生成的内容和输入的商品信息能不能对上比如标题里说“iPhone 15”描述里就不能写“支持5G网络”这种和产品无关的通用话术。第4层是最有用但最容易被忽略的。因为格式校验只能保证“结构对”内容校验只能保证“词合法”只有一致性校验才能发现“Agent自己编造了输入里不存在的信息”。这也是LLM输出的最大风险点幻觉。你不做一致性校验就无法拦截幻觉产物。后置校验的失败处理也很有讲究不是简单“终止任务”就完了。我把校验失败分为“可重试”和“不可重试”两类可重试比如生成的JSON格式不对、字段缺失这种属于LLM输出层面的抖动让它带着错误提示重来一次大概率就能通过。不可重试比如生成的内容和源数据冲突、数值超出合理范围这种说明Agent对任务的理解有偏差重试一万次都一样必须停下来人工介个。两类错误处理方式完全不同你的代码逻辑里必须有这个区分否则会把所有错误笼统一股脑塞给重试机制白白耗费成本还可能在错误方向上越跑越远。2.3 工具层校验给LLM套上“验货”环节工具层校验是我特别想强调的。Agent在执行任务时通常不是直接用LLM完成一切而是通过调用工具函数来读写文件、操作数据库、调用API。这些工具就是LLM的“手”工具层的校验就是给“手”戴上一副“手套”防止它抓到不该抓的东西。我常用的一种设计是不直接暴露原始工具给LLM而是用一个包装层Wrapper包一层在包装层里加参数校验和动作校验。比如def write_to_db(table_name, data): # 参数白名单校验只允许指定的表 allowed_tables [orders, users, products] if table_name not in allowed_tables: raise PermissionError(ftable {table_name} is not allowed) # 数据完整性校验关键字段不能为空 required_fields [id, timestamp] for field in required_fields: if field not in data: raise ValueError(fMissing required field: {field}) # 动作分级校验危险操作需要额外确认 if table_name users and is_admin in data: raise PermissionError(Modifying admin flag is forbidden) # 真正的写库逻辑 ...这样做的好处有两个一是控制了LLM的行为边界。LLM再怎么“自由发挥”落到工具层时非法的动作会被硬性拦截。比如它想通过写文件接口去覆盖别的目录包装层里的路径检查就能拦下来。二是给了后置校验一个明确的抓手。有了工具层参数校验你不需要在LLM的输出里大海捞针式地找错误工具层直接帮你把异常抛出来了。2.4 一套可复用的校验骨架总结一下我落地的校验机制大概长这样。下面是一个精简版的伪代码实际项目里我会把它做成一个装饰器或者框架层的东西统一挂在每个Agent步骤上。def validated_step(step_func, pre_checksNone, post_checksNone): def wrapper(context): # 前置检查 for check in pre_checks: check(context) # 执行步骤 result step_func(context) # 后置检查 for check in post_checks: check(result, context) return result return wrapper这套骨架的好处是校验体系和业务逻辑分离。业务代码专注自己的事校验逻辑统一管理每加一个步骤只要声明它需要“读哪些文件、写哪些库、输出什么结构”校验体系自动生效。维护起来非常省心尤其是当你面对几十个Agent步骤的时候。3. 暂停给系统留一个“踩刹车”的入口校验做得再严密也只能拦截“已知的异常”。真正麻烦的是“看起来正常但实际已经偏离”的情况这种错误往往会在执行中途累积等你发现时已经晚了。所以Agent的执行流程里必须有暂停机制让系统有机会在“还没彻底坏掉”的时候停下来。3.1 暂停的三条触发路径暂停机制我拆成了三条触发路径对应不同发起方路径一自检触发。Agent在关键节点执行后内部校验发现结果异常或置信度过低主动拉起暂停。这种场景在设计时要特别明确“置信度阈值”——LLM是可以给出一个置信度的虽然不绝对可靠但当它自己对某一步都犹豫不决时暂停往往比硬着头皮继续跑更稳妥。我设定过一个经验值当Agent对某次关键操作的回答置信度低于0.8时自动进入暂停。路径二网关触发。这是我最推荐的做法。所有的Agent动作都走统一的网关网关侧实时监控指标比如API调用失败率、token消耗异常、执行时长过长一旦触发阈值就强制暂停。设计上这一步与Agent逻辑解耦不干扰Agent内部运转又能在外部兜底。路径三外部指令触发。也就是人工暂停。操作者可以随时通过控制台或消息接口对一个正在执行的任务下达暂停指令。这类触发路径可能看起来不起眼但我在生产环境里用得频率是最高的——很多情况下你在监控面板上发现Agent跑偏了第一反应是喊暂停而不是去改代码。3.2 暂停时的状态持久化让Agent“接上上次的线”暂停不是把进程杀掉就行暂停之后还需要能恢复或者能定位问题。所以暂停时做的第一件事是状态持久化——把当前语境Conversation Context、中间产物、已执行步骤清单都保存下来。我用一个JSON文件保存Agent的“暂停快照”大致长这样{ task_id: task_12345, paused_at: 2025-04-15T10:30:00Z, pause_reason: confidence_low, conversation_history: [..., ..., ...], current_step: step_5, completed_steps: [step_1, step_2, step_3, step_4], intermediate_results: { step_3_output: {raw_data: ..., cleaned: ...} }, context_metadata: { input_file: orders_20250414.xlsx, source_hash: 4f1c4f0d... } }这里有一个细节我踩过坑单独保存当前对话历史是不够的。因为LLM的上下文是有限的Agent可能会在某个节点做上下文压缩把之前的细节提炼成摘要。你恢复Agent时不能只给它看“压缩后的摘要”还要给它保留关键中间产物否则它后续步骤就失去了准确的事实依据自己脑补。3.3 运行时限制防止失控的“安全阀”暂停机制里最容易被忽略的是“运行时限制”——比如最大执行步数、最大token消耗、最大工具调用次数。这类限制相当于给Agent加了一个“总闸”防止它跑进死循环或者无限消耗资源。我之前做一个数据拉取Agent源数据接口有一处逻辑Bug导致某次请求永远返回一个“当前没有新数据”的空结果同时又把游标往前推进一位。Agent以为“没数据拉取”继续循环下一次——“没数据”又“推进游标”无限循环。如果没有最大调用次数限制这任务能一直跑到接口超时。我通常会给Agent设置三重限制最大连续执行时长比如60秒、最大步骤数比如20步、最大工具调用次数比如50次。任何一条超限直接触发暂停。宁可误杀宁可多让人工看一眼也不要让它像脱缰野马一样跑下去。4. 回滚状态损坏时的复位机制校验拦截错误、暂停控制事态但有些错误已经造成了状态变化写了脏数据、改了文件、删了记录这时候只有回滚机制能把你拉回正确的位置。回滚是最后一道保险也是最容易设计得“差一口气”的环节。4.1 回滚的三个层级点、线、面我先梳理一下回滚的层级。很多团队一想到“回滚”就把整个Agent任务回归到初始状态这粒度太粗了成本也高。我把回滚分成三层第1层单步回滚点。Agent执行到第5步发现第4步的输出有问题那么只需要把这个步骤的产物丢弃回到第4步刚完成时的状态用修正后的逻辑重跑。第2层流程回滚线。错误跨了多个步骤比如第3步的错误影响了第4、第5步的中间产物这时需要沿着执行链把相关步骤串起来一起回退回到“错误注入点”之前的那个干净状态。第3层全面回滚面。错误已经写入了外部系统数据库、文件系统、第三方服务单靠Agent内部状态无法恢复了需要借助外部系统的快照、备份或事务回滚能力把整个任务涉及的外部状态一起还原。我在设计回滚时的一个核心原则是能局部回滚就不要全局回滚。每次都做全面回滚成本太高而且会对没有出错的数据造成无谓的打扰。4.2 回滚的本质是恢复可复现状态事务日志与快照回滚工作的本质其实是“把系统恢复到出错前的某个可复现状态”。一旦理解了这一点你就能明白为什么回滚机制一定要在设计阶段就规划好而不是出错之后再想办法。我在Agent框架里内置了一个“操作日志”机制每一步执行、每一次工具调用、每一个外部系统变更都记录在案。日志里除了动作本身还包含两个关键信息变更前的状态摘要Before Image和变更后的状态摘要After Image。有了Before Image回滚就能精确地知道“该还原成什么样”。让我用文件操作举例说明。operation_log [] def tracked_write_file(path, content): # 读取变更前的hash import hashlib old_content b if os.path.exists(path): with open(path, rb) as f: old_content f.read() old_hash hashlib.md5(old_content).hexdigest() # 天然可以提炼旧状态 new_hash hashlib.md5(content.encode()).hexdigest() operation_log.append({ type: file_write, path: path, old_hash: old_hash, new_hash: new_hash }) with open(path, w, encodingutf-8) as f: f.write(content)有了这个操作日志回滚函数就非常简单遍历日志的反向顺序对每个写操作执行“逆向动作”——写了文件就恢复内容删了记录就重新插入更新了数值就还原旧值。这里我特别想分享一个晶彩时刻的经验给文件做MD5校验值记录比记录整个文件内容高效得多。记录整个文件内容在旧文件很大时会占大量空间记录hash可以在回滚前先比对当前hash是否等于变更后的hash判断文件是否在Agent执行期间被其他进程改过避免回滚误伤。说到文件校验MD5虽然已经有碰撞风险但用在这里做“前后一致性”检测完全足够。如果追求更强的安全性可以用SHA-256代价是hash计算速度稍慢一点但Agent场景通常完全可接受。4.3 幂等设计为什么回滚后重试还会坏这个坑我踩得最深写了很久才真正搞清楚。你回滚之后马上让Agent重新跑一遍结果——又坏了。不是回滚的逻辑有问题而是你的Agent执行过程不是幂等的。解释一下幂等同一个操作执行一次和执行多次结果是一样的。但很多Agent操作天然不具备幂等性。比如“创建新订单”这个操作你执行两次就会创建两个订单回滚把第一次创建的订单删掉重跑又创建了第二个看似正常但如果这次重跑中间某个步骤又被中断你再回滚时回滚逻辑处理的是“第二次创建的订单”而旧数据可能早就被覆盖掉了。解决幂等问题的标准做法是引入幂等键Idempotency Key。每次任务生成一个唯一的Task ID把这个ID随上下文和每次工具调用一起传给外部系统。外部系统至少是数据库层需要检查“这个Task ID对应的操作是否已经发生过”发生过就直接返回之前的结果不做重复动作。def create_order_with_idempotency(task_id, order_data): existing db.query(SELECT * FROM order_actions WHERE task_id ?, task_id) if existing: return existing.result # 直接复用上次的结果 # 真实创建订单 result db.create_order(order_data) db.insert(order_actions, {task_id: task_id, result: result}) return result有了幂等键回滚之后重试才不会重复执行副作用这是回滚体系里最容易被忽视但影响最大的设计。4.4 代码回滚与Agent回滚的配合还有一类回滚经常被混为一谈Agent任务执行出错后的“数据回滚”和Agent程序本身升级出问题后的“代码回滚”。这两件事看起来都叫回滚机制完全不一样。数据回滚解决的是“这一次任务的执行结果坏了”代码回滚解决的是“Agent的程序本身有bug导致所有任务都跑不对”。数据回滚靠操作日志和快照代码回滚靠版本管理和部署系统。我一般会让Agent的每次部署都打上一个版本标签并且把“当前任务使用哪个版本执行”记录在任务上下文里。这样如果某个版本有bug我可以精确地把受影响的那些任务筛出来定向重跑而不是把所有任务一刀切全部回滚那样会误伤正常任务。如果你用过Jenkins这类流水线工具做发布和回滚应该很熟悉这套思路的核心版本可控、变更可溯、回滚可精确到特定批次。5. 人工接管把控制权交回给最可靠的那个执行器校验、暂停、回滚都做完了还是会有一批错误是自动化机制处理不了的。这时候就需要人工接管。很多团队把人工接管设计成“最后不得已的手段”我觉得这个定位不准确——人工接管应该是整个体系里的一等公民它和自动化机制是平等的、互补的关系不是替代关系。5.1 接管的条件与界面不是所有问题都应该自动处理我建议给人工接管设定明确的触发条件不要让它变成一个“临时起意”的动作。我在项目里用的是这样一套触发逻辑校验失败且不可重试前面讲过输出与源数据冲突这类错误。暂停后人类检查发现当前指令本身就是模糊或有歧义的。Agent执行链路已经完全偏离自动化回滚无法恢复到一个可信状态。任何涉及敏感操作如删除数据、发送外部通知、修改权限的步骤强制人工确认。重要的一点是接管一定不是“人从零开始重做”。接管界面要把上下文打包好Agent目前执行到哪一步中间结果是什么出了什么错已经尝试了哪些处理方式。人应该能直接接上上一轮的进度而不是从日志里翻线索。我在接管面板里放了一个按钮“一键生成当前任务的问题简报”把暂停快照、失败原因、会话历史一键汇总成文。对接时直接看那份简报对事情的了解程度不比看代码差。5.2 上下文交接给人一个能立刻开工的工作台人工接管的下一个话题是交接的手段和有效程度。给人的信息不是越多越好而是精确呈现“决策所需的最小集”。我具体做了什么原始任务描述用户最初想干什么。已完成的步骤及其产物摘要不是完整历史而是“产生过哪些关键结论”。失败点的原始报错、校验报告。当前系统的状态哪些表被改过、哪些文件被动过、哪些接口被调过。推荐的下一步动作可选表明系统的判断但不代表必须采用。这份交接信息不是给人看的是给人“直接开干”的。接手的工程师应该能在十分钟内理解情况并在工作台里直接修复问题、修正指令、重新发起任务而不是陷在“这个Agent到底刚才做了什么”的迷雾里。5.3 交接后的归因与复盘每次人工接管都是一次免费升级人工接管本身是一次宝贵的学习机会。每次接管结束后我会强制要求记录一份归因报告包含三个问题的答案这次错误是输入问题、Agent逻辑问题还是外部环境变化现有的校验、暂停、回滚机制在当时为什么没有拦住当前的机制需要做什么调整下次才能避免同类问题这份报告会直接回流到校验规则库、暂停策略、Prompt模板里。我见过很多团队把Agent接管的经验散落在聊天记录里第二次遇到同样的问题还是靠人肉排查可惜得很。最好的方法论是“让每一次人工介入都变成系统能力的一部分”这样系统才会越跑越稳、越跑越省心。6. 一条完整的故障链路校验失败→暂停→回滚→人工接管前面讲了很多模块化的机制最后我用一个真实发生过的完整场景把校验、暂停、回滚、人工接管整个串起来。这样你看到的不是一个一个孤立的功能点而是一条一体的、自动协作的故障处理链路。6.1 场景设定一个定时运行的“日报生成Agent”。任务流程是读取昨日的销售原始数据 - 数据清洗和汇总 - 生成Markdown日报 - 推送到企业微信群。这个任务每天凌晨跑一次如果出错早晨上班的人打开群就会看到一份错的日报。某天上游系统销售人员手动录入的Excel里出现了一个格式异常某个地区的销售数字列被我一个手滑填成了文字比如“两百三十万”而不是“2300000”。6.2 故障链路逐步拆解第1步前置校验。Agent任务启动前置校验检查文件存在、数据库连接正常。这些都没问题任务继续。注意前置校验只查环境状态不查内容这是合理的因为它不知道今天的数据应该长什么样。第2步工具层校验。读取Excel时工具层对每行数据做类型校验发现“sales_amount”字段有非法值。因为工具层的规则是确定性的必须是数字所以它能立刻抛出一个可读的错误第39行第3列字段类型非法。第3步后置校验失败。工具层校验拦住Agent没有继续走下去但这里的处理逻辑通常不是直接终止而是向上抛出错误。顶层调度器收到错误后判断这是一次可重试的失败吗源数据本身是坏的重试没有意义于是判定为“不可重试”触发暂停流程。第4步暂停与快照。调度器暂停任务记录暂停快照任务ID、当前步骤、失败原因第39行字段类型非法、源文件Hash。并发通知到人工接管队列。第5步人工接管。人工工程师收到通知打开接管面板看到的是任务在“数据清洗”阶段失败原因是Excel第39行的数值字段为文本。工程师可以立即选择“修正后继续”或者“修正后重跑”。假设他远程修改了Excel文件或者通过面板直接把那个字段改成数字然后触发“从清洗步骤继续”。第6步回滚与重试。如果这个任务之前在“数据汇总”阶段已经写入了一个临时表比如先写了一个汇总结果文件而今次任务失败时发现那个临时文件的状态不对因为源数据变了Agent框架会自动做局部回滚删除汇总临时文件重跑清洗和汇总。做过一次基于Task ID的幂等检查之后不会重复发企业微信消息。第7步日报生成与推送。这一次顺利通过后置校验生成日报并推送全流程正确结束。这时企业微信群里出现的是一份正确的日报而不是等同事看到一份错误的日报后再手动删除、再重发一份错的更正消息。6.3 这套机制落地时要避的坑整套链路里我踩过不少地方的坑值得专门列出来坑1回滚逻辑里的旧状态恢复千万别直接覆盖还在写的新文件。我在做文件回滚时发现过一个合并写操作的函数回滚恢复旧文件时另一个并发的Agent任务恰好也在写同一份文件结果旧文件覆盖了新写入的合法数据。后来加了文件锁和“变更前Hash比对”回滚时先检查文件当前Hash是否和After Image匹配不匹配说明有并发改动直接放弃自动回滚转人工处理。坑2暂定状态要及时“过期”。没有设置有效期的事务状态容易出现堆积。任务暂停了三天什么都忘了。我现在规定暂停快照保留24小时超过24小时没有人工接管就发三级警报并在群里置顶提醒避免任务永远悬着。坑3校验阈值不要定太死。我在初期把置信度阈值和校验规则定得极严动不动就暂停结果是Agent整天被人为打断没有人敢放开它在生产环境跑。后来我把规则做了分级一级规则绝对不能违反比如关键字段为空、写入危险表直接Fail二级规则合理但允许一定弹性比如文本风格、表述方式只告警不阻断。暂停率一下子降到合理水平告警量虽然还在但不再干扰正常执行。提示规则分级的判断标准是——违反了会造成实质性数据破坏或安全事故的必须Fail只是不符合主观偏好、不影响正确性的可以只告警。别让“完美主义”拖垮整个体系的效率。坑4人工接管界面一定要“所见即所得”。我第一次做接管面板时只在里面放了堆栈日志和JSON快照工程师要花半小时才能搞清楚Agent走到了哪一步。后来我把每一步的中间结果渲染成直观的可视化界面表格、缩略图、对比差异接管效率提升非常明显。人机协作的体验直接影响整个体系的可靠性。结语把这四件事做成一个整体而不是四座孤岛最后说说我个人的感受。很多团队聊AI Agent治理喜欢分别去抠“校验怎么做”“回滚怎么做”但实际运行中你会发现这四件事必须是连体的。校验的作用是发现问题暂停的作用是防止问题扩散回滚的作用是消除已发生的影响人工接管的作用是兜住那些自动化机制还理解不了的情况。少任何一个环节其他三个都会变得很吃力。没有校验你会频繁触发回滚没有暂停回滚的对象可能已经是一个彻底坏掉的状态没有人工接管纯自动化的体系会在边界情况里反复转圈。根据我的实操经验这套体系从零搭到基本可用大概需要两周调到一个让人舒服的状态至少得有一个月的生产数据回来喂养它。但一旦跑顺你会明显感觉Agent从“玩具”变成了一个敢让它在生产环境里干活的工具。这种安全感是单纯的Prompt调优给不了的。最后一个小技巧每次出问题别急着骂模型笨先去查你的校验和暂停链路是不是在“该出手的时候”真的出手了。多半情况下不是模型乱了是机制没有兜住。把机制补齐Agent的表现自然就稳了。