⛲人们到底给了 AI Agent 多少自主权？Anthropic 用数据回答了这个问题
type
Post
status
Published
date
Feb 27, 2026
slug
summary
tags
category
技术分享
icon
password
Status
Agent 安全这个话题讨论了一两年了，但之前所有讨论都有一个共同的问题：缺少真实数据。大家要么在假想场景里推演，要么在评估环境里跑 benchmark。真实世界里的用户到底怎么用 Agent、给了多少权限、出过什么问题，没人说得清。
2026 年 2 月 18 日，Anthropic 发了一篇研究报告（作者包括 Miles McCain, Thomas Millar, Saffron Huang 等人），第一次用生产数据来回答这些问题。他们分析了 Claude Code 和公共 API 上的数百万次 agent 交互，用自家的隐私分析工具 Clio 做了一次大规模的实证研究。
这篇文章是我读完这份研究后的解读。我不会逐页翻译原文，而是挑我觉得最值得拿出来讨论的发现和数据来聊，同时也说说我自己的一些想法。如果你在做 Agent 相关的产品或者对 Agent 安全感兴趣，这份研究值得完整读一遍，我在文末附了原文链接。
怎么量化"自主性"这种模糊的东西
研究的第一步是建立测量框架。Agent 这个词被用得太泛了——从一个能调 API 的 chatbot 到能独立完成 5 小时任务的编程助手，都有人叫 Agent。所以他们先给了一个实用主义的定义：
Agent = 配备了工具的 AI 系统，能够采取行动（运行代码、调用外部 API、向其他 agent 发消息）
这个定义兼容 Russell & Norvig (1995) 的经典定义，也兼容 Simon Willison 那个更直白的说法："runs tools in a loop to achieve a goal"。好处是可操作——只要观察工具调用，就能量化分析 agent 行为。不需要猜测模型内部在"想"什么，只看它实际调了什么工具、传了什么参数、产生了什么结果。
双数据源：广度和深度的互补
数据来自两个源头，各有优势和盲区：
Public API 覆盖行业广，能告诉你 agent 在各行各业都做了什么，但只能看到零散的 tool call，无法还原一次完整的工作流。Claude Code 正好反过来，场景几乎全是软件工程，但能看到从用户下达指令到 agent 完成任务的整个链路——包括人在中间干预了几次、在什么时候干预的。
两个拼在一起才勉强算一个完整画像。
打分方法：用 AI 评 AI
对 API 上的每个 tool call，他们用 Claude 自身来打两个维度的分：
维度 | 评分范围 | 低分含义 | 高分含义 |
Risk | 1-10 | 出错无后果 | 可能造成重大损害 |
Autonomy | 1-10 | 严格遵循人类指令 | 独立决策，极少人类参与 |
这里有个绕不开的问题——让 Claude 给自己的行为打分，自评偏差肯定存在。打个比方，你让一个员工自己评估自己的工作风险等级，结果能有多客观？Anthropic 在论文里也承认了这一点，说在内部数据上做了交叉验证，但因为隐私约束，没法让人工审查原始数据。算是坦诚，但这个局限需要一直记在心里。后面所有基于 Risk/Autonomy 分数的分析，都带着这层不确定性。
核心发现一：头部用户在做越来越长的自主任务
99.9 分位的 turn duration（Claude 一次不被人类打断、连续工作的时长）在四个月内从 25 分钟增长到 45 分钟：
但中位数几乎没动，一直在 40-55 秒之间。99 分位以下也都很稳定。
这个分布说明什么？不是所有人都在放飞 Agent，而是一小撮头部用户在持续加码——他们给 Agent 越来越长的任务链，让它连续跑更久。大量新用户还在用 Agent 做一问一答式的短任务，拉着中位数原地踏步。
这有点像早期的云计算采用曲线。2010 年前后，大部分企业还在把云当成"远程虚拟机"用，只有少数先行者在跑全托管的分布式服务。Agent 的使用也是类似的状态——多数人还在浅层使用，头部用户已经在探索深度协作。
还有一个细节我觉得比数字本身更有意思：增长曲线跨越了多个模型版本的发布节点。如果纯粹是模型变强了所以用户敢放手，那增长应该在新模型发布时出现跳变。但实际趋势是平滑的，更像是信任的逐步积累叠加工作流的逐步适配。用户在学习怎么跟 Agent 协作，Agent 的能力提升只是其中一个因素。
Deployment Overhang：能力和授权之间的鸿沟
这篇研究里我最想拿出来说的一个概念。
METR 的评估显示，Claude Opus 4.5 能以 50% 的成功率完成人类需要 5 小时才能做完的任务。但在实际使用中，99.9 分位的连续工作时长也就 42 分钟。
模型能做到的，和人们实际允许它做的之间，有一个巨大的差距。Anthropic 管这个叫 Deployment Overhang。
这个差距有两面性。一面是安全缓冲——模型有能力做更危险的事但没被授权做，这是好事。另一面是产能空间——如果能安全地释放这个差距，Agent 能创造的价值远超今天的水平。
举个具体的例子：一个 Claude Code 用户可能只让 Agent 改改单个文件的 bug，但模型实际上有能力独立完成跨多个文件的重构任务。用户不敢放手不是因为模型做不到，而是不确定模型会不会搞砸，出了问题回滚成本多高。这就是为什么 Deployment Overhang 的释放速度不取决于模型能力的提升，而取决于周边基础设施的成熟——监控、审计、回滚能力到位了，信任自然就跟上来了。
核心发现二：从"驾校教练"到"团队经理"
随着使用经验增加，用户的监督行为出现了一个表面上矛盾的变化：auto-approve 率从 20% 升到了 40%+，中断率同时也从 5% 升到了 9%。
放权和中断同时上升？看起来矛盾，其实一点都不。
新手的策略是事前审批（Pre-approval）——每步操作都要确认才能继续，像驾校教练坐在副驾上随时准备踩刹车。在这种模式下，Agent 走不了几步就要停下来等人点头，中断的机会本来就少。
老手切换成了事后监控（Supervisory）——让 Agent 先放手跑，出了问题再介入。更像团队经理做 code review：不盯着你写每一行代码，但会在关键节点看一眼，方向不对就拉回来。既然 Agent 跑起来了，需要在中途纠偏的频率自然就更高了。
ㅤ | 新手策略 | 老手策略 |
模式 | 事前审批 (Pre-approval) | 事后监控 (Supervisory) |
特征 | 每步操作都要确认 | 放手运行，出问题才介入 |
类比 | 驾校教练踩副刹车 | 团队经理做 code review |
Auto-approve | ~20% | ~40%+ |
中断率 | ~5% | ~9% |
中断需求 | 低（因为每步都审核了） | 高（需要在关键点纠偏） |
监督策略变了，不是信任降低了。
这个发现对做 Agent 产品的人有直接参考价值：不要给所有用户强制同一套审批流程。新手需要扶手，老手需要仪表盘。好的 Agent 产品应该同时支持两种监督模式，并且提供从前者到后者的平滑过渡路径。
类比一下 IDE 的设计思路可能更好理解。VS Code 不会因为你是新手就把终端功能藏起来，也不会因为你是老手就取消语法高亮。它在同一个界面里同时提供了不同层级的辅助，用户按需取用。Agent 产品的监督机制也应该是这个思路——默认开着安全网，但让有经验的用户能方便地调整控制力度。
核心发现三：Agent 比人更爱喊暂停
这是我在整篇研究里觉得最意外的一组数据。
在复杂任务中，Claude 主动暂停请求确认的频率，是人类中断它的 2 倍以上：
差距在任务复杂度越高时越明显。Minimal 复杂度下两条线还比较接近，到 High 复杂度就拉开到 25% vs 11%。
更有意思的是暂停/中断的原因分布。
Claude 主动暂停的 Top 5 原因：
原因 | 占比 |
向用户展示多个方案供选择 | 35% |
收集诊断信息或测试结果 | 21% |
澄清模糊或不完整的需求 | 13% |
请求缺失的凭据/token/权限 | 12% |
在采取行动前请求批准 | 11% |
人类中断 Claude 的 Top 5 原因：
原因 | 占比 |
提供缺失的技术上下文或纠正错误 | 32% |
Claude 运行太慢/卡住/过度执行 | 17% |
已获得足够帮助，可以自行继续 | 7% |
想要自己执行下一步（测试/部署/提交） | 7% |
中途变更需求 | 5% |
两边停下来的理由完全不同。Claude 停下来主要是因为它自己不确定——有多个合理选项不知道选哪个，信息不够做不了判断，或者觉得操作有风险想先问一声。人类打断 Claude 主要是因为 Claude 搞错了方向或者做的事不是人想要的。
这两类暂停的性质有根本区别。Claude 的主动暂停是"我知道我不知道"——这是一种元认知能力。人类的中断是"你做错了但你自己没意识到"——这是模型的真正盲区。一个理想的 Agent 应该尽量多做前者、少触发后者。从数据看，Claude 在这方面做得不算差，但 32% 的人类中断来自"纠正错误"也说明还有很大的改进空间。
换句话说，至少在 Claude Code 的实现里，模型的不确定性校准是有效的。它知道什么时候该停下来问人。这跟很多人对 Agent 的直觉认知不太一样——经常听到的担忧是 Agent 会闷头执行造成不可逆后果。数据显示，至少目前，Agent 的问题不是不停，而是有时候停得太多（用户嫌它磨叽想让它直接干活的情况占了 7%）。
训练模型识别自身的不确定性并主动暂停，是一种内生的安全机制。它跟外部的权限系统、人类审批流程形成互补——一个从模型内部兜底，一个从外部框架兜底。
风险分布的全景
风险-自主性四象限
研究对 API 上的 agent action 做了一个风险 vs 自主性的四象限分析：
大部分 action 聚集在左下角——低风险、低到中自主性。右上角（高风险 + 高自主）几乎是空的，但不是完全空的。能看到 "API Backdoor" 这种点落在了危险区，不过 Anthropic 指出这些往往是安全评估或红队测试，不一定是真实的恶意操作。问题是，从数据上无法区分。
几个关键数字：
- 80% 的 tool call 有某种形式的安全措施（权限控制、沙箱、确认流程等）
- 73% 有人类参与
- 只有 0.8% 的操作不可逆（比如发送邮件给客户）
0.8% 听起来很小。但乘以百万级的调用量，绝对数字就不小了。
行业分布：软件工程一家独大，但高风险行业在冒头
软件工程占了半壁江山，原因很直观：代码是最容易验证的输出（跑一下就知道对不对），软件工程师是最早接触和构建 agent 工具的群体，而且出了错还能 git revert。
但金融（5%）、医疗（2%）、网络安全（2%）这些高风险领域已经出现了。它们目前体量小，但一旦出错的后果比代码写错严重得多。一个错误的交易指令、一份泄露的病历、一次失控的安全扫描，都不是 git revert 能解决的。
这里有一个不对称性值得注意：软件工程之所以成为 Agent 的第一战场，很大程度上是因为试错成本低、反馈循环快。但当 Agent 扩展到金融、医疗这些领域时，试错成本会成指数级增长，而反馈循环会变慢——一个错误的 campaign 配置可能要跑几个小时才能发现问题，一个不当的用药建议的后果可能要几天甚至几周才能显现。这意味着从软件工程中总结出来的 Agent 监督经验，不能简单照搬到其他行业。每个行业需要根据自己的试错成本和反馈周期，设计不同的安全边界。
研究给谁提了什么建议
研究最后对四类人群分别给了建议，我把原文建议和自己的解读放在一起：
对象 | 建议 | 我的理解 |
模型开发者 | 投入后部署监控基础设施 | 目前缺乏跨 API 请求的 session 关联能力，这是最大的基建瓶颈。你连一个 agent 干了什么都串不起来，谈什么安全监控 |
模型开发者 | 训练模型识别自身不确定性 | Claude 的主动暂停行为已经证明这条路能走通 |
产品开发者 | 设计支持用户监督的产品 | 提供可观测性和干预机制，而不是强制审批流。可观测性 > 审批流 |
政策制定者 | 不要急于规定特定交互模式 | 强制逐步审批会制造摩擦，但不一定带来安全收益。从数据来看，老用户自然演化出的事后监控模式可能更高效 |
局限性——以及为什么它仍然有价值
这篇研究的 limitations section 写得很长，几乎和 findings 部分一样详细。列一下主要的：
- 只有 Anthropic 一家的数据。GPT、Gemini 上的 agent 使用模式可能完全不同
- 用 AI 给自己打分，自评偏差无法消除
- Claude Code 数据几乎全是软件工程场景，对其他行业的代表性很弱
- 无法区分真实的高风险操作和安全评估/红队测试
- API 数据按 tool call 采样，高频操作被过度代表
不回避问题的研究才值得参考。不管这些局限怎么样，有一件事是确定的：这是第一次有模型提供商拿出生产数据来量化 Agent 自主性。之前所有关于 agent 安全的讨论都在评估环境或假想场景里打转，这次终于踩到了真实世界的地面上。
当然，一家公司的数据只能代表一家公司的生态。Claude Code 的用户群体、Claude 模型的行为特征、Anthropic 的安全训练策略，都在塑造这些数据的形态。如果 Google 或者 OpenAI 做同样的研究，结果可能会很不一样。但至少 Anthropic 开了个头，给了后续研究一个可以对标的 baseline。我期待看到其他模型提供商也能发布类似的报告，到时候交叉比较才能看出更完整的图景。
我从这篇研究里发现的东西
读完之后反复回想的几个点。
监督策略应该随用户成熟度演进。产品设计上同时支持事前审批和事后监控，不要强制所有人走同一条路。这个听起来是常识，但真正做到的 Agent 产品目前不多。大部分工具要么默认全锁死，要么给个
--auto-approve flag 一键全放开，中间的渐变地带几乎是空白。Agent 自我暂停这件事值得持续投入。数据已经证明它有用，而且用户对它的接受度比我预想的高。训练模型识别自身的不确定性并主动停下来，和外部的权限系统、人类审批形成互补，两条腿走路比单靠一条强。我甚至觉得"Agent 什么时候不该继续"比"Agent 能做什么"是一个更有价值的研究方向。
风险分级应该是动态的，不是静态的。一个 senior dev 在自己熟悉的 repo 里 auto-approve 是合理的；同一个人在一个陌生的 production 环境里应该被提示确认。不同用户、不同任务、不同时间段，风险阈值不该是同一个数字。这跟推荐系统里的 context-aware ranking 其实是类似的思路——同样的内容在不同上下文里风险完全不同。
最后是 Deployment Overhang。模型能力和实际授权之间的差距不会自动消失，需要基础设施（监控、审计、回滚）先到位，信任才能逐步释放出来。这中间的节奏感，可能是接下来做 Agent 产品最需要拿捏的东西。走太快会出安全事故，走太慢会被竞品超过。而这个节奏没有标准答案，只能一边走一边看数据一边调——这大概也是为什么 Anthropic 觉得这类测量研究值得做的原因。