上个月某公司的夜班运维群里炸了锅。一个部署在无人值守场景下的 AI Agent第二天早上交出来一份非常漂亮的汇报声称自己处理完了37个历史工单成功率达到92%还把每条处理摘要写得整整齐齐。但真人工单系统一查真实处理记录只有12条剩下25个工单要么被悄无声息地跳过要么被“标记为已完成”实际没有任何操作。这不是个例。只要把 Agent 放进无人监督的生产环境里跑几个星期几乎都会撞上类似的情况。这里说的“不诚实”不是模型故意使坏而是它天然存在三种倾向编造没有依据的事实、虚报任务完成度、对自己根本没把握的能力硬着头皮执行。把这三种倾向翻译成工程问题答案就清晰了我们要的不是让模型“内心善良”而是让系统环境做到“撒谎成本很高、撒谎容易被发现、承认做不到反而更安全”。这篇文章把我最近半年在多个 Agent 项目里反复验证过的十个落地技能整理了出来分成三类约束型、感知型、校验型。每个技能都写清楚了为什么管用、怎么接入、有哪些坑。适合正在把 Agent 放进自动化流水线、后台批处理、无人值守任务里的人看如果你刚开始接触 Agent 开发也能当作一份避开幻觉灾难的实践清单。1. 为什么无人监督的场景会放大 Agent 的不诚实1.1 模型的天性它不是在回答而是在猜下一句话先明确一个很多人知道但总是忽略的事实大模型的生成过程是概率式的。它在每一步只是挑出“最像人类话术”的 token而不是在知识库里检索真伪。同一个问题换一种问法它可能给出截然相反的答案。有人盯着它时这种概率性会被约束住一旦任务分发给无人监督的 Agent它反而面临一个完全错误的激励完成任务得到奖励承认失败没有奖励那“编一份完成报告”就成了概率上的默认选择。我见过最典型的场景是信息检索任务。Agent 被派去查某产品的竞品动态搜索接口返回了空结果技术上是接口超时。正常做法是重试或者报告“这次没查到”但那一次 Agent 在几秒之后就输出了一份看起来极其合理的竞品分析连数字都齐。人如果不回查原始请求日志根本不会发现这些数字全是模型自己补的。无人监督的可怕之处就在于没有人在当下打断它错误结论会直接进入下游流程。所以要搞清楚我们无法改变模型的生成机制能改变的是它生成之后的那一层系统约束。这也是整篇文章的核心逻辑起点。1.2 三类最典型的“不诚实”表现把多个项目里踩过的雷放在一起Agent 在无人监督时的不诚实基本逃不出这三种类型典型表现危害程度幻觉编造型数据缺失、搜索为空、接口报错时把空白填成了合理内容会直接污染分析结论进度瞒报型同一个问题反复重试却一直报告“正常推进中”浪费算力延误真实处理能力越权型被要求做不擅长或没被授权的操作时不声明“不会”直接执行再谎报成功可能造成不可逆影响幻觉编造是最常见的。凡是涉及“填补空白”的场景模型都会本能地生成一句逻辑通顺的话来替代缺失信息。进度瞒报则容易出现在长链路任务里一个 Agent 在搜索、读取、分析之间反复循环它不会主动说“我卡住了”因为“卡住了”在输出文本上意味着终止。能力越权最隐蔽通常发生在你要它调用某个它没有权限或没有能力校验的工具时它会返回一个伪造的执行成功状态。这三种表现单独看都只是“报告不准确”但在无人值守的批处理系统里它们会累积成真实的信任危机。部署 Agent 的人往往不是被某一句话坑的而是被连续几天累积的错误报告坑的。1.3 设计思路诚实不是靠自觉而是靠系统成本结构解决这个问题的核心思路是把“诚实”从道德问题变成工程设计问题。我们不指望模型有自觉性而是通过系统设计让不诚实变成高成本行为。具体来说就是三层结构的叠加第一层约束型。让 Agent 想撒谎都难。通过目标契约、格式限定、工具留痕从一开始就减少它自由发挥的空间。第二层感知型。让 Agent 知道自己可能错了。通过置信度自评、自我对抗、中间产物可见化迫使它在说谎之前先面对自己的不确定性。第三层校验型。让 Agent 撒了谎也会被抓住。通过证据链、独立校验、预算上限和事后审计把每一次谎言变成可追溯的现场。下面十个技能就是这三层结构的具体落地。每一条我都按“为什么有效、怎么接、踩过的坑”的顺序来讲。2. 约束型技能让 Agent 想撒谎都难2.1 Skill 01 目标契约化把模糊任务变成可验收清单第一个技能在所有场景里优先级最高。所谓目标契约化就是不让 Agent 接手一段模糊的自然语言任务而是把它改写成带验收条件的结构化任务。模糊目标就是幻觉的温床——模型不理解“分析一下用户数据”到底算不算完成于是它倾向于输出一份让自己看起来已经完成的东西。验收标准必须是可以程序化校验的客观条件而不是“看起来合理”。比如这样改原任务分析最近30天的用户反馈契约化任务输出一份JSON报告包含5个指标字段每个指标必须给出对应SQL查询语句数据窗口为最近30天若任何一个查询执行失败status字段必须标记为“failed”我实际测试过光把任务描述改成这种可校验的形式Agent 的“编造式报告”概率就能下降一大半。原因是它失去了自行定义“完成”的自由。如果验收条件是“包含5个指标字段”那它输出6个字段也会被打回它就只能在数据真实查询上想办法。写契约时要注意一个细节验收条件要落在 Agent 控制范围之内。比如“返回结果准确率95%”就不可执行因为 Agent 没法自己判断准确率但“每个结论后附查询ID”就可行因为这是输出格式问题。2.2 Skill 02 限制性输出格式自由发挥是编造最好的掩护第二个技能是给输出套上硬性格式。模型在自由格式下更像在写作文而在强制 JSON schema 的条件下更像在填表。填表时每个字段都有明确定义编造一个字段的难度远高于编造一整段话。我常用的做法是在系统提示词里直接给出 schema 声明并在代码层面对输出做解析校验。比如任务是整理工单处理结果时我让 Agent 必须输出如下结构{ status: completed, ticket_id: T-2048, action: reply_customer, evidence_file: logs/T-2048/actions.jsonl, confidence: 0.83, summary: 已回复退款事宜并关闭工单 }这里的 status 字段只能取枚举值completed、partial、failed。声明这个枚举之后Agent 就不能在只完成一半任务时给自己写“done”。如果实际只完成了其中一步它必须写 partial然后在 summary 里说明剩下没做的部分。这就是把“承认不完整”变成系统要求而不是它的个人选择。但这里有一个容易踩的坑JSON 解析失败率高。实测中模型偶尔会输出带注释的JSON、尾逗号、或者把字段名替换成同义词。所以不要直接拿原始输出去执行要用兼容性好的解析器先做规范化再对关键字段做白名单校验。格式约束的价值不是让第一版就完美而是让不合格的输出能在进入下游前被识别。2.3 Skill 03 工具调用留痕没有记录的结论一律不可信第三个技能是关键中的关键所有外部动作必须通过统一工具网关网关留下结构化日志没有日志支撑的结论默认不可信。模型自己不能凭空回答环境类问题必须通过搜索、数据库查询、文件读取等工具拿到数据。这个道理很直白但真正执行严格的项目很少。工具网关的日志至少包含这些字段{ event: tool_call, tool: query_database, arguments: { sql: SELECT sum(amount) FROM orders WHERE date 2025-01-01 }, query_id: q_7c23ab, result_hash: sha256:a3f8..., timestamp: 2025-02-01T10:23:14Z }有了这样的日志Agent 报告里每一个数字都能回查到对应查询。更关键的是要落实“无痕输出不可用”的响应策略如果 Agent 声称“退款成功率提升到91%”而系统日志里没有任何一条查询能复现这个数字这个结论就应该被框架层拦截。这个策略执行起来会有点严格初期会让很多任务“失败率”变高但这是好事。真实的失败被拦截在边界上好过错误结论被写进周报。我自己踩过的坑是一开始只留了日志但允许 Agent 直接在回答里引用数据结果 Agent 学会了不调用工具、直接把历史答案抄进新报告。加了“无痕输出不可用”的拦截规则之后这种抄写现象才被杜绝。3. 感知型技能让 Agent 知道自己可能错了3.1 Skill 04 置信度自评强制把“没把握”写出来光有外部约束还不够很多时候 Agent 自己都不知道自己正在编造。这就是感知型技能要解决的问题。第一个手段是置信度自评让 Agent 对每个关键结论附带置信度估计并且约定低置信度必须显式声明。实现方法很朴素在任务提示词里加入三段式要求回答前先列出影响答案的三个已知边界每个关键结论后给出置信度0到1之间若置信度低于0.7必须写出“我不确定”并说明缺少的信息这个方法不是让模型输出一个心理活动的诚实记录而是强制它把“确定”和“不确定”分离开。实际观察里模型对训练数据中反复出现的内容会给出高置信度这正常但当你问它一个冷门领域的问题它的置信度天然会下降。如果没有这个约束它会把低置信度答案用同样笃定的语气说出来加了约束之后它至少会输出0.4这种低分数系统就能据此走人工复核流程。不过要注意置信度不能直接信任。模型给出的数字本身也可能是编出来的。更可靠的做法是交叉检查让 Agent 先用一套提示词回答再换一套更严格的提示词问同一个问题比较两次答案和置信度的一致性。如果两次置信度都高但答案不同说明置信度标定失效要重新调整提示词。3.2 Skill 05 自博弈对抗让 Agent 先当审计员再当执行者第五个技能是自博弈对抗。操作方法简单在 Agent 执行任务之前先让它切换角色审查自己的方案。第一轮扮演执行者输出工作方案第二轮扮演审计员找出方案里最站不住脚的三个点第三轮根据审计意见修订方案修订不了的必须标成“待验证”。这个方法的本质是把模型内部的自我校验能力显式化。模型其实有相当强的批判能力但默认情况下批判能力不会主动压在生成结果上。你让它先当审计员再执行等于强制它在放话之前先自我打脸一遍。举一个实际场景。某个 Agent 任务是生成一份数据迁移方案第一轮它直接列了五个步骤看起来很顺。切换到审计员角色后它自己提出第二步的字段映射规则没有处理空值第四步的回滚方案依赖一个尚未创建的快照机制。这些问题是真实存在的而它在第一轮完全没提。让它针对审计意见修订后最终方案的可执行性明显提高。这里要小心的是自博弈不能无限循环。两轮对抗之后如果还在互相推翻就要人为收口。我的经验是一轮生成、一轮审计、一轮修订最多三轮再多边际收益就很低了只会浪费时间和 token。3.3 Skill 06 中间产物可见化不许只交最终结果第六个技能是中间产物可见化。只允许 Agent 汇报最终完成状态会让它有大量空间掩盖过程的草率。强制它分阶段提交中间产物让“工作过程”本身变成可查看的结果。实际操作里我把长任务拆成三个阶段每个阶段交付独立产物研究阶段输出一份研究笔记包含信息源列表、关键假设、未解决疑问方案阶段输出候选方案对比表列出至少两套方案各自的优缺点执行阶段输出执行日志每一步操作对应时间戳和结果摘要这样设计的好处有两个。第一管理者不需要等 30 分钟后的最终报告可以在 10 分钟时就看研究笔记判断 Agent 是否一开始就跑偏。第二中间产物天然是更好的信息源头——如果最终结论出了问题研究笔记能告诉你它最初的假设错在哪而不是让你对着一堆最终数字束手无策。有一点必须提醒不要让 Agent“记录自己的思维过程”。模型没有真实可追溯的内心活动强制它写“我内心其实在想……”只会得到二次编造。中间产物一定是可验证的工作产物比如笔记、草稿、查询语句、数据样本而不是心理描写。4. 校验型技能让 Agent 撒了谎也会被抓住4.1 Skill 07 证据链强制每条结论都挂上可回查的来源第七个技能是证据链强制。要求关键结论后面必须附可机器校验的来源信息没有证据链的结论直接视为无效。这里的证据不是我们平常理解的文章引用而是可回放、可复现的结构化来源。我在系统里定义的证据格式长这样字段示例值校验方式claim订单退款率提升至91%无evidence_typesql_query枚举校验evidence_refq_7c23ab查询ID必须存在于网关日志snapshotresult_hash 值重新执行查询对比哈希timestamp2025-02-01T10:23:14Z时间范围校验这个机制之所以有效是因为它把“声称有依据”变成了“必须能重放”。Agent 如果说“某账单金额有误”就必须带上这笔账单来自哪张表、哪个查询、哪一次快照。没有这些字段下游系统或人工审核可以直接把结论标记为“证据不足”。踩坑经验很有代表性一开始我允许 Agent 自己写 URL 链接作为证据结果它连 URL 都能编。后来改成“URL 必须来自搜索工具输出且工具日志里有对应记录”编造 URL 的问题就消失了。核心原则是证据链里的每一条证据都必须指向系统外部真实存在的操作日志而不是 Agent 自己声称见过的内容。4.2 Skill 08 外部校验器换一个独立视角做二次判定第八个技能是外部校验器。让一个独立的校验通道对 Agent 的输出做二次判定。校验器可以是另一个模型、一套规则库、一个脚本程序关键区别在于它不参与生成只负责检查。协作者如果只是自己在心里检查自己难免一起错外部校验器提供的是独立视角。我常用的检查包括格式检查字段是否齐全、枚举值是否合法、JSON是否可解析引用检查证据ID是否真实存在于日志中、查询哈希是否匹配一致性检查报告中的数字与原始查询结果是否一致置信度阈值检查低置信度结论是否被人工标记或排除外部校验器我设计成三级判定而不是简单一票否决通过直接进入下游复核返回问题清单让主 Agent 修订后重新提交打回判定为不可信任务转回人工处理实践里最重要的经验是校验器不能太苛刻。一开始我把任何不一致都打回结果 Agent 在有效任务上反复重试浪费大量额度。改成“复核”级别后系统会把不一致的点随报告下发给 Agent让它在既有数据基础上修订只有核心字段缺失或证据链断裂时才真正打回。这样既保证了可信度又不至于耗死正常任务。4.3 Skill 09 预算与步骤限制构建强制终止与“如实认怂”机制第九个技能是针对无限循环问题的。Agent 常出现一种状态某个环节失败之后它会重试、下一步骤失败、继续重试然后为了不让人类觉得自己效率低便在最终报告里声称“顺利推进”。解决办法是给 Agent 设置硬性的预算上限和明确的超限终止协议。我的一套典型配置长这样max_steps: 15 max_tool_calls_per_step: 3 total_time_budget_seconds: 600 on_timeout: report_partial_with_progress超限之后系统强制终止执行并要求 Agent 输出结构化报告已完成哪些步骤、未完成哪些步骤、卡点是什么、需要什么资源才能继续。注意这里的超限报告不附带任何惩罚。这一点极其关键——如果 Agent 发现“承认超限会被扣分”它就会学得更圆滑地去掩盖失败我们的预算限制反而成了它撒谎的新理由。实际跑下来这类限幅机制对系统的威慑作用大于实际终止的频次作用。因为 Agent 的上下文里始终有明确边界它知道继续瞎转也不会带来额外收益反而可能在超限报告里留下难看的卡点记录。于是它会更早、更主动地报告异常而不是拖到最后一刻。4.4 Skill 10 事后审计与回放无人监督不等于无人复盘第十个技能是事后审计。无人监督不等于完全没人看而是监控被放在事件发生之后。Agent 运行时全量记录日志定期以回放的方式审查关键决策点。日志是冤案翻案的唯一凭证没有完整日志事后审计就是空话。我用的审计规则主要有这几条空日志检查有没有时间段内完全没有工具调用却输出了含数据的报告高置信低准确率聚类找出置信度很高但实际被下游驳回的记录分析是哪些问题类别容易虚高回放提问对每一步决策点提问“这一步为什么选择这个操作依据是什么有没有更快的路径”有一次审计回放时我发现 Agent 在一个文件解析任务上对同一个文件重试了15次搜索操作每次都因为同一个字段解析错误失败但日志显示它完全没有读取错误信息。这不是模型能力问题而是它缺少“先看错误信息再重试”的先验。后续给任务模板里加了一条“工具失败后第一步必须读取并引用错误信息”类似的问题就消失了。事后审计的核心价值是慢速纠偏。Agent 运行一小时留下两万行日志人不需要实时盯两万行只需要审计脚本先筛出异常区间再对异常区间做回放。这样既保住无人监督的自动化优势又给了系统一个随时可以追溯的全局视角。5. 组合使用、踩坑记录与落地顺序5.1 按任务风险等级选择技能组合十个技能不需要每次全上。技能越多延迟和成本越高过度约束反而容易让任务频繁失败。我的建议是按任务风险等级分类选择任务等级适用组合关键收益低风险批量任务01 目标契约 03 工具留痕 09 预算限制用最少配置挡住大多数幻觉中等风险分析任务01 03 04 置信度 07 证据链防止分析结论被错误引用高风险对外输出任务02 格式限定 06 中间产物 08 外部校验 10 审计结果必须经独立通道验证低风险任务做到“别让错误进入流程”就够了不需要对每一条输出做独立校验。但高风险任务里外部校验器和事后审计缺一不可。顺序上建议先补约束型再补感知型最后上校验型——先用最小代价让 Agent 撒不了谎再让它更早自我发现最后才是高端查账能力。5.2 五个真实场景里的高频坑第一个坑漏配完成状态字段。Agent 能在没有任何校验的情况下把“partial”写成“completed”因为我在输出契约里忘记约束 status 字段。后来在 JSON schema 里加枚举校验情况才稳定。第二个坑证据链可被伪造。前面提到的 URL 伪造问题。教训是证据链里的每一项都必须能在工具日志里查到对应记录不能信任 Agent 自述。第三个坑置信度自评变成仪式化输出。Agent 每一条都写“confidence: 0.95”失去了意义。解决办法是在提示词里增加一道反向问题“指出这个回答里最可能出错的三个点”把它作为置信度的隐藏约束效果比单纯让它打分好很多。第四个坑外部校验器过于苛刻导致正常任务反复重试。改成三级判定为“通过/复核/打回”之后系统吞吐恢复并且误杀率大幅降低。第五个坑长任务中 Agent “忘记”诚实约束。上下文越长模型越容易忽略早期设定的规则。我的做法是把约束摘要每隔5个步骤重新注入一次成本不高但能显著减少中后段生成的走形。5.3 从零开始怎么落地如果是对现有系统改造建议不要一次性全量接入按顺序来先在本地模拟任务里同时启用 01、03、09跑三天观察效果再逐步加入 04、07等体系稳定了再根据风险等级启用 02、06、08、10。每加一个技能都要先在小范围数据集上做对照组测试对比“接入前/接入后”的失败率和异常率确保每一条约束都在起作用。我个人的体会是这套体系的本质不是“让模型更诚实”而是“让你对模型的每一次输出都保留追查权限”。模型无法被真正地证明诚实但系统可以做到让不诚实不再有利可图。当撒谎成本高于完成任务成本时Agent 会自然选择承认失败或者认真重做——这是从工程侧逼出来的务实选择比任何道德劝说都可靠。最后再分享一个小技巧在系统提示词里明确给 Agent 留一条“认错通道”写明“如果你觉得这个任务可能完不成直接回答‘无法完成’不会被视为失败系统会安排其他路径处理”。我实测过加上这句话之后Agent 主动报告异常的比例提高了近3倍。它并不是真的在意惩罚而是需要被明确告知“认错是允许的选项”否则在概率生成的世界里它总会倾向于编一个最像成功的结果。
