The Human Is Part of the Agent

过去几年，我们已经习惯用越来越难的 benchmark 去跟上模型能力增长的速度。MMLU 不够难了，就有 GPQA；竞赛数学逐渐接近饱和，就去测更难的 AIME、IMO，再设计 Humanity’s Last Exam；coding benchmark 也从 HumanEval 一路走向 SWE-bench、Terminal-Bench，以及时间跨度更长的真实软件工程任务。这个追赶本身越来越吃力。Stanford 2026 AI Index 提到，一些原本指望能用数年的 benchmark，几个月后就开始接近 saturation；Humanity’s Last Exam 这样专门面向 frontier model 设计、刻意难倒 human expert 的测试，在一年内最高成绩又增长了约 30 个百分点。我们不断把尺子拉长，因为旧的尺子过时得越来越快 (Stanford Institute for Human-Centered Artificial Intelligence, 2026)。这件事有它的道理：benchmark 用一组可以反复比较、客观打分的问题，来近似衡量一个很难直接定义的东西，也就是模型到底有多 smart。

随着 benchmark 继续变难，模型能力开始碰到更直观的人类参照：竞赛金牌、领域专家，以及真正尚未解决的研究问题。2025 年 7 月，OpenAI 的 general-purpose reasoning model 在 IMO 上得到 35/42，达到金牌水平。到 2026 年 2 月，First Proof 的十道专业数学问题里，至少五个 proof attempts 在专家反馈后被认为很可能正确，而其中一些题目在出题者自己找到解法之前，已经开放多年 (OpenAI, 2026)。此后这条曲线继续往上，2026 年 8 月公布的十项数学与理论计算机科学结果，每一项都解决或实质推进了一个长期未解的开放问题 (OpenAI, 2026)。这些结果各自带着不同的条件，包括多次尝试、人工挑选和专家反馈。把它们一律读成模型独立完成并不准确，不过方向是清楚的。数学还算一个相对“干净”的例子，换到 cybersecurity，同一条能力曲线的现实后果就直接得多。Mythos Preview 能够在 major operating systems 和 browsers 上发现并利用 zero-day vulnerabilities，其中大量此前未知的漏洞是在初始 prompt 之后自主发现的 (Anthropic, 2026)；这种能力在攻防两侧并不对称，于是有了 Project Glasswing 这类让防守方先拿到它的安排 (Anthropic, 2026)。

如果只沿着这条线看下去，我们很容易产生一种直觉：agent 好像已经非常、非常聪明了。它可以解决绝大多数人没有能力解决的数学问题，走到只有少数领域专家才进得去的研究前沿，也可以在某些高度专业的任务上直接超过人类专家。对于很多 frontier tasks，普通人的位置甚至已经从“我和模型谁做得更好”变成了“我可能根本看不懂它在做什么”。如果 smartness 指的是解决越来越困难问题的能力，那么过去几年我们确实一直在目睹一种相当直接的 smartness maxing，而且目前很难看到它停下来的迹象。可一旦进入真实使用，这种 smartness 并不会完整地反映到使用体验里。你每天用 Claude Code、Codex，或者任何一个足够强的 agent，一段时间以后很可能会形成一种非常微妙的判断：这个模型当然很强，有时候强得离谱，但它也会在一些看起来远没有 IMO、research mathematics 或 vulnerability research 困难的事情上，让你莫名其妙地觉得它“很蠢”。更微妙的是，我们经常很难立刻说清楚这种蠢到底是什么。任务可能完成了，代码可能能跑，回答甚至可能挑不出一个明确的 factual error，可你还是会觉得哪里不太对；换一个模型、换一种交互方式，甚至只是多来回几轮，这种“好不好用”的感觉又会明显变化。它不像 benchmark accuracy 那样容易落成一个数字，但实际使用过 agent 的人往往很快就能感觉到它。

麻烦在于，“smart”这一个词正在同时评价好几个不同的系统属性。Benchmark 主要回答其中一个：给定一个已经写好的问题，solver 能做多难。这是 problem-solving capability。真实使用还会暴露另外四个问题：Agent 能不能在长 trajectory 中稳定使用自己的能力，这是 agentic control；系统能不能在 interaction 中持续形成和修正任务，这是 task formation；结果有没有足够独立的 evidence 支撑采用，这是 assurance；某项行动由谁授权、出了问题如何归责，这是 governance。这五个问题会在同一次失败里重叠，变化速度也不一样（图 1）。它们被一起压进“聪不聪明”这个判断里，于是 benchmark score 一路上涨，日常体验却没有跟着一起改善。

它到底蠢在哪里

