R

A05 Agentic Coding 信任校准

创建 2026-06-07 更新 2026-06-11 5 条双链 编程工具 专题 AI 整理

A05 Agentic Coding 信任校准

当一个编程 agent 能自己读代码、改文件、跑测试、提交 git，PM 与开发者真正要回答的不是”它能不能干活”，而是**“我该在哪一步放手、在哪一步必须按住它”**。这就是信任校准（trust calibration）问题：信任既不能太低（每步都确认 → agent 退化成贵了 10 倍的自动补全），也不能太高（全自动放行 → 一次 rm -rf 或一次强推 main 就是灾难）。本节用”信任校准错位”作为判断主轴——把 auto-accept、YOLO/auto mode、HITL（human-in-the-loop）边界、Copilot→autopilot 光谱放在同一根坐标轴上，回答 PM 在选型会和产品设计评审里最该问的一个问题:这个工具把”判断权”交给了谁，在什么粒度上交的?

§0 为什么是”信任校准”,而不是”自动化程度”

最容易上手的错误框架是把工具按”自动化程度”从低到高排个序——补全 < Chat < Agent < 全自动——然后默认”越自动越先进”。这个框架在选型会上会直接把人带沟里,因为它隐含了一个错误前提:自动化是一根越高越好的单调标尺。

正确的框架是校准(calibration)而非程度(degree)。校准这个词借自仪表与人因工程:一个校准良好的信任,是指”人对系统的信任程度,恰好匹配系统在该情境下的实际可靠性”。信任低于可靠性叫under-trust(该放手时不放手,效率损失);信任高于可靠性叫over-trust / 自动化偏见(该接管时不接管,灾难风险)。两个方向都是”错位”,而错位的代价不对称——over-trust 的尾部风险远大于 under-trust 的效率损失。

所以本节不问”它有多自动”,而问三件事:(1) 在哪个粒度上请求确认(每个 token / 每次编辑 / 每个不可逆动作 / 任务结束);(2) 谁做”是否安全”的判断(人工 / 模型分类器 / 静态规则);(3) 判断失效时,系统是 fail-safe(默认拦截)还是 fail-open(默认放行)。这三问能把”光谱位置”翻译成”风险敞口”,而风险敞口才是 PM 的决策变量。

[!note] 这是对 m207 - Agent 产品化：场景推演与失败模式 的 HITL 段与 S03 Harness Engineering 全景（§4 confirmation 设计）的升级对照：那两个节点把 HITL 当成”要不要加确认环节”的功能问题；本节点把它重述为”信任与可靠性的匹配问题”,并补入 2026 年的实测数字与协议级缺口。不复述其基础论述。

§1 Copilot→Autopilot 信任光谱:把产品翻译成坐标

把主流工具的实际模式排到同一根轴上,光谱本身就是一张选型决策表。

信任档位确认粒度谁判断安全代表实现（口径 2026-06-07 WebFetch 官方文档·待核实持续变动）
手动审批每步每个工具调用人Claude Code default（仅读取自动），GitHub Copilot 非 autopilot
Accept Edits每次文件编辑批量放行人（事后）Claude Code acceptEdits
Plan-first先出计划再执行人（审计划）Claude Code plan 模式
Auto mode几乎全自动，分类器兜底模型分类器Claude Code auto（research preview）
YOLO / bypass全放行，无检查无Claude Code bypassPermissions；Copilot CLI /allow-all（别名 /yolo）

几个 PM 必须抓住的设计细节(均来自官方文档,口径 2026-06-07,⚠️ 该领域版本迭代极快,标〔以2026-06为准·待核实〕):

  • GitHub Copilot CLI 的 /yolo 一旦开启不可撤回——再次输入命令不会收回权限,只能重启会话。这是一个值得在产品评审里反复举的反例:不可逆的”放手”按钮本身就是 over-trust 陷阱。Copilot 用 --max-autopilot-continues 设步数上限作为熔断(来源:GitHub Docs Copilot CLI autopilot 页,WebFetch 2026-06-07)。
  • Claude Code auto 被官方明确标为 “research preview”,文档原话是”reduces prompts but does not guarantee safety”(来源:Claude Code 权限模式官方文档 code.claude.com/docs/en/permission-modes,WebFetch 2026-06-07)。这句免责声明本身就是信任校准自觉的范本:它没有假装”分类器=安全”。
  • bypassPermissions 官方限定用于隔离容器/VM——也就是说,真正的 YOLO 模式的正确用法是”先把灾难半径关进沙盒,再放手”,而不是”在生产机上信任 agent”。

