看起来完全符合要求：编码 Agent 的意图对齐缺口，和支付行业给出的凭证解法

我这一周在翻三条互不相干的信号流，最后发现它们撞在同一个词上：意图对齐。

第一条来自 arXiv 十月九日批次。一篇叫 AgentSWE 的论文开篇写了一句话，我读了两遍——"这份委托里藏着一个安静的假设：交付出来的那个 Agent，会忠实服务于它被造出来时要满足的需求，而不是仅仅看起来如此。目前没有任何基准测试检验这个假设。"第二条来自支付行业。十月十三日，美国运通在 TechCrunch 上公布了一套叫"意图智能框架"的东西，做法是在 Agent 真正下单之前，先把用户说的"买白色耐克九码"变成一张可校验的凭证。第三条来自 GitHub，十月上旬冒出来的十来个小项目，全都围着同一件事：怎么让人知道 Agent 究竟做了什么，哪些字段是它自己拿默认值填上的。

三条线索彼此不认识，却指向同一个缺口：我们有一整套办法验收"做完了没有"，却几乎没有办法验收"做的是不是你当初要的那个东西"。这篇文章我把这三条线的证据摊开，讲清楚意图对齐为什么在本周突然变成可测的对象，最后给一份我自己改过两版的落地清单。所有结论都标了口径，单源转述的地方我会明说未验证。

一、被跳过的那个假设：交付物"看起来对"就够了

委托和考试是两回事

先把概念钉住。过去三年编码 Agent 的评测，绝大多数是"考试"形态：给一份写清楚的规格说明或一个 GitHub issue，让模型交补丁，跑测试套件，绿了就算过。这套口径有个隐含前提——需求已经是完整的、无歧义的、被完整写下来的。

真实工作里不是这样。你不会给同事写一份二十页的规格，你会说"把那个接口改成支持分页，跟上周那个模块保持一致"。后半句是没写下来的约束，它活在上下文里。人能补全，Agent 不一定补得上，而它补不上时会用看起来合理的默认值把洞填平——交付物依然编译通过、依然跑得动、依然"符合"你字面写的那句话。

冻结提交与留出用例

AgentSWE 论文（arXiv 2610.13361）做的事，就是把上面这个假设从"默认成立"变成"被测对象"。它的二十五道题目，每道都被定义成一次委托而不是一场考试：构建方只能对着少量示例用例迭代，验收方则把冻结后的提交物放到一组留出用例上跑，这组用例是按"覆盖完整需求"设计的，而不是按"覆盖你被展示过的那几个例子"设计的。

我在读这份论文时最在意的是它的生命周期划分：从自然语言需求造出一个完整 Agent、编辑生产环境的 Agent 代码库、朝着一个可度量目标做优化，三个阶段各有各的忠实性风险。造的时候风险是需求丢失，改的时候风险是破坏既有契约，优化的时候风险是只优化那个被度量的指标。第三种风险我见过太多次了——指标上去了，实际体验下去了。

下面这张表是我按论文口径整理的对照，也是本文第一张可截图的锚点图：

右侧那一列的最后一行，就是本文要谈的意图对齐缺口：交付物可以在所有可见检查点上表现正常，同时在没被写下来的约束上偏得很远。

二、模糊意图的代价：需求澄清长期不在评测口径里

三百四十一个任务，测的是"会不会问"

意图对齐的第一道关口不在执行阶段，在动手之前——用户开口的时候需求往往是模糊的，真正的约束要靠交互问出来。可这块一直没人测。

ReqClarifyBench 论文（arXiv 2610.13022）把这个洞指出来了：现有基准要么从完整规格出发评实现，要么从欠规格请求出发评实现，两条路都跳过了"编码之前的需求澄清"这一步；此前关于澄清的研究又主要停留在函数级任务上。它给出的基准包含三百四十一个仓库级任务，专门测模型能不能通过交互把模糊意图转成清晰需求，以及这件事如何影响后续代码生成。

我特别认同论文里那句"误解会传播并导致昂贵的返工"。在仓库级场景里这不是修辞：一个模块对需求的理解偏了，偏的那部分会被下游当成既定事实继续写代码，等到联调时才发现，返工面积早就不是当初那个模块了。

澄清只有在能改变决策时才值钱

还有一层更细的口径。CLEAT 论文（arXiv 2610.12655）把这个问题正式命名为"通过澄清达成的交互式意图对齐"，然后补了一个容易被忽略的限制条件：澄清有用，前提是 Agent 能把回答转化成更好的决策。它为此提出"残差询问价值"来度量"问一句"相对"按当前策略直接做下去"能多拿到多少任务收益，并用同一起交互历史下的配对 rollout 来估计。

这个设计对我启发很大。很多产品把"Agent 主动提问"当成一个正向能力在堆，但提问本身是有成本的，而且成本随训练方式变化——同一个问题，在模型处理不完整信息的方式改变之后，价值可能变大也可能变小。不度量的澄清，只是把不确定性从结果端搬到了交互端。