这种“蠢”其实可以说得相当具体。真实使用中，用户很少抱怨“这个模型的推理能力不够”，更常见的是“你明明知道，怎么又违反了”、“你什么都没确认就开始改”、“刚才我改了这个，你没看到”、“你说 done，但根本没验证”，或者“你自己改乱的，撤不回去”。这些话都默认模型有能力做对，被抱怨的是它没能沿着一条正在展开的 trajectory 管住自己已有的能力。把这些抱怨换成更接近系统的说法排一遍，可以看出它们并不落在同一层，也不会被同一种办法修掉：

前八行主要属于 agentic control，要靠训练和 harness 一起解决：约束和计划可能没有留在后面几十步的 context 里，也可能留住了却没有被守住，多数情况两边都有份，所以我不打算逐条判定该改哪一边。第九行已经进入 assurance。“你自己写的测试自己跑过了”没有现成文献直接支撑，是我自己的判断：如果 Agent 对需求的理解已经偏了，它写出的测试可能和实现一起偏，跑绿也就不构成独立证据。接下来两行属于 task formation，分别对应信息尚未取得，以及判断尚未形成。最后一行属于 governance，由使用 Agent 的团队决定哪类动作需要谁批准。这些功能会彼此重叠；表格标出的是每种抱怨首先暴露的问题。

接下来的证据基本都来自 coding agent。软件工程同时提供 executable tests、git、diff、CI、sandbox 和 rollback，failure 因此能被看见、被定位、被计数，这在 agent 任务里是难得的条件；代价是它也最不像 legal、medical、finance 或组织决策那类场景：“做对了没有”本身就很模糊，撤回也困难。下面的材料用于识别机制，不能直接当作各行各业的普遍比例。

这类抱怨的规模不小。对 1,639 个 repositories、20,574 条 coding-agent sessions 的观察性分析归纳出七种反复出现的 misalignment 模式，从 project 理解、intent 解读、规则遵守，一直到 action boundary、代码执行和进度汇报；其中 90.5% 的 episode 带来的成本都落在 effort 或 trust 上。由于大部分 session 没有在可见对话中确认最终结果，只有 9.33% 的 episode 能观察到 resolution，共 1,504 个；在这部分案例里，91.49% 需要用户明确纠正 (Tang et al., 2026)。同一份数据里还有一个构成上的变化：随着总体问题率下降，constraint violation 和不准确的自我汇报在剩余问题中的占比反而上升。观察性数据不足以说明是模型变强导致了这种转移，不过至少剩下来的这批问题，已经不太像“模型不会做”。

其中最容易复现的是两种形态。一种是该停手的时候没停手：FixedBench 的 200 个任务全部来自已经被修复的 issue，正确的做法是识别出这一点、然后不动代码，五个近期模型在四种 harness 上仍有 35% 到 65% 的情况提出了不必要的修改；要求它们先复现问题再打补丁能缓解一部分，代价是对那些只被部分修复的 issue 又开始该改不改 (Gloaguen et al., 2026)。至于它们为什么这么爱动手，这份 benchmark 本身没有回答，一个说得通的猜测是在它见过的绝大多数训练和评测信号里，“什么都不做”很少被算成一次成功。另一种是不知道世界已经变了：真实开发中用户会在 Agent 工作时读代码、改代码甚至撤销改动，Agent 看到的 repository state 并不只由自己的 action 产生，而在 SWE-bench Verified 上注入与任务相关、会改变完成路径的 simulated user edits 之后，平均 resolve rate 下降了 7.7 个百分点，轨迹分析显示 Agent 有时保留与用户修改冲突的代码，有时直接覆盖用户的改动，却没有重新检查 workspace，也没有跑针对性的测试 (Tan et al., 2026)。这类行为在标准 SWE-bench 里根本不会露面：环境里没有别人动手，也就没有需要重新对齐的状态。

而且只看最终结果，很难知道 Agent 是从哪一步开始偏的。对 115 条失败 trajectory 的人工标注给出了九类 failure，包括 plan adherence failure、invalid invocation、对 tool output 的误读、intent-plan misalignment 和 under-specified user intent，并尝试定位一条 trajectory 里第一个不可恢复的 critical step；这些 trajectory 来自 structured API workflow、incident management 和开放式 web/file 任务三个不同 domain (Barke et al., 2026)，说明同样的失败形态会跟着长 trajectory 一起出现，和任务内容是不是写代码关系不大。