这根光谱的核心洞察:档位本身无优劣,错位才有。 在一次性脚本的隔离容器里跑 bypassPermissions 是合理的;在能 push 到生产 main 的工作树里跑 auto,就是把灾难敞口押在一个 17% 漏报率的分类器上(见 §2)。

§2 判断主轴:信任校准错位的四种致命搞错

这是本节的命门。Agentic coding 的信任校准,90% 的人会在以下四处搞错。每条给”症状 → 为什么会错 → 正确做法 → 真实反例”。

错位一:把”高批准率”当成”监督有效”

  • 症状:团队上了”每步确认”模式,看到开发者批准了绝大多数请求,得出结论”人在回路,很安全”。
  • 为什么会错:高批准率恰恰是监督失效的信号,不是有效的信号。当确认弹窗每小时来上百次,人会进入”橡皮图章”状态——这是人因工程里经典的确认疲劳(confirmation fatigue)。Anthropic 工程博客披露了一个尖锐的数字:在引入 auto mode 前,用户批准了 93% 的权限请求(来源:Anthropic Engineering Blog “How we built Claude Code auto mode”,2026-03-25,WebFetch 2026-06-07)。93% 的批准率意味着这道”人工闸门”实际上几乎不拦任何东西。
  • 正确做法:把确认预算花在刀刃上——只在不可逆性边界请求确认,而不是每步或仅末尾。一项设计研究(arXiv:2510.05307)发现,在可逆性边界处确认相比全量确认,任务时间减少 13.54%,且 81% 的参与者偏好这种方式优于”全量确认”或”仅末尾确认”。
  • 真实反例:安全运营领域早有前车之鉴——SOC 团队每日接收约 4,484 条告警,其中 67% 因疲劳被忽视(来源:Vectra 2023,via Rippling Agentic AI Security Guide 2025)。Rippling 把”Overwhelming Human-in-the-Loop”(用海量警报压垮人工回路)列为 agentic AI 威胁 T10——攻击者可以主动制造确认疲劳来让恶意动作蒙混过关。

错位二:把”分类器兜底”等同于”安全”

  • 症状:选了 auto mode,认为”反正有模型分类器把关危险动作,可以放心全自动”。
  • 为什么会错:Anthropic 自己公布的 auto mode 实测数字(测试集:10,000 真实动作 + 52 已知风险行为 + 1,000 合成外泄尝试)是——假阳性率 0.4%(无害动作被误拦),假阴性率 17%(危险动作被放行)(来源:同上 Anthropic Engineering Blog,2026-03)。0.4% 的误拦说明它确实”不太烦人”,但 17% 的漏报意味着大约每六个真正危险的动作就有一个被放行。把这个数字摆到选型会上,“分类器=安全”的幻觉立刻破产。
  • 正确做法:把分类器理解为”降低提示疲劳的过滤器”,而非”安全保证”——这正是官方文档”does not guarantee safety”的字面意思。真正的安全来自灾难半径控制(沙盒/容器)+ 不可逆动作硬拦截(默认阻断 curl | bash、生产部署、强推 main、删除会话前已存在文件等)的组合,而不是单点依赖分类器。
  • 真实反例:auto mode 的分类器在设计上有一个反操控的细节值得 PM 学习——它只看用户消息和工具调用,不看 assistant 的文本和工具输出,因为如果让它读 agent 的”解释”,agent 可以用说服性话术操控判定;同理服务端有一道 prompt injection probe 扫描工具输出,防止抓取的网页里嵌入越权指令劫持 agent(来源:同上)。这说明”由模型评判模型”是一个 self-referential 的脆弱设计,需要专门的架构约束去堵。

