三成任务是成功的，流程却是坏的

银行先把责任写清楚了

10 月 27 日，Bank of America 给客户群发了一封叫「Protecting your finances in the AI World」的邮件，提醒别把用户名和密码交给任何声称替你行事的 AI 工具或 agent。邮件里最硬的一句是：如果你还是把凭据交出去了，请记住，由此产生的活动由你负责。TechCrunch 拿到了这封邮件并找发言人确认了真实性，同一篇报道引用 Axios 10 月 22 日的消息，说银行业仍在应付未授权的 agent 访问客户资金这件事。

这段话值得逐字读。它没有否认 agent 会去动你的钱，也没承诺银行会替你分辨哪些操作是 agent 干的，只把责任边界划在用户这一侧。用户承担后果，前提是能知道 agent 做了什么、哪一步做错了。眼下这个前提不成立。

外面那层想问「是不是 agent」，银行要问的是「是不是我的 agent」

arXiv 2610.35288《Proof-of-Agentness》处理的正是服务端这一侧的困惑。CAPTCHA 用二十多年区分人和机器，现在网页服务开始把 agent 当合法用户接待，麻烦换了个方向：怎么把 agent 和会重放请求的普通脚本分开。作者给了两条路，主动发挑战题验回答，被动分析服务端看得见的信号。主动验证在 8 个语言模型加 2 个规则脚本、100 道挑战题上拿到 96.5% 的整体准确率，平均开销 1,647 个 token；被动分析做了一次 IRB 批准的用户研究，720 次网页访问、三个购物任务、12 名人类参与者对照 6 个 Bot 与 3 个 Agent 配置，用 40 个服务端可见特征，在留出任务上四个分类器平均 95.8%。

两个数字都很高，它们回答的问题和银行那封邮件不在一个层面。PoA 证明的是这个客户端背后有语言模型在推理，证明不了这个 agent 是账户主人授权过的那一个。脚本能伪装成 agent，被授权的 agent 和没被授权的 agent 在服务端眼里长得一样。身份这一层补上了人与机器之后的第三类，没补上是谁派来的。

里面那层更麻烦：三成成功任务通不过流程检查

arXiv 2610.32285《Trial by Trace》把评测对象从模型挪到了 harness，也就是模型与工具之间那层壳。作者按上下文、执行、治理、生命周期、可观测性、工具、验证七个组件组织可靠性，构造 95 个带可执行或状态型 ground truth 的专家级任务，在 4 个 harness、9 个模型上跑了 3,420 次执行，每个 harness 覆盖 855 个对齐的模型—任务单元。

任务成功率的排序和 harness 标准满足度的排序不是一回事：任务成功率最高的是 Claude Code 的 44.0%，最低的是 Codex 的 35.8%，跨度 8.2 个百分点；harness 标准满足度最高的是 OpenClaw 的 72.0%，最低的是 Codex 的 59.8%，跨度 12.2 个百分点。跑得最顺的那个，不是流程最规矩的那个。31.1% 的运行任务成功却至少违反了一条 harness 标准；两层都干净的比例，四个 harness 只在 2.8% 到 11.7% 之间。

把四个 harness 的成对读数摊开，错位比单一排序更清楚：

流程最规矩的 OpenClaw 在任务成功率上只排第三，比最会做题的 Claude Code 低 5.8 个百分点；反过来，Codex 在两条轴上都是最后一名。这说明两层之间不是「牺牲流程换成功率」的取舍曲线——存在两侧同时垫底的 harness，也存在流程领先而能力居中的 harness。把两层当成一条此消彼长的曲线来读，是这张表最容易犯的错，它实际上是两个维度上的四枚散点。

把这两条放进银行那封邮件的语境，缺口就清楚了。一家机构只看任务成功率，会漏掉三成在流程上已经跑坏的案例，偏偏是流程层面的违规决定了出事之后能不能查、由谁赔——有没有越权、有没有留下可审计的痕迹、错误状态有没有被正确呈现。

多出来的那一层，正是查不下去的原因