这些失败已经很难再叫作“模型不会做”。多数时候它完全有能力完成局部任务，出问题的是几十步甚至几百步之后，它还能不能守住一开始说过的约束、维护最新的状态、在证据不足时先去拿证据、控制改动范围、知道什么时候该停、验证结果、如实汇报，以及在做错之后退回去。姑且把这部分叫作 agentic control，它和“能解多难的题”是两种不同的东西，而今天不少“你明明会，为什么还这样做”的质问，指的都是它。我倾向于认为这一层会被显著压低，因为其中每一项都有明确的工程抓手：constraint 的持久化、workspace state 的刷新、行动前的证据门槛、自动验证、checkpoint 与回滚，都可以从 harness、context 管理和 training incentive 入手。这算一个判断，还没有得到长期数据验证。FixedBench 展示的 under-action trade-off 也说明，修掉一种 control failure 可能带来另一种失败形态。更稳妥的预期是，今天这批“蠢感”中会有相当一部分随着系统改进而减少。接下来仍有一件事需要解释：如果 control failure 在真实使用中这么普遍，为什么它们在 benchmark 上几乎看不见？

Benchmark 替 Agent 固定了什么

Benchmark 看不见这些问题，很大程度上是设计使然，而且是正确的设计。SWE-bench 给定一个真实 GitHub repository、issue 描述和代码环境，让 Agent 修改代码，再由测试判断 patch 是否有效 (Jimenez et al., 2023)；SWE-Lancer 把同一个思路推到 1,400 多个来自真实 freelance work 的任务上，对应到约一百万美元的实际报酬 (Miserendino et al., 2025)。它们要回答的是一个 solver 问题：给定一个已经写好的任务和一个固定的成功标准，模型能做多难。为了让这个测量有意义，task、environment 和 verifier 必须固定下来。真实 delegation 中，这些条件需要由更大的系统持续提供和维护，具体工作可能分散在 Agent、harness、用户、CI 或组织流程中的不同位置。任务会被重新解释，别人会同时修改环境，success criterion 可能依赖用户尚未说出的偏好，验证也可能来自独立 checker 或 reviewer。Benchmark 在一次运行里替整个系统固定了这些变量，所以一个 component capability score 不足以预测同一个模型在真实委托里的表现。

把这些条件准备齐，需要一批人先完成大量工作，而且不便宜。DeepSWE 从头设计了 113 个 long-horizon software engineering tasks，覆盖 91 个真实 repositories，并为每个 task 手写 behavior-oriented verifier：这种 verifier 接受研究者从未见过、但确实满足 task 要求的 implementation，以 requested functionality 为判断依据；独立 LLM judge 对它们的 disagreement 只有 1.4%，对从 SWE-Bench Pro 继承下来的 tests 则达到 32.4% (Huang et al., 2026)。这里最稀缺的人类判断已经不在“你来把这 113 道题先做一遍”，而在更前面：哪些 task 值得拿来测，真实 environment 该保留哪些复杂性，一个完全不同的解法要满足什么条件才算成功。

这种位置前移，在现在的 evaluation 出现之前就已经开始了。早期 RLHF 里，labeler 按真实用户提交的 prompt 写出理想回答做 supervised fine-tuning，再给模型生成的多个 candidate 排序，用这些 ranking 训练 reward model，最后拿去继续优化 policy (Ouyang et al., 2022)，力气几乎全花在一个个 sample 上。这类工作后来大面积被模型接手：2023 年 ChatGPT 在一组文本 annotation 任务的五类中有四类超过 crowdworkers，inter-coder agreement 更高，单条成本约为 MTurk 的二十分之一 (Gilardi et al., 2023)；GPT-4 当 judge 时与 human preference 的 agreement 超过 80%，代价是 position bias、verbosity bias 这类系统性偏差 (Zheng et al., 2023)。被接手的大多是绑在单个 sample 上的 bounded judgment，更多人类投入因此可以转向覆盖范围更大的判断。Constitutional AI 把这一步做得很直白：人写下的是一组 principles，模型照着 constitution 自己 critique 一个回答哪里违反了原则、再做 revision，之后还能用同一套原则比较不同回答、生成 preference data 继续做 reinforcement learning (Bai & others, 2022)。人不用再逐条判断某个回答好不好，一条 principle 就能约束模型以后遇到的一整类情况。

把这些来自不同研究脉络的变化放在一起看，可以抽出一个共同维度：一次人类判断能够约束多大范围的 future behavior。下文把这个维度叫作 supervision leverage（图 2）：

越靠左，人越像在替模型生产答案；越靠右，人越像在划定模型该在哪个问题空间里工作，以及什么样的结果在这个空间里才算成功。一个 label 只影响一个 sample，一条 principle 约束一类 output，一个 verifier 规定一整组可接受的解法，task 和 environment 则决定整个问题空间的边界。这条线描述的是 judgment coverage，无法单独回答总 human-hours 是增加还是减少。它能支持的结论是，一部分 sample-level labor 正在下降，同时一些判断移动到 principle、verifier、task design 和 environment design。新的位置经常落在计分范围之外：SWE-bench 上的一个分数不会计入设计这套 environment 的人花掉的判断，就像一次顺利的委托不会计入用户为它补的那些 context。这种位移后面还会出现几次，一次比一次难看见。