错位三:把”代码质量提升”误读为”可以跳过审查”

  • 症状:agent 生成的代码初见质量越来越好,开发者越来越倾向直接 accept,审查越来越走过场——典型的 vibe coding 路径。
  • 为什么会错:这是 vibe coding 研究里点名的 “auto-accept 悖论”:随着 agentic 模型能力提升,代码初始质量改善 → 开发者越发倾向跳过审查 → 永远无法建立对系统的功能性理解(来源:vibe coding 研究 arXiv:2505.19443 等,2025)。代码审查在这里不只是质量控制,更是维持作者归属感与对系统理解的认知活动——跳过它,人就从”能维护系统的工程师”退化成”无法辨别错误的旁观者”。
  • 正确做法:区分”辅助型信任”(AI 加速一个本就有能力判断输出的开发者)与”替代型信任”(AI 替代了本应由人保留的认知活动)。前者增强 DX,后者侵蚀 agency。产品上对应的设计是:把审查从”可跳过的弹窗”变成”低摩擦但不可省略的环节”(如 diff 预览 + 一键回滚,而非默认 accept all)。
  • 真实反例:ReversingLabs 2025 年记录了 vibe coding 直接引入”密码明文存储”等漏洞的案例;BNY Mellon × GitHub Copilot 的混合方法研究(arXiv:2602.03593,n=2,989 问卷 + 11 深度访谈,2026-06)明确指出技能侵蚀对初级开发者的长期职业风险——他们最依赖 AI、认知负荷最高,却最缺乏评估输出的心理模型。

错位四:把”感觉更快”当成”真的更快”

  • 症状:开发者主观觉得 AI 让自己飞快,于是更愿意把更多判断权交给 agent。
  • 为什么会错:感知与实测可以符号相反。METR 的随机对照试验(arXiv:2507.09089,16 名平均 5 年经验的开源开发者,246 个任务,工具为 Cursor Pro + Claude 3.5/3.7 Sonnet,研究期 2025 年 2–6 月)发现:允许使用 AI 工具时任务完成时间增加 19%——而开发者事前预测会快 24%、事后估算仍认为快了 20%(来源:METR,arXiv:2507.09089 + metr.org/blog/2025-07-10,WebFetch 2026-06-07)。⚠️ 这是 volatile 结论〔以2026-06为准·待核实〕:样本小(n=16)、仅针对成熟项目的资深开发者,METR 已于 2026-02-24 宣布调整后续实验设计。但方向相反这件事本身,足以警告”感知”不能作为信任校准的依据。
  • 正确做法:信任校准要锚定客观可观测信号(测试通过率、回滚率、PR 返工率),而非主观流畅感。产品侧应主动暴露这些信号(置信度、动作审计、回滚率仪表盘),帮助用户校准而非放任自动化偏见。
  • 真实反例:Faros AI 的生产数据(高 AI 采用团队)显示 PR 数 +98%、审查时间 +91%、PR 体积 +154%、人均 bug +9%(来源:Faros AI,via TianPan.co 2026-04)——“产出感”暴涨的同时,审查负担和缺陷一起涨。这正是”感觉更快”与”系统真的更健康”之间的裂缝。

§3 产品 PM 视角补盲:三个工程视角看不见的坑

跳出”哪个模式更安全”的工程视角,信任校准还有三处 PM 容易看走眼的地方。

  1. 用户心理模型:信任是粒度化、动态的,不是一个全局开关。 vibe coding 研究指出,信任”随互动演化,表现为便利与谨慎的平衡”。所以”全局 auto approve”这种一锤子设置(JetBrains 2026-04 推出过类似全局开关)在心理上是危险的——它把一个本应随任务、随风险动态调节的判断,冻结成了一个静态承诺。好的设计是 Smashing Magazine(2026-02-11)总结的 Autonomy Dial(自主度旋钮):建议 → 提案 → 确认后执行 → 自主执行,4 级可随时调。

  2. 商业模式:确认粒度直接耦合计费模式与留存。 当工具从”订阅包月”转向”用量计费”(Cursor 2025-06 转 Credit 制、GitHub Copilot 2026-06-01 全面转 AI Credits、Windsurf/Devin Desktop 2026-03 转 Quota 制,均⚠️〔以2026-06为准·待核实〕),“每个 agent 动作都烧钱”的现实会改变用户的信任策略:用户会因为”怕烧 credit”而过度确认(under-trust),或因为”已经付了钱不想浪费”而过度放手(over-trust)。Visual Studio Magazine 2026-04 那篇标题”You Will Get Less, but Pay the Same Price”反映的开发者焦虑,本质是计费不确定性污染了信任校准。

  3. 合规边界:自动化放行触碰的是责任归属。 当 agent 自主 push 到生产、自主修改 IAM 权限,出了事谁负责?这不是技术问题而是治理问题。Claude Code auto mode 默认阻断的清单(curl | bash、向外部端点发送敏感数据、生产部署、IAM 修改、强推 main、不可逆删除)实际上是一份**“绝不自动放行的高责任动作清单”**——PM 在做企业版时,这份清单应该是可配置、可审计、可对接组织合规策略的,而不是写死在代码里。

