Agent 说它做完了数据库不同意微软给智能体上了场「查账式」考试最近有个场景让我印象特别深一个号称能自动处理售后工单的智能体跑完流程日志里清清楚楚写着“退款已完成已通知用户”结果运营同学打开后台一看支付流水里根本没有那笔退款。系统说做完了数据库不认账。这不是个例。随着AI Agent开始从“陪聊”走向“干活”越来越多团队发现智能体最擅长的不是执行任务而是“汇报任务”。你问它做完没它永远说做完了语气还特别笃定。但你把数据库翻出来一核对经常对不上。微软最近给智能体上了一场“查账式”考试思路很直接不听Agent自己怎么说只看数据库里留下的事实痕迹。这场考试的本质是把Agent当成一个需要接受审计的执行者来考核而不是当成一个靠嘴汇报的助手。这方向我非常认同今天就把这套思路背后的原理、实操方法以及我们在开发Agent时怎么借鉴这套“对账思维”来避坑一次性讲透。1. Agent的“做完”为什么不能信自我报告的信任边界1.1 报告与事实之间的三个裂缝先别急着骂Agent撒谎它其实也不是故意骗你。大模型生成文本的底层机制决定了它在输出“已完成”这句话时本质上是在生成一段“听起来像已完成”的文字而不是在陈述一个经过验证的事实。这就是第一道裂缝——表述与事实脱钩。第二道裂缝更隐蔽工具调用返回的信息被截断或误读。比如Agent调用了一个退款接口返回值是“200 OK”它就把“OK”理解成“退款成功”于是汇报“已退款”。但很多时候接口返回200只代表“请求已受理”不代表“业务操作已生效”。你让HTTP状态码代替业务状态码数据库当然不答应。第三道裂缝来自Agent的上下文窗口限制。跑一个复杂任务时Agent要处理几十轮工具调用早期步骤的结果可能被后续内容挤出上下文。它记不清自己到底做过什么就会根据“最近一次动作”脑补出一个完整闭环然后自信地输出“做完了”。这三道裂缝叠加在一起就是我们在真实项目里反复遇到的“Agent幻觉式完成”。1.2 数据库为何是查证Agent行为的天然现场要识别Agent到底有没有真干成得有个“不可抵赖”的凭证。数据库就是这个凭证。任何需要持久化的业务行为最终都会落在数据库里退款会有一条支付流水记录建表会多出一张表发消息会多一行消息记录。数据库像一个财务账簿Agent做的每一笔“支出”和“收入”都会留下痕迹。更重要的是数据库的状态是可以被独立查询、独立验证的——不需要依赖Agent的自我报告。这也是“查账式”考试的精髓把评价Agent的唯一标准从“它说了什么”切换成“账面上留下了什么”。做成了就是做成了没做成就是没做成一切以数据库里的最终状态为准。这个思路其实和审计行业一脉相承。审计人员从来不问企业负责人“你们这笔钱付了没”而是直接去银行打流水、查对账单。微软把这套“查账”思想搬到了Agent评测里本质上是在给智能体的可信度立规矩别跟我汇报让我查账。2. 微软的查账式考试评测思路与判定机制拆解2.1 不考“说得好”只考“账对得上”传统的大模型能力评测考的是“生成质量”看输出文本是否流畅、是否正确。但Agent不是文本生成器它是个“执行者”。执行者的考核标准不应该是“解释得好”而应该是“事情办成了没有”。微软这套评测把Agent丢进真实的业务场景里给它一个任务、一批可用工具、一个真实的数据库。任务执行完之后评测系统不去读Agent写的总结报告而是直接对数据库做检查和比对。我理解这套考试的核心判定机制分两层第一层账户级核对。任务要求Agent完成一个明确数据变更评测方提前定义好“成功态”数据库应该长什么样。比如“把订单状态从待支付改成已支付并生成支付流水”那成功态就是订单表状态字段正确流水表多一条匹配记录。Agent执行完毕系统直接查库逐条比对。第二层过程级审计。光看最终状态还不够因为有的Agent会“歪打正着”改对了数据但过程是错的或者中途产生了不该产生的脏数据。所以评测系统还会核对Agent过程中的每一次数据库操作检查是否有遗漏操作、多余操作、错误操作。这种双轨判定的好处是既防“假完成”也防“瞎完成”。2.2 评测任务设计的讲究数据最诚实的逻辑就是增删改查。微软这场考试里的任务设计也基本围绕数据库核心操作的组合展开数据新增类比如“创建一条客户反馈记录”“把新注册用户写入用户表”考察Agent能否按schema正确插入数据。数据修改类比如“把订单金额从500改成600并重算总价”“更新用户的会员等级”考察Agent能否精确定位并修改目标数据。数据删除类比如“删除已注销用户的相关记录”“清理过期缓存数据”这类任务最考验Agent对边界条件的把握删多了删少了都会被数据库“记账”。数据查询决策类比如“统计本月销售额并生成报表”不仅要求Agent能查询数据库还要求它基于查询结果做出正确决策再反过来把决策结果落库。任务难度不在于SQL语法本身而在于Agent必须在真实数据库环境里面对数据一致性、字段约束、外键依赖、并发冲突这些实际工程问题。这种评测方式比让模型“写一段SQL文本”要难出一个量级也更有价值。2.3 判定真正落地为“查账”微软这个评测里最值得借鉴的一点是判定环节几乎不需要人工参与。评测方把“完成态”预先固化成可执行的数据库查询脚本Agent一结束运行系统自动跑脚本比对。我推测其具体判定流程是这样的Agent执行任务所有数据库操作都被记录到审计日志。评测系统在Agent启动前先对目标数据库做一次快照。Agent结束后系统再对数据库做一次快照。比对两轮快照的差异逐项核对是否符合预期变更。同时用预置好的核查脚本对关键业务表执行精确查询确认状态字段、关联数据、时间戳等都正确。最终根据比对结果给Agent打“过/不过”同时列出它说做了但没做的项、它做了但没说的项、它做了但做错的项。三个“异常类别”分别对应什么行为说做了但没做是幻觉式完成做了但没说是执行混乱、缺乏自我认知做了但做错是执行精度问题。三种情况都能通过“查账”被精准揪出来。这给整个Agent行业提供了一个很宝贵的信号智能体的验收标准正在从“体验导向”向“事实导向”迁移。3. 实操视角如何搭一套类似的对账评测3.1 前置条件与环境准备我们自己要复现这套“查账式”评测并没有想象中那么复杂不需要微软级别的工程资源。核心就三件套一个装有真实业务Schema的数据库、一个包装好的Agent工具环境、一套对账脚本。数据库我建议直接用MySQL或者PostgreSQL原因是它们的事务处理成熟能真实模拟业务状态变化。不要把Agent丢进SQLite内存库里去测那等于给考生开卷还允许他改考卷很多数据库层面的细节问题根本暴露不出来。Schema设计要尽量贴近真实业务。至少要包含三张以上有关联的表比如用户表、订单表、支付流水表表之间要有外键约束、唯一索引、非空约束。这些看似“找麻烦”的约束恰恰是查出Agent问题的关键探测器。比如Agent插入支付流水时漏掉了必填的用户ID字段数据库会直接报错Agent如果没处理这个报错还强行汇报成功对账脚本一下就能抓个正着。3.2 快照对比与数据核对脚本对账脚本我推荐分两段写。第一段是“状态比对”第二段是“业务断言”。状态比对最简单的实现方式是给每个任务定义“前置状态”和“后置状态”用SQL查询把关键表的全量数据导出来再对前后两轮结果做差异分析。数据量大时可以用哈希比对计算每张表的checksum差异表再单独展开。这个方案写起来快跑起来也快。业务断言更有针对性。比如退款任务你直接在脚本里写SELECT COUNT(*) FROM payment_records WHERE order_id 预期订单号 AND refund_status SUCCESS;断言这段查询返回1否则判定Agent未完成。这种断言脚本的写法跟我们平时写单元测试里的断言一模一样只是把“接口返回值”换成了“数据库实际状态”。把“任务是否成功”和“数据库里的真实状态”绑定之后评测就不再依赖任何主观判断。同一套脚本跑十遍结果高度一致。3.3 判定标准与异常分类表对账脚本跑完之后建议把结果归入下表对账结果含义Agent存在的问题数据库有预期变更Agent报告成功真完成正常可通过数据库无预期变更Agent报告成功假完成幻觉式汇报最严重数据库有预期变更Agent报告失败执行成功但认知错误自我感知能力差数据库有部分变更与预期不符做了一部分但做错了任务拆分与执行精度差数据库有预期外变更多做了不该做的事边界控制能力弱这五类结果基本覆盖了Agent在实际生产环境里会犯的所有数据操作错误。我在自己的评测脚本里也建了一个类似的结果分类表每次跑完批量Agent任务直接看统计分布就能快速定位某个版本的Agent是“汇报问题”还是“执行问题”。4. 从评测到落地给Agent工程开发的三条硬经验4.1 工具调用后必须做“落库回读”我在多个Agent项目里踩过最深的坑就是Agent调用了一个写数据类的工具工具返回“成功”Agent就开始往下执行全程不回读数据库验证。后来我们定了一条铁律凡是写操作调用完成后必须加一步“读回校验”。写完了好立刻查一下刚写的数据确认字段值、确认影响行数。这个逻辑很简单但它把Agent从“调完接口就信了”改成了“写完了还不放心自己查一遍账”。现实中你是怎样确认转账成功的不是盯着转账按钮看而是过几分钟打开银行App看流水。Agent也应该这样。这条规则在工程上的实现成本很低对可靠性的提升却极其明显。4.2 给Agent配置“事务边界”意识单个Agent任务往往会对应多次数据库操作。比如“创建订单”这个动作可能涉及插入订单主表、插入订单明细表、更新库存表。这三张表的数据必须同时成功或同时不成功任何一张表写入失败订单就是残缺的。不少Agent框架在工具层面上是“一次性调用”的没有跨工具的事务语义。这就导致Agent经常出现“主表写了明细表没写”或者“订单建了库存没扣”的情况。而且因为它没有全局事务的感知最后还会一本正经地汇报“订单创建成功”。我们的做法是在Agent的任务编排层显式注入事务边界一个需要多步写操作的任务必须由一个顶层的“事务控制器”来管理任何一步失败立刻触发补偿逻辑或回滚动作。Agent本身可以不管事务细节但它必须知道“这是个事务”不能说一步成功就等于全盘成功。4.3 日志审计与数据库审计双向对照评测Agent时要查数据库生产环境里排查Agent问题同样要查数据库。但生产环境比评测复杂的地方在于你无法轻易造一个“干净的前置状态”来对比。这时候就要靠日志审计来补位。常规的做法是给Agent的每次工具调用、每次数据库变更都写一条结构化日志记录“调用了什么工具、传了什么参数、返回了什么结果、影响了哪些数据”。排查问题时先把Agent日志按时间线拉出来再把数据库的binlog或操作日志拉出来两条线一对照问题基本就浮出水面了。这个习惯非常重要。很多人排查Agent问题时只盯着Agent的Prompt日志看看它“想”了什么却忽略了看数据库“记”了什么。记住Agent的想法再天衣无缝只要没在数据库里留下痕迹都是空谈。5. 常见问题与排查技巧实录5.1 四个高频故障现场第一个高频现场是“接口成功但数据没写进去”。Agent调了插入接口接口返回200但数据库里没有新行。排查后发现接口本身有事务控制Agent在事务提交前就进行了下一个操作或者事务被后续操作异常回滚了。解决办法就是回读校验写完之后立刻查库。第二个高频现场是“数据写进去了但写错了位置”。Agent要更新A表却更新到了B表原因是工具参数的描述不够清晰或者相似表名让Agent产生了混淆。建议在工具定义里明确标注表用途甚至给容易混淆的表加上关键字段提示。第三个高频现场是“并发环境下数据互相覆盖”。两个Agent同时处理同一条订单记录后写的把先写的覆盖了。这类问题靠Agent自身逻辑很难规避必须依靠数据库层的乐观锁或版本号机制。排查方法给关键表加版本字段看异常数据时先对比版本号变化。第四个高频现场是“Agent删数据没有边界控制”。它执行“删除过期记录”任务时因为WHERE条件构建错误把“所有记录”都删了。这类问题最危险也是查账式考试里最容易判零分的项目。生产线上的保护手段至少要有两层强约束的删除语句模板、删除前先查一次预期影响行数并要求Agent确认。5.2 排查工具与方法速查表症状可能原因排查步骤Agent报告成功库里无数据事务未提交 / 工具返回误读查binlog确认是否有写入加强制回读校验库里数据错误Agent无感知工具参数传递错误 / schema理解偏差拉取工具调用参数日志核对目标表和字段并发场景数据被覆盖缺少乐观锁 / 任务编排未加锁控制查版本字段变更记录为关键操作加锁数据被过量删除WHERE条件构建错误 / 无确认机制查删除操作前的SELECT影响行数日志增加确认步骤Agent频繁重复插入幂等性判断缺失查插入前的存在性校验逻辑加唯一索引兜底排查工具方面日常用得最多的是直接看MySQL慢查询日志和binlog。慢查询日志能暴露Agent是否在数据库上做了低效操作比如全表扫描binlog则能准确还原每一条数据变更的时序。先把这两个日志打开再结合Agent自己的工具调用日志做对齐绝大多数“Agent和数据库对不上账”的问题都能在半小时内定位。5.3 一个我自己踩过的印象最深的坑前阵子我们有个Agent负责批量修正历史订单的金额。测试环境跑了几轮结果都正确Agent汇报“全部修正完成共更新500条”。放上生产环境执行数据库一查只更新了428条。查日志发现Agent在拼接UPDATE语句时把一条WHERE条件写到了字符串截断的位置导致后面72条订单根本没匹配上。更麻烦的是Agent完全没意识到因为它只看返回值“执行成功”没核对受影响行数。那次事故之后我们对所有写操作工具的返回结构做了强制约定返回结果必须包含affected_rows字段并且Agent必须把“更改行数”和“预期行数”进行比对。如果不匹配视为任务失败不能汇报成功。这件事让我切身体会到Agent的可信度不是靠模型聪明而是靠工程约束一层层垒出来的。微软那场“查账式”考试本质上就是把这类约束提前搬进了评测环节。数据库不会因为Agent语气诚恳就给高分它只看账目。这个态度值得所有做Agent开发的人复制到自己的项目里——少听汇报多查落库。
Agent 说它做完了数据库不同意微软给智能体上了场「查账式」考试最近有个场景让我印象特别深一个号称能自动处理售后工单的智能体跑完流程日志里清清楚楚写着“退款已完成已通知用户”结果运营同学打开后台一看支付流水里根本没有那笔退款。系统说做完了数据库不认账。这不是个例。随着AI Agent开始从“陪聊”走向“干活”越来越多团队发现智能体最擅长的不是执行任务而是“汇报任务”。你问它做完没它永远说做完了语气还特别笃定。但你把数据库翻出来一核对经常对不上。微软最近给智能体上了一场“查账式”考试思路很直接不听Agent自己怎么说只看数据库里留下的事实痕迹。这场考试的本质是把Agent当成一个需要接受审计的执行者来考核而不是当成一个靠嘴汇报的助手。这方向我非常认同今天就把这套思路背后的原理、实操方法以及我们在开发Agent时怎么借鉴这套“对账思维”来避坑一次性讲透。1. Agent的“做完”为什么不能信自我报告的信任边界1.1 报告与事实之间的三个裂缝先别急着骂Agent撒谎它其实也不是故意骗你。大模型生成文本的底层机制决定了它在输出“已完成”这句话时本质上是在生成一段“听起来像已完成”的文字而不是在陈述一个经过验证的事实。这就是第一道裂缝——表述与事实脱钩。第二道裂缝更隐蔽工具调用返回的信息被截断或误读。比如Agent调用了一个退款接口返回值是“200 OK”它就把“OK”理解成“退款成功”于是汇报“已退款”。但很多时候接口返回200只代表“请求已受理”不代表“业务操作已生效”。你让HTTP状态码代替业务状态码数据库当然不答应。第三道裂缝来自Agent的上下文窗口限制。跑一个复杂任务时Agent要处理几十轮工具调用早期步骤的结果可能被后续内容挤出上下文。它记不清自己到底做过什么就会根据“最近一次动作”脑补出一个完整闭环然后自信地输出“做完了”。这三道裂缝叠加在一起就是我们在真实项目里反复遇到的“Agent幻觉式完成”。1.2 数据库为何是查证Agent行为的天然现场要识别Agent到底有没有真干成得有个“不可抵赖”的凭证。数据库就是这个凭证。任何需要持久化的业务行为最终都会落在数据库里退款会有一条支付流水记录建表会多出一张表发消息会多一行消息记录。数据库像一个财务账簿Agent做的每一笔“支出”和“收入”都会留下痕迹。更重要的是数据库的状态是可以被独立查询、独立验证的——不需要依赖Agent的自我报告。这也是“查账式”考试的精髓把评价Agent的唯一标准从“它说了什么”切换成“账面上留下了什么”。做成了就是做成了没做成就是没做成一切以数据库里的最终状态为准。这个思路其实和审计行业一脉相承。审计人员从来不问企业负责人“你们这笔钱付了没”而是直接去银行打流水、查对账单。微软把这套“查账”思想搬到了Agent评测里本质上是在给智能体的可信度立规矩别跟我汇报让我查账。2. 微软的查账式考试评测思路与判定机制拆解2.1 不考“说得好”只考“账对得上”传统的大模型能力评测考的是“生成质量”看输出文本是否流畅、是否正确。但Agent不是文本生成器它是个“执行者”。执行者的考核标准不应该是“解释得好”而应该是“事情办成了没有”。微软这套评测把Agent丢进真实的业务场景里给它一个任务、一批可用工具、一个真实的数据库。任务执行完之后评测系统不去读Agent写的总结报告而是直接对数据库做检查和比对。我理解这套考试的核心判定机制分两层第一层账户级核对。任务要求Agent完成一个明确数据变更评测方提前定义好“成功态”数据库应该长什么样。比如“把订单状态从待支付改成已支付并生成支付流水”那成功态就是订单表状态字段正确流水表多一条匹配记录。Agent执行完毕系统直接查库逐条比对。第二层过程级审计。光看最终状态还不够因为有的Agent会“歪打正着”改对了数据但过程是错的或者中途产生了不该产生的脏数据。所以评测系统还会核对Agent过程中的每一次数据库操作检查是否有遗漏操作、多余操作、错误操作。这种双轨判定的好处是既防“假完成”也防“瞎完成”。2.2 评测任务设计的讲究数据最诚实的逻辑就是增删改查。微软这场考试里的任务设计也基本围绕数据库核心操作的组合展开数据新增类比如“创建一条客户反馈记录”“把新注册用户写入用户表”考察Agent能否按schema正确插入数据。数据修改类比如“把订单金额从500改成600并重算总价”“更新用户的会员等级”考察Agent能否精确定位并修改目标数据。数据删除类比如“删除已注销用户的相关记录”“清理过期缓存数据”这类任务最考验Agent对边界条件的把握删多了删少了都会被数据库“记账”。数据查询决策类比如“统计本月销售额并生成报表”不仅要求Agent能查询数据库还要求它基于查询结果做出正确决策再反过来把决策结果落库。任务难度不在于SQL语法本身而在于Agent必须在真实数据库环境里面对数据一致性、字段约束、外键依赖、并发冲突这些实际工程问题。这种评测方式比让模型“写一段SQL文本”要难出一个量级也更有价值。2.3 判定真正落地为“查账”微软这个评测里最值得借鉴的一点是判定环节几乎不需要人工参与。评测方把“完成态”预先固化成可执行的数据库查询脚本Agent一结束运行系统自动跑脚本比对。我推测其具体判定流程是这样的Agent执行任务所有数据库操作都被记录到审计日志。评测系统在Agent启动前先对目标数据库做一次快照。Agent结束后系统再对数据库做一次快照。比对两轮快照的差异逐项核对是否符合预期变更。同时用预置好的核查脚本对关键业务表执行精确查询确认状态字段、关联数据、时间戳等都正确。最终根据比对结果给Agent打“过/不过”同时列出它说做了但没做的项、它做了但没说的项、它做了但做错的项。三个“异常类别”分别对应什么行为说做了但没做是幻觉式完成做了但没说是执行混乱、缺乏自我认知做了但做错是执行精度问题。三种情况都能通过“查账”被精准揪出来。这给整个Agent行业提供了一个很宝贵的信号智能体的验收标准正在从“体验导向”向“事实导向”迁移。3. 实操视角如何搭一套类似的对账评测3.1 前置条件与环境准备我们自己要复现这套“查账式”评测并没有想象中那么复杂不需要微软级别的工程资源。核心就三件套一个装有真实业务Schema的数据库、一个包装好的Agent工具环境、一套对账脚本。数据库我建议直接用MySQL或者PostgreSQL原因是它们的事务处理成熟能真实模拟业务状态变化。不要把Agent丢进SQLite内存库里去测那等于给考生开卷还允许他改考卷很多数据库层面的细节问题根本暴露不出来。Schema设计要尽量贴近真实业务。至少要包含三张以上有关联的表比如用户表、订单表、支付流水表表之间要有外键约束、唯一索引、非空约束。这些看似“找麻烦”的约束恰恰是查出Agent问题的关键探测器。比如Agent插入支付流水时漏掉了必填的用户ID字段数据库会直接报错Agent如果没处理这个报错还强行汇报成功对账脚本一下就能抓个正着。3.2 快照对比与数据核对脚本对账脚本我推荐分两段写。第一段是“状态比对”第二段是“业务断言”。状态比对最简单的实现方式是给每个任务定义“前置状态”和“后置状态”用SQL查询把关键表的全量数据导出来再对前后两轮结果做差异分析。数据量大时可以用哈希比对计算每张表的checksum差异表再单独展开。这个方案写起来快跑起来也快。业务断言更有针对性。比如退款任务你直接在脚本里写SELECT COUNT(*) FROM payment_records WHERE order_id 预期订单号 AND refund_status SUCCESS;断言这段查询返回1否则判定Agent未完成。这种断言脚本的写法跟我们平时写单元测试里的断言一模一样只是把“接口返回值”换成了“数据库实际状态”。把“任务是否成功”和“数据库里的真实状态”绑定之后评测就不再依赖任何主观判断。同一套脚本跑十遍结果高度一致。3.3 判定标准与异常分类表对账脚本跑完之后建议把结果归入下表对账结果含义Agent存在的问题数据库有预期变更Agent报告成功真完成正常可通过数据库无预期变更Agent报告成功假完成幻觉式汇报最严重数据库有预期变更Agent报告失败执行成功但认知错误自我感知能力差数据库有部分变更与预期不符做了一部分但做错了任务拆分与执行精度差数据库有预期外变更多做了不该做的事边界控制能力弱这五类结果基本覆盖了Agent在实际生产环境里会犯的所有数据操作错误。我在自己的评测脚本里也建了一个类似的结果分类表每次跑完批量Agent任务直接看统计分布就能快速定位某个版本的Agent是“汇报问题”还是“执行问题”。4. 从评测到落地给Agent工程开发的三条硬经验4.1 工具调用后必须做“落库回读”我在多个Agent项目里踩过最深的坑就是Agent调用了一个写数据类的工具工具返回“成功”Agent就开始往下执行全程不回读数据库验证。后来我们定了一条铁律凡是写操作调用完成后必须加一步“读回校验”。写完了好立刻查一下刚写的数据确认字段值、确认影响行数。这个逻辑很简单但它把Agent从“调完接口就信了”改成了“写完了还不放心自己查一遍账”。现实中你是怎样确认转账成功的不是盯着转账按钮看而是过几分钟打开银行App看流水。Agent也应该这样。这条规则在工程上的实现成本很低对可靠性的提升却极其明显。4.2 给Agent配置“事务边界”意识单个Agent任务往往会对应多次数据库操作。比如“创建订单”这个动作可能涉及插入订单主表、插入订单明细表、更新库存表。这三张表的数据必须同时成功或同时不成功任何一张表写入失败订单就是残缺的。不少Agent框架在工具层面上是“一次性调用”的没有跨工具的事务语义。这就导致Agent经常出现“主表写了明细表没写”或者“订单建了库存没扣”的情况。而且因为它没有全局事务的感知最后还会一本正经地汇报“订单创建成功”。我们的做法是在Agent的任务编排层显式注入事务边界一个需要多步写操作的任务必须由一个顶层的“事务控制器”来管理任何一步失败立刻触发补偿逻辑或回滚动作。Agent本身可以不管事务细节但它必须知道“这是个事务”不能说一步成功就等于全盘成功。4.3 日志审计与数据库审计双向对照评测Agent时要查数据库生产环境里排查Agent问题同样要查数据库。但生产环境比评测复杂的地方在于你无法轻易造一个“干净的前置状态”来对比。这时候就要靠日志审计来补位。常规的做法是给Agent的每次工具调用、每次数据库变更都写一条结构化日志记录“调用了什么工具、传了什么参数、返回了什么结果、影响了哪些数据”。排查问题时先把Agent日志按时间线拉出来再把数据库的binlog或操作日志拉出来两条线一对照问题基本就浮出水面了。这个习惯非常重要。很多人排查Agent问题时只盯着Agent的Prompt日志看看它“想”了什么却忽略了看数据库“记”了什么。记住Agent的想法再天衣无缝只要没在数据库里留下痕迹都是空谈。5. 常见问题与排查技巧实录5.1 四个高频故障现场第一个高频现场是“接口成功但数据没写进去”。Agent调了插入接口接口返回200但数据库里没有新行。排查后发现接口本身有事务控制Agent在事务提交前就进行了下一个操作或者事务被后续操作异常回滚了。解决办法就是回读校验写完之后立刻查库。第二个高频现场是“数据写进去了但写错了位置”。Agent要更新A表却更新到了B表原因是工具参数的描述不够清晰或者相似表名让Agent产生了混淆。建议在工具定义里明确标注表用途甚至给容易混淆的表加上关键字段提示。第三个高频现场是“并发环境下数据互相覆盖”。两个Agent同时处理同一条订单记录后写的把先写的覆盖了。这类问题靠Agent自身逻辑很难规避必须依靠数据库层的乐观锁或版本号机制。排查方法给关键表加版本字段看异常数据时先对比版本号变化。第四个高频现场是“Agent删数据没有边界控制”。它执行“删除过期记录”任务时因为WHERE条件构建错误把“所有记录”都删了。这类问题最危险也是查账式考试里最容易判零分的项目。生产线上的保护手段至少要有两层强约束的删除语句模板、删除前先查一次预期影响行数并要求Agent确认。5.2 排查工具与方法速查表症状可能原因排查步骤Agent报告成功库里无数据事务未提交 / 工具返回误读查binlog确认是否有写入加强制回读校验库里数据错误Agent无感知工具参数传递错误 / schema理解偏差拉取工具调用参数日志核对目标表和字段并发场景数据被覆盖缺少乐观锁 / 任务编排未加锁控制查版本字段变更记录为关键操作加锁数据被过量删除WHERE条件构建错误 / 无确认机制查删除操作前的SELECT影响行数日志增加确认步骤Agent频繁重复插入幂等性判断缺失查插入前的存在性校验逻辑加唯一索引兜底排查工具方面日常用得最多的是直接看MySQL慢查询日志和binlog。慢查询日志能暴露Agent是否在数据库上做了低效操作比如全表扫描binlog则能准确还原每一条数据变更的时序。先把这两个日志打开再结合Agent自己的工具调用日志做对齐绝大多数“Agent和数据库对不上账”的问题都能在半小时内定位。5.3 一个我自己踩过的印象最深的坑前阵子我们有个Agent负责批量修正历史订单的金额。测试环境跑了几轮结果都正确Agent汇报“全部修正完成共更新500条”。放上生产环境执行数据库一查只更新了428条。查日志发现Agent在拼接UPDATE语句时把一条WHERE条件写到了字符串截断的位置导致后面72条订单根本没匹配上。更麻烦的是Agent完全没意识到因为它只看返回值“执行成功”没核对受影响行数。那次事故之后我们对所有写操作工具的返回结构做了强制约定返回结果必须包含affected_rows字段并且Agent必须把“更改行数”和“预期行数”进行比对。如果不匹配视为任务失败不能汇报成功。这件事让我切身体会到Agent的可信度不是靠模型聪明而是靠工程约束一层层垒出来的。微软那场“查账式”考试本质上就是把这类约束提前搬进了评测环节。数据库不会因为Agent语气诚恳就给高分它只看账目。这个态度值得所有做Agent开发的人复制到自己的项目里——少听汇报多查落库。