这一路变化背后还有一个前提：task、rubric 和 objective 可以在 Agent 动手之前就写完整。Benchmark 把这个前提直接做成了设计条件，也正因如此它才能稳定地测出 solver capability。真实的 user-facing agent 没有这么好的条件。

我们可能一直在测一个不存在的用户

这类 evaluation 里其实站着一个非常配合的用户：他能一次把 requirement 写完整，提供相关 context，定好 success criterion，并且在整个任务过程中判断不变。他只在开头说一次话，之后由 tests、verifier 或 judge 判定这次做得对不对。要隔离 problem-solving capability 就需要这样一个用户，真实工作里却很少遇到他。

一个工程师说“这个 feature 现在太复杂了，帮我简化一下”，他自己也说不出简化到什么程度算合适；等看见第一版改法，他才发现真正在意的是新同事能读懂这段代码，而某些看起来冗余的分支恰好是几次线上事故留下来的。这句话没写错，它只是要等到有具体的东西可以对照，才会变得足够具体。对 11,579 条 AI-assisted IDE sessions 的行为分析看到的也是这个模式：开发者很少一次说完，更多是靠一连串短 prompt 逐步收紧目标，并在看到中间结果之后调整方向 (Tang et al., 2026)。

这里其实混着三件不同的事。有时候用户从一开始就知道自己在意什么，只是 Agent 不知道，需要的是去问，这是 reveal。有时候用户只有一个大致方向，要看到具体实现和 trade-off 才能把要求说准，这时 Agent 得先拿出一个足够具体、值得被评价的东西，这是 refine。还有一种是 Agent 的动作改变了用户对问题的理解，让他形成了 interaction 开始时并不存在的判断，产物本身成了帮他想清楚问题的手段，这是 reconstruct。三种都会让初始 prompt 显得不完整，但它们要求 Agent 做的事情并不一样：第一种要它会问，第二种要它先动手做出可评价的东西，第三种则意味着这次委托的目标有一部分是在委托过程中才产生的。

更强的模型会把前两种的成本压低不少，例如从 context 里推断更多 latent preference，把稳定偏好记进 memory，并判断哪些不确定真的会影响下一步动作。Ambig-SWE 就在直接测这件事：它把 SWE-Bench Verified 改成刻意 underspecified 的版本，要求 Agent 先意识到 instruction 缺了关键信息，再用 targeted clarification 把它拿到手，而模型并不总能判断出什么时候该问；在这套设置里允许 interaction，结果相对 non-interactive setting 最高提升了 74% (Vijayvargiya et al., 2026)。这是一个能靠训练、评测和工程手段补上的缺口。第三种无法被 ex ante preference inference 完全消除：如果一个判断要等到具体后果摆在面前才形成，Agent 提前询问时还拿不到答案。Cheap prototype、reversible action 和快速展示 alternatives 可以降低形成判断的成本，却仍然绕不开 interaction 本身。所以“先建一个 user profile 再执行”不够用，偏好会在行动前后继续变化，personalization 更像一个需要反复更新的 loop (Liang et al., 2026)；把不同用户的 utility 压成一个 population-level reward，得到的目标也可能没有很好地代表任何一个人 (Poddar et al., 2024)。

Evaluation 也在跟着改。SWE-Together 从 11,260 条真实 user-agent coding sessions 里筛出 109 个 repository-level task，用 reactive user simulator 保留原始用户的 intent 和 intervention 顺序，同时记录最终 repository correctness 和过程中需要多少轮 corrective feedback (Wu et al., 2026)，测量对象因此从“能不能独立解出这道题”扩到“在用户的澄清、约束和纠正下能不能把一条 trajectory 推下去”。可交互的 evaluation 当然只能靠 user model 来做，真正麻烦的是这个 model 有多像人会直接改变分数的含义：用 31 个 user simulator 和 451 名真实参与者、165 个任务做对照之后发现，LLM simulator 过度配合、风格单一，缺少真实用户会有的 frustration 和 ambiguity，给出的反馈也一致地更正面，构成一种会抬高 agent 表现的 easy mode，而更强的模型并不自动更忠实 (Zhou et al., 2026)。把用户放进 evaluation 之后，“用户是什么样的”本身也成了一个需要校准的实验参数，而这件事在 solver benchmark 里根本不存在。