§4 对手框架回应:接受反方,标注边界

业界反方立场(强自动化派): “93% 批准率证明人工确认已经失效,与其维持一道形同虚设的人工闸门,不如交给分类器——0.4% 的误拦率说明它比疲劳的人类更可靠。每小时 100 次弹窗从根本上摧毁心流,这才是真正的 DX 灾难。”

接受的部分: 这个立场对了一大半。确认疲劳是真实的,93% 批准率确实说明逐步人工审查在高频场景下名存实亡;心流被打断的非线性代价也真实——研究显示哪怕 10% 的中断率都可能让总任务时间接近翻倍。把”是否需要人工逐步确认”当成信仰来坚持,确实是 under-trust 的教条。

坚持的边界与赌注: 但本节坚持把争议重新定位——问题不是”人 vs 分类器谁更准”,而是”在哪个粒度、对哪类动作用谁来判断”。17% 的漏报率在”隔离容器里跑实验”时完全可接受,在”能强推生产 main”时绝不可接受。我赌的是:正确答案不是光谱的某个固定点,而是按动作可逆性分段——可逆动作交分类器/全自动,不可逆动作硬拦截到人。 这个赌注会在一种场景下失效:当”可逆性”本身难以静态判定时(比如一个看似只读的查询触发了下游副作用),分段策略会漏判——这正是 §2 错位二里 prompt injection probe 想补、但只补了一部分的盲区。

Rick 未读的对手框架——MCP 协议级缺口(B.C. Smith 式的”实现 vs 规范”裂缝): 一个常被忽略的对手视角是:信任校准的失败可能不在产品层而在协议层。changkun.de 的分析《Confirmation Fatigue and the Protocol Gap》(WebFetch 2026-06-07)指出,MCP 规范虽写了”hosts MUST obtain explicit user consent”,却随即用 SHOULD 削弱为软约束,且缺失 approval/request 这样的 JSON-RPC 方法、缺失工具元数据的 requiresApproval 字段、缺失权限作用域机制。结果是每个客户端各自为政(Claude Code 用 allow/deny/ask 数组、Cline 提供细粒度自动批准),用户甚至能用 JavaScript 注入绕过 Electron 应用的确认弹窗。这逼问本专题一个盲点:我们一直在产品层讨论信任校准,但如果底层协议不提供”请求确认”的一等公民原语,任何产品层的校准都是各家私搭的脚手架,无法跨工具迁移、无法被审计。 信任校准最终需要协议级的标准化,这是 2026 年仍未解决的结构性问题。

§5 跨域呼应:阿伦特的 work vs labor——auto mode 抹掉的是哪一种?

汉娜·阿伦特在《人的境况》(The Human Condition, 1958)里区分了 labor(劳动) 与 work(工作):labor 是循环往复、不留痕迹、维持生命过程的消耗性活动(吃了又饿、扫了又脏);work 是创制持久之物、在世界上留下人造物、带有作者归属(authorship)的活动。这组区分恰好切中 agentic coding 信任校准的伦理核心。