三、支付行业先把意图做成了一张凭证

四步链路

学术在造尺子，支付行业已经在卖尺子了。十月十三日 TechCrunch 报道，美国运通发布了"意图智能框架"（Intent Intelligence Framework），这是它四月推出的 ACE 开发者工具包的一部分。我按报道口径把链路拆成四步：

报道里给的例子很能说明问题：用户让 Agent 买白色耐克九码，Agent 提交的是阿迪达斯的鞋——框架能在这一步把交易拦下来。这个例子的价值不在"拦错品牌"，而在于它证明了约束是可以被带进执行环节并在那里被检查的，而不是事后在账单上被发现。

需要说明的是，报道里的两个调研数字（百分之六十六的美国受访者可能用 Agent 比价、百分之六十一可能用它做推荐）来自美国运通自己的 Trendex 报告，经 TechCrunch 转述，我未核到原始问卷，只作定性引用。公司同时自述"尚未看到因代理商务引发的争议增加"，这条属于厂商自述口径，不作为结论。

与事后审计的分界

这里必须划一条线，否则容易和最近另一波信号混为一谈。近期行业讨论很多的是审计轨迹与留痕——Agent 做了什么动作、花了多少钱、归属到哪个身份，事后可查。那套东西解决的是"追责"，是事后的。

意图对齐要解决的不是追责，是事前的匹配：约束能不能在执行之前被固化成一个可携带、可校验的对象，并且在执行链路的每一环都被拿出来比对一次。留痕告诉你它买了阿迪达斯，意图凭证让它在买阿迪达斯的那一刻就付不了款。这也是我判断意图对齐价值时会优先看拦截位置，而不是看报表做得有多细的原因。这是两个不同的位置，成本结构也完全不同——留痕是记录成本，意图凭证是协议与接入成本。

VEPA 论文（arXiv 2610.12813）从学术侧给了同一个位置的论证：运行时护栏应当在潜在的不可逆动作被执行之前做出可检查、可复现、确定性的放行或拒绝决策。它的贡献在于处理"部署前需求永远不完整"这个现实——纯 LLM 推理执行策略会导致判决不一致、策略解释含糊，而纯形式化护栏又无法适应新出现的风险。顺带说明，论文的"确定性"主张是作者自述的设计目标，我未实测其运行时开销，这里只作存在性引用。

四、开源侧在补的三块短板：把意图对齐落进工程

把拦截放到编辑之前

先说最贴近日常的一块。十月的 GitHub 上出现了一批把检查前置到写入动作之前的插件，比如 susanoo（Claude Code 工作流护栏）的做法是按 FAST、STANDARD、DEEP 三档给编码任务分流，在编辑动作通过校验之前直接拦住。这类项目的星数普遍不高（本文引用时均为十月十四日快照），样本风险不小，但它们共有的设计取向值得记下来：拦截点越靠近写入，返工面积越小。

让"它到底做了什么"可读

第二块是把 Agent 的实际行为变成人能扫的东西。TRACES.md 的定位很直白——AGENTS.md 是写给 Agent 看的规范，它要做的是记录 Agent 实际干了什么；whiteboard-defense 关心的是另一个更隐蔽的点：你建的这个东西里，哪些地方是 Agent 直接用了默认值而不是按你的要求来的；gravitas 走的是第三路，让 Agent 自己先声明"这个答案依赖什么"，把隐含假设显式化。

三个项目角度不同，落点是同一个：把未声明的东西变成已声明的东西。这恰好就是意图对齐在工程侧最朴素的形态。

给验收造一个可跑的环境

第三块是验收环境本身。fde-gym 把自己定位成"LLM 时代的在线判题系统"，每个用例都是一次真实客户交付；dudes 让守护进程自己验证目标是否达成；cromford 的目标是工单进、经过评审与合并、生产级校验过的变更出。它们的成熟度参差，我核对过仓库描述，但都没有实测，只作存在性证据。

五、把约束前置：一份可落地的意图对齐清单

先冻结意图，再派发任务

下面是我在自己项目里改过两版的结构化意图文件。要点是派发任务之前冻结，运行过程中不允许修改，这样验收才有稳定的参照物：

{
  "intent_id": "INT-2026-10-14-001",
  "task": "把订单接口改为支持分页",
  "hard_constraints": [
    "分页参数必须与用户模块上周的实现保持一致",
    "不得修改对外响应体的既有字段名",
    "单页上限不超过 200 条"
  ],
  "acceptance": {
    "illustrative_cases": ["case_basic_page1", "case_empty_result"],
    "held_out_cases": ["case_last_page_boundary", "case_concurrent_insert"],
    "frozen_at": "2026-10-14T11:30:00+08:00"
  },
  "disallowed_defaults": ["page_size", "sort_key", "null_ordering"]
}
​