所以这里缺的东西和 agentic control 属于不同问题。就算 constraint following、state tracking 和 verification 全都做到位，一个只在开头说话的用户仍然交代不完整任务：他手里有 Agent 看不到的 state，也会在整条 trajectory 上继续提供决定“现在这个任务到底是什么”的信息。Interaction 既承担纠错，也参与目标形成。只看最终 pass rate 会漏掉维持这段 interaction 所需的人类投入，这也就引出了委托本身的成本问题。

委托的成本花在哪里

如果 AI 能让写代码这一步快一半，放进真实工程里，工程师的总时间也该跟着明显下降。数据没有这么整齐，而落差恰好出现在 generation 之外。生成这一步的收益是真的：在一个边界清晰、可以自动跑测试判对错的 programming task 上，用 GitHub Copilot 的 treatment group 平均比 control group 快 55.8% (Peng et al., 2023)。这个实验也顺带说明了它的适用范围：task、context 和 success criterion 都被固定住的时候，生成速度的提升最容易被测出来。

换到 developer 自己熟悉的 mature repository 上，测出来的结果反了过来。METR 在 2025 年让 16 名 experienced open-source developers 在自己的 repositories 上处理 246 个真实 issue，用上当时的 AI tools 之后，完成时间平均增加了约 19%；他们事前预期会快 24%，做完之后仍然相信自己快了约 20% (METR, 2025)。三个数字之间的距离本身也是一个结果：在这个实验里，参与者对自己花了多少时间的感觉，和实际测到的并不一致。METR 后来的实验在 raw estimates 中出现了 speedup，但置信区间跨过零，参与者和任务的选择也发生了明显偏移；METR 因此把这批数据称为对当前 productivity effect 不可靠的信号，只把它视为工具可能已经比 2025 年更有帮助的弱证据 (METR, 2026)。这两组结果都不足以单独确定 AI 对开发效率的总体方向，它们更适合用来说明 generation 之外还有几项成本一直没被算进去。

把这些成本一项一项写出来：

\[\text{Net Delegation Value} = U_{\text{verified outcome}} -\lambda_h C_{\text{human effort}} -\lambda_t C_{\text{latency}} -\lambda_c C_{\text{compute}} -\lambda_r E[\text{risk}]\]

$U_{\text{verified outcome}}$ 是用户最终愿意接受、使用并且愿意继续委托的结果，$C_{\text{human effort}}$ 包括 prompt、context setup、monitoring、intervention、review、correction 和 rework，其余几项对应等待、算力和风险。它是一个 conceptual equation，用来提醒我们 autonomy、pass rate 或 latency 变好只说明右边某一项动了，净值未必跟着变好。对于任务价值和验证门槛相近的一组委托，我会进一步看前两项的比值，也就是每换来一个真正算数的结果，所有参与者一共花掉多少分钟。暂且把它叫作 Human Minutes per Verified Valuable Outcome（HM/VVO）：

\[\text{HM/VVO} = \frac{\sum_{i=1}^{N}\sum_{r\in R_i} m_{ir}}{\sum_{i=1}^{N} s_i}\]

$N$ 是这段时间里的委托次数，$R_i$ 是参与第 $i$ 次委托的所有角色，$m_{ir}$ 是角色 $r$ 在这次委托上花掉的分钟数，理解、澄清、监督、验证、维护和返工都算在里面；$s_i$ 只有在结果既通过验证、又真的被采用时才取 1。

三件容易被绕过去的事，必须留在这个定义里。一是 $s_i$ 的验证门槛必须跟着风险走：一个随手可撤的脚本和一次动 production 权限的操作，需要的把握完全不在一个量级，后者的验证成本经常比生成成本还高，所以比较两个系统之前得先把门槛固定，否则少 review 一点就能让数字变好看。二是不同任务的价值差异不能太大，一个低价值小修改和一次关键 migration 都记作一个 outcome 时，比值会失去解释力。三是分子要把所有人的时间都算进去，这一点后面马上会用到。

把 $C_{\text{human effort}}$ 再拆一层，是三笔性质不同的开销。一笔花在让 Agent 朝对的方向走：解释目标、补 context、回答和提出澄清。一笔花在过程里盯着它：看它在做什么、发现偏了、打断、纠正、恢复。还有一笔花在结束之后相信它：读 diff、跑测试、判断边界条件、确认它没动不该动的地方。这三笔要靠不同的办法才降得下来，把它们混在一句“Agent 用起来很累”里，就不知道该改哪一处。

