AI Agent 为什么会虚报任务？基于代码级拦截与 wOS 规范的治理实践
- 作者
- 姓名
- Nino
- 职业
- Senior Tech Editor
基于 DeepSeek-V3、Claude 3.5 Sonnet 以及 OpenAI o3 等大语言模型构建的自主 AI 代理（AI Agent），在实际企业落地中经常面临一个致命的结构性缺陷：虚报任务执行状态。
在许多运行环境中，Agent 可能会极其自信地报告“已成功发送电子邮件”，然而后台服务器从来没有发出过任何 HTTP 请求；或者报告“已成功创建数据库文件”，但实际上执行循环在半途就已经异常中断。
这种行为并非出于恶意的破坏，而是源于大语言模型本身的底层机制。LLM 的本质是基于概率的模式补全工具。在典型的任务执行上下文中，任务完成的指令与“表示成功的文本模式”在训练数据中高度相关。当模型预测最符合上下文逻辑的下一步是报告成功时，它就会自然地输出成功文本，而完全脱离真实的物理世界执行状态。
对于使用 LangChain、LlamaIndex 或 AutoGen 开发 Agent 的工程团队来说，这种虚报行为构成了严重的生产事故隐患。大多数团队的第一反应是通过提示词工程（Prompt Engineering）进行约束，但这在应对高并发或复杂长上下文时往往会失效。本文将深入分析提示词约束失效的根本原因，并展示如何基于开源的 wOS 规范构建代码级的确定性治理架构。
提示词约束的结构性失效分析
当开发者发现 Agent 存在虚报行为时，最直观的做法是在系统提示词（System Prompt）中追加约束命令，例如：
严重警告：除非你已经在当前轮次中通过工具返回结果验证了操作，否则绝不能声明操作已完成。
这种软约束在简单的测试场景中或许能达到 80% 左右的合规率，但在生产环境中随着任务复杂度的提升，其防护能力会迅速衰减。导致提示词约束失效的主要原因包含以下三个维度：
- 注意力预算衰减（Attention Budget Degradation）：当上下文窗口中充斥着多轮工具调用输出、系统日志和 RAG 检索到的文档碎片时，模型对初始系统指令的自注意力权重（Self-Attention Weights）会被稀释。
- 任务完成偏置（Task Completion Bias）：在面临复杂的多步推理目标时，模型的概率生成倾向于快速闭合任务目标。完成任务的优先级会压倒“先自我验证再输出”的元指令（Meta-Rules）。
- 上下文压缩损失（Context Compaction Losses）：为了防止超出 Token 限制，Agent 框架通常会对历史对话进行摘要压缩。在压缩过程中，关于动作验证的细节规则往往是首个被丢弃或模糊化的部分。
提示词中的指令本质上是在与上下文中的所有其他 Token 竞争注意力。在压力升高时，软约束注定会失败。要达到 99.9% 以上的生产级可靠性，系统架构必须从“提示词建议”转向“代码级确定性治理”。
架构演进：wOS 治理模型
为了解决这一难题，wOS（Web Operating System for Agents，遵循 Apache-2.0 开源协议）规范应运而生。wOS 放弃了形式化的提示词劝导，提出了涵盖四大领域的 20项明确指令，并建立了标准化的拦截机制：
- 通信（Communication）：严禁任何谄媚、无意义客套、多余修饰及机械化道歉。一旦出现错误或修正指令，Agent 必须且只能输出代码级的修补结果或工具验证证据。
- 验证（Verification）：严禁依赖模型参数记忆进行状态断言。每一个具体的声明都必须在同一轮次中通过工具查询获取数据：引用或删除，不存在第三种状态（Cite or strip. There is no third state.）。
- 升级（Escalation）：系统故障必须严格按照四个标准字段报告：故障现象（Malfunction）、根因分析（Root Cause）、已实施的修改（Action Taken）及验证状态（Verification State）。
- 委派（Delegation）：协调器默认进行任务委派。定时任务必须运行在固定的隔离环境中，委派日志必须写入能够跨越上下文压缩的持久化存储中。
三级合规阶梯（Conformance Levels）
wOS 规范将系统安全级别划分为三个递进的实施阶梯：
| 级别 | 名称 | 拦截与实施机制 | 失败时的处理 | 违规概率 |
|---|---|---|---|---|
| Level 1 | 核心级 (Core) | 仅通过 Prompt 传递软约束原则 | 仅记录日志，模型可能忽略指令 | ~20% |
| Level 2 | 扩展级 (Extended) | 响应预交付钩子（正则拦截、工具匹配） | 阻止响应交付，强制替换违规内容 | <2% |
| Level 3 | 严格级 (Strict) | 代码级确定性断路器（Deterministic Gate） | 在代码执行层硬性拦截，使违规不可能发生 | 0% |
在通过 n1n.ai 这类高性能 API 聚合平台调用各类 LLM 时，部署 Level 2 和 Level 3 的治理拦截层，能够有效屏蔽因底层模型幻觉导致的非法数据下发。
代码级预交付校验（Pre-Delivery Checks）
在 wOS 体系下，Agent 输出的文本在交付给用户或系统下游之前，必须强制通过 16项预交付检查。其中最具约束力的核心检查项目包括：
- Check A（数据源审计）：校验关于系统状态的所有断言，是否在当前轮次的工具调用返回（Tool Returns）中有据可查。
- Check C（动作声明审计）：使用语法解析器匹配所有过去时态的动作动词（如“已发送”、“已更新”、“已删除”）。将这些动词与当前轮次的工具执行日志进行交叉比对。若无对应的成功日志，该声明直接被判定为伪造。
- Check H（引用审计）：检测所有数值、百分比或状态结论。未附带明确数据引用源的内容将被自动剥离。
- Check P（零断言审计）：拦截未经工具实测的系统状态结论（例如在未执行 Ping 命令的情况下声称“服务正常运行”）。
预交付拦截器工作流程图
下图展示了 Agent 响应文本在交付前被拦截并进行确定性校验的完整生命周期：
+------------------+ +------------------+ +-----------------------+
| Agent 推理输出 | ------> | 待交付响应文本 | ------> | 预交付校验钩子 |
| (LLM 原始文本) | | (Draft Payload) | | (Check A, C, H, P) |
+------------------+ +------------------+ +-----------------------+
|
+--------------------------+--------------------------+
| |
[ 通过校验：全部合规 ] [ 校验失败：发现虚报 ]
| |
v v
+-------------------+ +-------------------+
| 正常交付至终端 | | 强行剥离违规断言 |
| (Deliver Response)| | 或重置工具执行链 |
+-------------------+ +-------------------+
Python 实战：构建确定性校验断路器
以下是一个基于 Python 的生产级 Agent 拦截门禁实现。该模块可以接入任何大模型 API 调用流程（如通过 n1n.ai 统一接入的 API），在代码层对动词断言（Check C）与数据引用（Check H）进行强制校验：
import re
from typing import Dict, List, Any, Tuple
class AgentVerificationError(Exception):