把它落到本节点的具体判断上:auto-accept 自动化掉的,理应是 coding 中的 labor 部分,而非 work 部分。 重复的样板代码、机械的格式修正、跑测试等待结果——这些是 labor,抹掉它们是纯收益,这正是信任校准里”该放手”的一侧。但架构决策、命名、对系统取舍的判断、对”这段代码为什么这样写”的理解——这些是 work,是开发者在代码世界里的作者性所在。§2 错位三的”auto-accept 悖论”用阿伦特的语言就能说穿:当自动化从 labor 越界吞噬 work,开发者就从代码的”作者”退化为代码的”消费者”——他不再创制和理解,只是不断接受又遗忘,陷入 labor 式的循环(accept 了又来、看了又忘)。

这给信任校准一个伦理判据而非纯效率判据:校准的边界不应只画在”可逆/不可逆”(风险维度),还应画在”labor/work”(作者性维度)。一个动作即便可逆、即便低风险,如果它属于 work——属于开发者必须保留理解的认知活动——那么”为了省事而自动放行”也是一种侵蚀。这与 RedMonk(2025-12-22)调研里开发者把”回滚能力""细粒度权限”列为顶层需求遥相呼应:开发者要的不是”少做事”,而是”保留对什么是自己作品的判断权”。〔此为 Rick 视角的跨域诠释,阿伦特原文未直接论及 AI,属推演性应用〕

[!note] 这条呼应可链入 0117社会学 的劳动与异化讨论。阿伦特的 work/labor 与马克思的劳动异化是两套不同框架——前者讲”创制 vs 消耗”的活动类型学,后者讲”劳动产品与劳动者的分离”,此处取阿伦特而非马克思,因为信任校准的核心是”作者性/理解”的保留,而非”产品归谁所有”。

§6 PM 决策启示:面试·选型·复现三类落地

  • 面试怎么用(尤其字节 TRAE 方向): 当被问”怎么评价一个 coding agent 好不好”,不要答”看 SWE-bench 分数”,而要答”看它的信任校准设计——确认粒度、谁判断、失效时 fail-safe 还是 fail-open”。可以直接甩出 Anthropic 那组数字:93% 批准率证明逐步确认失效、17% 漏报证明分类器不等于安全,然后给出”按可逆性分段”的判断。再带一手洞察:Claude Code 作为 CLI 工具,把权限模式做成显式的命名档位(default/acceptEdits/plan/auto/bypassPermissions),本身就是一种”让信任校准可被言说、可被配置”的产品哲学——这是 Rick 作为深度用户能讲出的体感。对 TRAE 方向,要点出 TRAE 的 Builder/SOLO 模式(自然语言→PRD→代码→测试→部署全链路)在光谱上更靠 autopilot 端,它的信任校准设计是否经得起 §2 四问,是一个值得在面试里展示判断力的切口;同时 TRAE 2025-07 曾因遥测/数据采集争议(Unit 221B 报告、The Register 2025-07-28)被质疑——这提示”信任”在国产工具语境里还多一层数据主权维度〔以2026-06为准·待核实,争议尚未完全平息〕。

  • 选型怎么用: 把 §1 的光谱表打印出来,对每个候选工具填三列——确认粒度、谁判断、失效行为。再叠一个问题:这工具的”放手”按钮可不可逆?(Copilot /yolo 不可逆是个减分项)。企业选型额外查:高责任动作清单可不可配置、可不可审计、能不能对接组织合规。

  • 复现怎么用: 自己搭 agent 时,默认 fail-safe(不确定就拦截到人),把灾难半径关进容器再考虑放手;确认环节只放在不可逆性边界(arXiv:2510.05307 的 13.54% 时间收益就来自这里);主动记录回滚率/返工率作为信任校准的客观信号,别信”感觉更快”(METR 的 +19% 反例)。

§7 与已有节点的关系

本节点对照三个旧节点,做的主要是纠偏 + 深化:

§8 关联节点

核心(必读):

延伸(可选):

修订日志

  • R0(2026-06-07):首稿。建立”校准 vs 程度”框架,Copilot→autopilot 光谱表,四种信任校准错位(确认疲劳/分类器≠安全/auto-accept 悖论/感知≠实测),阿伦特 work/labor 跨域呼应,MCP 协议级缺口对手框架。核心数字接地至 Anthropic Engineering Blog(2026-03)、METR(arXiv:2507.09089)、arXiv:2510.05307、Vectra/Rippling。产品定价/用户量及 TRAE 争议均标 volatile〔以2026-06为准·待核实〕。