前期 clarification 主要能减少误解、correction 和 rework，独立 assurance 的需求却未必随之下降。在 health information 场景里，主动去要 context 的 Wayfinding AI 在 randomized、blinded study 中被评价为比 baseline 更 helpful、relevant 和 tailored，用户也愿意为了多提供一些 context 而晚一点拿到答案 (Sayres et al., 2025)。这份研究测的是用户对答案的评价和他们愿意付出的耐心，没有直接测出“前期多问一句、后期少改一轮”能省下多少成本；Agent 问得不对时，提问本身就是额外开销。

第二笔开销长什么样，取决于用户能不能看懂 Agent 在做什么。对 17 名 experienced developers 的访谈把 oversight 拆成 a priori control、co-planning、real-time monitoring 和 post-hoc review，也记下了他们怎么靠 tests、扫一眼 diff 之类的 heuristics 来减少必须逐行读的东西 (Dhanorkar et al., 2026)。这些 heuristics 都在替人省注意力，可靠性则取决于它们依据的 evidence 是否真的支持继续往下走，或者仅仅说明 Agent 完成了自己定义的局部目标。如果没有专门设计，这些成本会以 coordination overhead 的形式集中冒出来：让 31 名参与者用商业 Agent 完成代表性任务的研究，记录到 mental model mismatch、trust 建立不起来、collaboration style 不匹配、communication overhead 过高等问题 (Shome et al., 2025)，而这些困难大体可以归成两组：用户如何向 Agent 传达 goal、preference 和 constraint，以及 Agent 如何向用户说明自己的 capability、plan、action 和 side effect (Bansal et al., 2024)。双方建立不起 common ground，用户就既不知道自己有没有被理解，也不知道什么时候该介入。

第三笔通常最难压缩。$\tau$-bench 让 Agent 在 retail、airline 这类 domain 里和 simulated user 对话、调用 domain-specific API、遵守 policy guidelines，最后拿对话结束时的 database state 和标注好的 goal state 比对；除了单次成功率，它还用 $\text{pass}^k$ 来衡量重复多次的 reliability，而 retail domain 的 $\text{pass}^8$ 低于 25% (Yao et al., 2025)。单次成功说明 Agent 找到过一条可行路径，一个团队要把同一类任务稳定地交出去，还需要足够的 assurance。生成的量可以跟着模型和算力一起增长，这种把握却受另一组条件限制：测试覆盖率、CI、staged rollout、审计、出事之后能退回到哪里，还有多少人有时间读。Generation capacity 和 trusted assurance capacity 因此可能以不同速度增长，assurance 也可能成为组织扩大 delegation 时的 binding constraint（图 3）。这里用 assurance 这个词，是因为要建立把握，可以靠 tests、independent checker、rollout、audit 和 human review，逐行阅读只是其中最贵的一条路径。

要是每个 step、每次 tool call、每段 diff 都得由人以同样的强度过一遍，Agent 越自主，人手上的活反而越多。所以工程实践里降低成本的方向，和前面的 supervision leverage 是同一件事在 runtime 的表现：OpenAI 对 agent-first software product 的复盘直接把 human time and attention 当成稀缺资源，做法是把更多 domain context、architecture constraints、observability 和 verification mechanisms 放进 repository 和 harness，让 Agent 能在更大的 problem space 里工作 (Lopopolo, 2026)。人逐渐减少逐行生产和检查，更多精力转向搭建让代码能够被可靠生成、检查和恢复的 environment；这部分工作同样不会被算进任何一次委托的成本里。

还有一个更麻烦的地方：这些时间未必花在发起委托的那个人身上。对 81 个 open-source repositories 里 4,550 条 agentic pull requests 的研究发现，Agent 处理 logging 的方式和人类 developer 明显不同，人没有明确要求时它很少主动补齐，而最终 72.5% 的 post-generation log repairs 由人完成；作者把这些人叫作 silent janitors，因为他们收拾了 Agent 留下的 observability 问题，却未必在 review feedback 里提过这条要求 (Ouatiti et al., 2026)。这份研究测的是谁在修 log；把它读成“一次委托的收益归发起者、成本落到下游维护者”是我的推论，只是这个推论和不少团队的实际感受对得上。这就是分子里那个对 $r$ 求和的意思：$R_i$ 里至少坐着三种人，发起委托的 requester、替他把关的 reviewer、以及事后接手的 downstream maintainer，算这个数的时候把谁计进去本身就是一个选择，而最省事的那个选择（只算 requester 的时间，只算到 delivery 为止）恰好会把成本藏起来。

人应该站在哪一个 loop 上