最后那个字段是我在吃过亏之后加的。默认值字段清单的作用，是把"Agent 自己填了什么"变成可枚举的检查项，而不是靠人眼扫 diff。

跑一次留出用例的比对

冻结之后，验收阶段要做的是拿留出用例打冻结提交物，并逐条比对待检查项是否落进实现里：

# check_intent.py —— 冻结意图之后跑留出用例，并逐项比对默认值字段是否显式声明
import json, subprocess, sys

spec = json.load(open("intent.json"))
fails = []

for case in spec["acceptance"]["held_out_cases"]:
    rc = subprocess.call(["pytest", f"tests/{case}.py", "-q"])
    if rc != 0:
        fails.append(f"留出用例未通过: {case}")

src = open("src/order_api.py", encoding="utf-8").read()
for field in spec["disallowed_defaults"]:
    if f"{field}=" not in src and f'"{field}"' not in src:
        fails.append(f"未显式声明默认值字段: {field}")

if fails:
    print("验收未通过:")
    print("\n".join(fails))
    sys.exit(1)
print("意图对齐检查通过")
​

这段脚本的逻辑很粗，它只能检查"字段有没有被显式写出来"，查不出写出来的值对不对。我保留它的原因是它够便宜——一个粗糙但每天真跑的检查，价值高于一个精细但没人跑的检查。这是我在权衡之后的选择，不是通用结论。

六、意图对齐这套口径的代价与边界

写到这里必须说清楚代价，否则就成了推销。

第一，意图凭证的接入成本是真实存在的。支付行业有统一的清算网络，所以能把凭证塞进既有链路；软件工程没有这种统一层，你要么等工具链自己长出来，要么在每个项目里手写一遍本文第五节那样的东西。对十人以下团队，这笔成本可能不划算。

第二，冻结意图会牺牲灵活性。真实开发里需求本来就会变，硬冻一份意图文件，要么频繁解冻重签，要么团队开始绕开它。我的做法是把硬约束和软偏好分开，只冻结前者，这个分法不一定适合你的场景。

第三，本文引用的 arXiv 论文都是十月八日至九日提交的预印本，未经同行评审，结论可能修订；GitHub 项目的星数与描述均为十月十四日快照，早期项目存活率不高，不宜作为选型依据。第四，Amex 框架的细节来自 TechCrunch 的一手报道，但其中引用的调研数字与"未见争议增加"均属厂商自述，我未核到独立来源，按单源口径处理。

还有一条更根本的局限：意图对齐的尺子只覆盖"交付物是否服务原意"这一层，它不解决"原意本身是否合理"，也不解决需求在冻结之后发生合理演变的情况。一个忠实实现了错误需求的 Agent，在这套尺子下依然会拿高分。

常见问题

意图对齐和提示词工程有什么区别？

提示词工程优化的是"怎么说能让模型做对"，意图对齐关心的是"做出来的东西是否服务于最初那个需求"，并且要求约束在执行前被固化成可校验对象。前者是表达技巧，后者是验收机制，两者的检查点位置不同。

委托式评测和考试式评测的关键差异在哪？

关键在验收样本。考试式用同一批可见测试判分，委托式把提交物冻结后放到留出用例上跑，且留出用例是按覆盖完整需求设计的。这让"只在示例用例上表现好"这条捷径失效。

小团队值得做意图冻结吗？

我的判断是要看任务是否被反复执行。一次性脚本不值得，反复迭代的核心模块值得。可以先只冻结硬约束那一栏，把软偏好留给口头沟通，成本大约在每个任务十分钟以内。

默认值字段清单要列多细？

列出那些"填错了会静默出错"的字段，比如分页大小、排序键、空值排序、超时时间、重试次数。那些填错了会立刻报错的字段不必列——它们自己会暴露。

意图凭证和审计轨迹是不是重复建设？

不重复。审计轨迹是事后的，解决追责与复盘；意图凭证是事前的，解决执行时的约束校验。前者记录成本为主，后者是协议与接入成本。两者可以共存，也可以只做前者。

Agent 主动提问越多越好吗？

不一定。CLEAT 论文的口径是澄清的价值取决于它能否转化为更好的决策，用"残差询问价值"度量问一句相对直接做下去的收益。不度量的提问只是把不确定性从结果端搬到交互端。

这些论文和项目现在能直接用到生产吗？

论文的预印本状态与项目的早期状态都需要留意。我会把它们当成设计思路的来源，而不是可直接依赖的组件——先按本文第五节那样做一版最小的手工实现，看着效果再决定是否引入外部工具。

参考与口径说明

本文引用的 arXiv 论文提交于二〇二六年十月八日至九日，均为预印本；GitHub 项目星数与描述为十月十四日快照；美国运通框架内容来自 TechCrunch 二〇二六年十月十三日的一手报道，其中调研数字与公司自述按单源口径处理。本文未做性能实测，所有性能与设计目标的描述均标注为作者自述或原文主张，供参考。