arXiv 2610.35767 给了同一件事的另一半证据。作者把微服务的根因分析当成考场：一边是三个不管模型看什么、怎么想的简单 harness（一次调用读完证据包、一个查原始遥测的 SQL agent、Codex），一边是五个已发表的 LLM RCA agent，它们用 SOP、固定阶段和角色 agent 把调查过程手工编排起来，还有一边是统计与因果方法。数据用 RCAtlas，八个公开数据集合成一种格式，从 542 个案例里筛出 90 个有效案例，覆盖 23 种场景，跑 6 个模型、3 档推理强度。

简单 harness 在三个中端模型上 PR@1 拿到 65%–77%，已发表的那些 agent 只有 16%–53%，非 LLM 方法 6%–39%，其中最好的 NSigma 是 38.9%。论文里的案例解释了差距从哪来：FoA 这套流程由程序按故障描述选 SOP，选中的通用 SOP 从头到尾不读日志，第一轮内经控制器四次调用（合计 11 次模型调用）就把 cart 定成根因；Codex 用七条命令先自己写代码比对故障前后的指标，看到 cart 错误率从 0.017 跳到 0.325，再读故障前后两分钟的日志，发现 inventory 服务到 01:59:22 还在响应、cart 从 01:59:23 开始被拒，最后报的是 inventory。决定答案的不是模型强弱，是程序有没有允许它去看那一行日志。

还有两句结论可以直接抄：换更强的模型主要提高可靠性（同一题多次跑的一致性）；换成多轮 harness 主要提高能力上限；加大推理强度对准确率只改几分，却能把耗时乘到七倍。在比最好的非 LLM 方法更准的运行里，成本或时间的帕累托前沿上每一条都是简单 harness。

该问的三个问题

今天能拿到的工具是分层的：服务端能验客户端是不是 agent（96.5%），基准能测 harness 的七个组件（59.8%–72.0%），运维侧能比出哪种编排更准（65%–77%）。缺的是一个把它们串起来的口径。一次 agent 事故之后，至少要能回答三个问题——发起方是谁，且这个答案不靠服务端猜；错在哪一层，且这个答案不必重放整个系统才拿得到；换个模型会不会变，且这个答案不受 harness 版本影响。第一个问题已有实验性答案，后两个刚有测量工具，还没有标准。银行邮件里那句由你负责，目前买不到这三个答案里的任何一个。

还有一层边界值得写下来。PoA 这两个准确率都是准入控制意义上的数字：它们决定服务端要不要把这个客户端当成 agent 对待。3.5% 的漏判在单机实验里是好分数，放在网页服务的量级上，是一批每天稳定混进来的假 agent。而授权判定对漏判的容忍度是零——放错一个未授权 agent 的代价比误拦一个真 agent 高得多。这两个场景要的不是同一个工作点，眼下只有一个。

参考来源

• Bank of America 邮件报道（TechCrunch，2026-10-27）：https://techcrunch.com/2026/10/27/bank-of-america-kindly-asks-that-you-dont-share-your-banking-password-with-your-ai-assistant/
• Proof-of-Agentness（arXiv:2610.35288）：https://arxiv.org/abs/2610.35288
• Trial by Trace（arXiv:2610.32285）：https://arxiv.org/abs/2610.32285
• Free to Look, Free to Reason（arXiv:2610.35767）：https://arxiv.org/abs/2610.35767

事实核查记录

本文四个一手来源已逐条回源核对：arXiv:2610.35288（Proof-of-Agentness: Towards Verifying Agents on the Web，v1 2026-10-26，第一作者 Xu Zuyao）、arXiv:2610.32285（Trial by Trace，v1 2026-10-23，第一作者 Cao Zhiyong）、arXiv:2610.35767（Free to Look, Free to Reason，v1 2026-10-26，第一作者 Bi Tingzhu）的标题、提交日与全部引用数字均与 abs 页及 HTML 全文一致。其中 96.5% / 1,647 token / 100 道挑战题 / 720 次访问 / 12 名参与者 / 40 个特征 / 95.8% 出自 2610.35288 引言逐字表述，44.0 / 35.8 / 72.0 / 59.8 / 31.1 / 2.8–11.7 / 3,420 / 855 出自 2610.32285 摘要与 Table 5.3，65%–77% / 16%–53% / 6%–39% / 七倍耗时出自 2610.35767 摘要。Bank of America 邮件一事为 TechCrunch 转述并获发言人确认，本文按转述处理，未独立取得邮件原件。