“Human-in-the-loop”常常被做成在每个 action 前放一个 approval button，或者最后由人点一次确认。这两种做法都把用户的注意力当成可以均匀铺开的东西，可它不是：澄清、监督和验证的成本不同，能换回来的信息也不同。按信息价值来安排的话，人进入 trajectory 的方式大致有四种。低风险、可逆、有强 machine verification 的 action，Agent 直接做完就好。碰到只有用户知道的信息或者 preference-sensitive 的选择，值得花一次 clarification。碰到 money、permissions、production state、security 这类不可逆后果，需要显式 approval。而当 verifier 之间出现分歧、状态异常，或者失败的原因模型自己解释不了时，系统该做的是 escalation。区别在于人被叫来干什么：补信息、给判断、授权，以及在 Agent 已经处理不了的时候接手（图 4）。

“有不确定性就问人”不是一个可行的 policy，因为提问本身消耗用户的注意力，而多数问题的答案并不会改变 Agent 接下来做什么。更合适的判据是这次询问能带来多少 value of information，也就是把答案可能带来的期望收益和用户为此付出的认知成本放在一起比，这个比较会随任务风险、问题的歧义程度和用户所需的投入而变化 (Dong et al., 2026)。这也解释了为什么更爱提问的 Agent 未必更好用。知道自己什么时候该问同样是一种能力，而且不随 capability 自动获得：HiL-Bench 在 software engineering 和 text-to-SQL 任务里加入只有 progressive exploration 才会暴露的 missing、ambiguous 或 contradictory information，要求 Agent 通过 ask_human() 识别 blocker 并提出有针对性的问题，用 Ask-F1 同时衡量 question precision 和 blocker recall 之后可以看到，即使模型在 full-information setting 下表现很好，一旦要自行决定是否求助，它们的 performance 也只能恢复一部分 (Elfeki et al., 2026)。

提问也不是拿到人类判断的唯一方式，有时甚至不是最省事的方式。当用户的偏好要看见具体实现才会变清楚，一个可撤销的小改动、一个 draft PR 或者一次 dry run，比一串抽象问题更快让人说出自己要什么。这类 action 起的是 judgment aid 的作用，它把 refine 和 reconstruct 需要的那个具体对象先造出来，代价是必须真的可撤销。可逆性因此不只是一条安全约束，它同时决定了 Agent 有多少机会用行动代替提问。

有一条界线不会随能力提升而消失。Agent 可以越来越准确地预测用户会批准什么，这不等于它被授权去做：预测说的是会发生什么，授权说的是允许发生什么，模型变准只解决前一半。

不过“必须有人允许”和“必须每次都有人点一下”是两个要求。逐次 approval 大多可以被事先划定的权限范围替代：说清哪一类动作、在什么条件下、影响多大范围之内可以直接做，Agent 就不必每一步回来问，人也不必把注意力耗在低价值的确认上。留下来的是划这个范围的权力，以及范围之外那些影响足够大的动作。

在这些约束下，成熟的用法看起来会有点反直觉。对 Claude Code 和 public API 中数百万次 human-agent interactions 的分析发现，experienced users 会更频繁地 auto-approve，同时也更频繁地 interrupt (Anthropic, 2026)。至少在这批用户身上，autonomy 和 oversight 没有沿着一条轴此消彼长：他们不再点每一个 permission prompt，打断反而更多。数据本身没有说这些打断发生在什么时刻，我的理解是他们把确认从“每一步”挪到了自己认为值得管的地方。这更像是在给自己的注意力挑位置。Magentic-UI 干脆把这种挑法做进了 interface 和 agent architecture，co-planning 让用户在执行前改 plan，co-tasking 让用户在执行过程中用自然语言反馈或者直接接管 browser，另外还有 action guards、answer verification、memory 和 multi-tasking (Mozannar et al., 2025)。提供目标信息、修改计划、接管一个局部 action、只验证最后结果，这些是 delegation workflow 里几个不同的位置，不是一个开关的两端。

但把人放回 loop 里并不自动改善结果。对 106 项实验、370 个 effect sizes 的 meta-analysis 显示，human-AI combinations 平均表现甚至低于 human 或 AI 中更强的一方，在 decision tasks 中尤其容易出现 performance loss，而收益高低与 task allocation、information flow 这些设计因素有关 (Vaccaro et al., 2024)：参与本身不产生收益。更早的一条警告在这里也仍然成立：自动化会把操作者从执行者变成监控者，而人恰恰不擅长长时间盯着一个几乎总是正确的系统，随着自动化接管日常情况，操作者练习的机会减少、技能退化，却被期望在最罕见、最困难的时刻接手 (Bainbridge, 1983)。这两条合起来说明，把人的判断集中到少数几个高价值时刻，本身是有代价的：越少介入，介入时越生疏，而需要介入的又恰好是最难的那些情况。

所以 human-on-the-right-loop 是一个必须靠设计才能达成的目标，不会作为 capability 提升的副产品自动到来。人的判断集中到 goal、context、exception、verification、approval 和 accountability 这些位置，前提是系统真的为这些时刻准备了足够的上下文、足够的可恢复性，以及让人保持理解的手段。缺了这些，autonomy 提高只会让人在更少的时刻面对更难的问题。

The Human Is Part of the Agent

决定一次委托成不成的条件，有不少落在我们习惯称为“Agent”的那个框外面。SWE-bench 上的分数里不包含设计这套 task 和 verifier 的人做出的判断。产品指标里的“完成”不包含事后的 review、维护和恢复。软件意义上的 Agent 不包含谁有权批准、谁是这个系统的 owner。发起委托的那个人的视角里，也看不见被这次委托影响到的其他人。这四处遗漏的形式不同，方向一致：真正把事情做成的那个系统，比我们画的框大一圈。

这一点容易被能力增长盖过去，因为工作被挪到框外的时候，看上去和被消灭掉差不多。从 label 到 task design 的那条线已经演示过一次：人逐渐减少逐条写答案，判断则移到挑 task、写 verifier、决定一个陌生解法是否成功的位置。现在正在发生第二次。Agent 吸收完 execution，又开始吸收 routine control，包括记住上周说过的约束、刷新状态、动手前先取证、跑验证和出错回滚。这部分确实应该由它吸收。替 Agent 维持基本 control 属于还没做完的工程，很难成为人类的长期角色。

吸收完之后，人手上还剩三类性质不同的工作：目标形成处理尚未确定的信息和偏好，assurance 处理相信结果所需的 evidence，authorization 与 accountability 处理允许什么发生、由谁承担责任。

一是目标还在成形。任务有一部分要等 Agent 做出具体的东西，用户才说得清楚。Agent 可以越来越会问，也可以先给一个可撤销的版本让人看见，但问出来的内容只能来自人。这一件不会消失，只会换形式。

二是有人得能相信这个结果。Manual verification labor 正在被快速自动化，测试、CI、staged rollout 和可回滚的发布都在减少人的逐行阅读。Assurance function 仍然存在，变化的是 evidence 由谁产生、怎样汇总。它的上限是验证手段不能和被验证的行为一起错：Agent 自己写、自己跑通的测试不算独立证据。

三是授权和责任。逐次点击的确认大多会消失，事先划定的权限范围就是干这个的。Authorization 回答什么行动被允许发生，这个边界需要由拥有相应权力的人或组织设定。Accountability 回答谁决定部署、谁设置权限，以及事故发生后责任如何分配；它可能分散在 operator、engineering owner、manager、vendor、organization 和 regulator 之间。这些安排在 runtime 之前就要存在。把它们压缩成“loop 上得有个人负责”，等于让点过 approve 的那个人替实现缺陷和部署疏忽兜底。

对那种目标明确、可以自己跑很久的 Agent，这三件事一件都没少，只是全部前移了：目标和成功标准是谁定的，权限划到哪里，这个系统归谁，跑歪了叫醒谁，什么时候有权叫停。人接触这条 trajectory 的次数最少，每一次的分量却最重，accountability 在这一端也最吃紧，因为没有任何一次人工点击可以拿来当作责任的落点。

顺着这个方向往前看，我认为最关键的变化是：交互变少之后，瓶颈会从“人愿不愿意介入”转到“人还来不来得及理解”。平时越不需要人，异常发生时他对这条 trajectory 知道得越少，而需要他判断的又恰好是最难的那些情况。Bainbridge 在自动化驾驶舱上说的就是这件事，Vaccaro 那份 meta-analysis 则从另一头说明，多加几个人工环节也不会自动划算。所以 Agent 产品接下来要拼的一项能力，是在打断发生的那一刻，把足够的东西一次交到对的人手上：相关的历史、现在的状态、支持这个动作的证据、还有哪些选项、做下去的后果、能不能退回来、需要谁的权限。一个只有 Allow 和 Deny 的确认框做不到这件事，而今天大多数产品给的就是这样一个框。

Benchmark 会继续告诉我们模型能解多难的题，这条曲线仍然重要。已经有一些 evaluation 在往旁边挪：$\tau$-bench 问同一类任务能不能反复交出去，HiL-Bench 问 Agent 知不知道自己什么时候该求助，SWE-Together 记录一条 trajectory 需要用户纠正几次。它们的共同难处也正是这个视角的难处：一旦把人算进系统，被测量的对象就扩展成模型与 surrounding delegation system。

人并没有站在 Agent 外面单纯等结果；随着 Agent 的执行能力、对长 trajectory 的 control 和自动验证不断提升，人会更少介入具体执行，更多判断则会前移到目标怎样形成、什么 evidence 足以让结果被采用，以及权限边界应该划在哪里。