Human–Agent Interaction、Autonomy 与 Trust Calibration 深潜

研究基线：2026-08-03。本文是总纲 Part 13 的专题展开，目标不是罗列 UX 功能，而是建立一套可以用于架构、产品、评测和面试推演的统一控制论。

本文只讨论一个核心问题：

当一个不完全可靠、会调用真实工具、可连续运行很久的概率系统代表人行动时，怎样让人和 Agent 对目标、权限、进度、证据、风险与接管条件保持共同理解？

三个总判断：

1. Human–Agent Interaction 不是聊天界面问题，而是一个分布式控制协议。 人、模型、runtime 和外部世界对状态的观察不完全一致；工具动作有延迟、失败和部分副作用；因此必须显式设计状态、提交、回执、中断和恢复。
2. Autonomy 不是数轴上的高低，也不是 manual / auto / yolo 单开关。 它是关于 scope、capability、effect、horizon、budget、initiative、oversight 和 verification 的条件向量；产品模式只是这个向量的粗粒度投影。
3. 目标不是让用户“更信任” Agent，而是让其 reliance 与 Agent 在当前条件下的真实可靠性相匹配。 好系统既降低过度依赖，也降低不必要的不信任；展示行动证据比生成听起来合理的解释更重要。

证据与时效口径：本次线上复核截止 2026-08-03。正文把四类材料分开使用：同行评审研究、尚可能修订的预印本、厂商 telemetry / field observation、以及产品文档 / 公共实现。产品文档只能证明“当前公开 contract 如何定义”，不能证明该机制在真实用户中安全有效；观察数据能描述共现，不能自动给出因果；小样本 HCI 研究适合揭示机制，不应直接外推生产效应量。Kimi Code 与 pi 使用固定 commit；Claude Code、GitHub Copilot 与 OpenAI Codex 的公开规范按复核日快照描述，后续可能漂移。文中规范性架构判断是基于证据约束后的设计推论，不伪装成实验结论。

0. 这门课的对象边界

0.1 五个经常被混为一谈的概念

关键关系是：

Capability 决定可行集合
Authority 截断合法动作集合
Autonomy 决定集合中哪些动作可自行推进
Trustworthiness 决定推进是否有客观依据
Trust / Reliance 决定用户是否真的委派、采纳或接管

能力增强不会自动扩大 authority；用户连续十次批准也不会自动赋予永久 authority；一次成功也不能证明另一 repo、另一工具或另一 effect 上同样可靠。

0.2 Interaction 的正确抽象：部分可观测的联合控制系统

设：

• W_t：外部世界真实状态，如文件、进程、Git、CI、部署状态；
• S_t：runtime 持久化任务状态；
• C_t：模型在当前 context 中看到的投影；
• U_t：用户心中对目标和状态的理解；
• V_t^k：第 k 个 surface（TUI、IDE、desktop、web、mobile）展示的任务投影；
• A_t：Agent 提议或执行的动作；
• H_t：用户的澄清、批准、steer、接管或取消动作。

优秀交互的目标不是让四种状态永远相同——这在异步系统中不现实——而是保证：

1. 关键差异可检测；
2. 用户知道当前相信的是什么、证据是什么；
3. effect 发生前存在正确粒度的控制点；
4. effect 发生后存在 receipt、reconciliation 与恢复路径；
5. 中断、重启、compaction 后不会把叙述误当事实；
6. 任一 surface 发出的 steer、approval、stop 都有 task / turn identity、ack 和可收敛状态，而非各自维护一份真相。

所以 transcript 只是用户可见投影，不能兼任 world state、journal、permission ledger 和 model context。

0.3 成功函数必须包含人的成本

一个 delegated task 的净价值可粗略写成：

Net Value
= P(verified success) × task value
- execution cost
- expected failure / recovery loss
- active human attention cost
- verification cost
- context-switch cost
- trust miscalibration cost

只优化 autonomous task success，可能把成本转移为巨量 diff review；只优化 approval 次数，可能把风险转化为 silent effect；只优化 wall-clock time，可能掩盖用户同时监管十个任务的注意力崩溃。

1. Interaction Contract：人机合作的最小完备契约

1.1 一次委派究竟委派了什么

自然语言任务不能直接等同于可执行授权。一个最小委派契约应表示为：

Delegation D = (
  principal,          谁授权、谁承担最终责任
  goal,               期望结果
  non_goals,          明确不做什么
  scope,              可读写对象与边界
  authority,          可用 capability 与 effect 上限
  constraints,        架构、风格、安全、合规约束
  acceptance,         什么证据构成完成
  budget,             时间、token、金额、并发、工具调用预算
  checkpoints,        哪些决策点必须对齐
  escalation,         何时、向谁、以什么证据请求决策
  expiry,             授权何时失效
  recovery_policy     失败、中断和部分提交如何处理
)

这不是要求用户每次填写十二个字段。产品职责是从组织策略、workspace 配置、任务类型和对话中编译出 contract，并只对高信息增益或高后果的缺口提问。

1.2 Contract 的核心不变量

1. No authority by inference：模型可以推断目标，不能推断新增权限。
2. Negative constraints dominate convenience：用户说“不部署”“不要改 X”后，任何便利性推断都不能覆盖它。
3. Completion is evidence-gated：模型只能提议 done，完成状态由 acceptance evidence 决定。
4. Effect is attributable：每个外部副作用都能追到用户授权、policy 决定、tool intent 和 receipt。
5. Revocation is prompt：用户撤销或缩小授权后，未来动作立即服从；已在途动作必须进入 reconciliation。
6. Preference is not permission：学到“用户偏好少打断”不等于学到“可以读取密钥或部署生产”。
7. Scope cannot silently expand：从修一个 bug 扩到升级依赖、重构全仓库，必须成为显式 re-scope。

1.3 Contract 编译流水线

Intent Compiler 负责解释想要什么；Policy Compiler 负责什么允许做；二者必须分离。让 LLM 同时自由解释意图与决定权限，会把 prompt injection、错误推断和权限扩张合并成同一个不可审计判断。

1.4 Contract Card：用户真正需要看见的内容

长 plan 通常不是好的 control surface。高质量的 contract card 应压缩为：

objective: 修复登录回调偶发丢失 state 的根因
will_touch:
  - auth callback handler
  - state persistence tests
will_not_touch:
  - deployment
  - dependency upgrades
decision_points:
  - 如果根因需要 schema migration，先询问
evidence:
  - reproducer fails before / passes after
  - targeted tests
  - full auth suite
authority:
  read_repo: allow
  edit_workspace: allow
  network: ask
  external_effect: deny

信息设计原则：突出边界、决策点和完成证据，不展示模型的逐 token 思考过程。

2. Delegation、Shared Intent 与 Mixed Initiative

2.1 Shared intent 不是“模型复述了一遍需求”

Shared intent 至少包含五层共同状态：

Agent 与用户无需对每个实现步骤达成共同理解；但在 outcome、硬约束、重大 tradeoff 和 completion 上必须对齐。所谓 shared intent 是可更新的任务状态，不是开场 prompt 的永久解释。

2.2 不确定性来自不同来源，不能一律“问用户”

2026 年预印本 Ask or Assume? 在人为构造的 underspecified SWE-bench Verified 变体中，把“检测信息缺口”与“执行代码任务”分离；其 OpenHands + Claude Sonnet 4.5 多 Agent scaffold 报告 69.40% resolve，单 Agent setup 为 61.20%。这支持“主动澄清可以提升欠规格任务表现”的方向，但证据来自模拟用户、派生 benchmark 和特定 scaffold，不能直接推导真实用户体验或通用产品收益。

2.3 Mixed initiative 的本质：谁在什么时候获得发言权和决策权

Mixed initiative 不等于 Agent 多问问题，而是人和 Agent 都能在任务生命周期中主动：

• 人可定义、纠正、steer、替换目标、暂停、接管、取消；
• Agent 可调查、提出 plan、暴露 tradeoff、请求澄清、主动降级 autonomy、报告异常；
• runtime 可因 policy、预算、验证失败或外部状态变化强制暂停；
• verifier 可否决“完成”，把任务退回 repair。

Agent 是否应该主动打断，可用决策价值近似：

Ask iff:
Expected Loss(acting under current uncertainty)
  - Expected Loss(after answer)
> Cost(interruption + wait + context switch)

更完整时还需加入：答案能否从环境获得、用户是否有能力回答、用户当前是否可用、决策是否可逆、延迟是否放大损失。

2.4 决策点，不是每一步

好的 checkpoint 通常落在：

1. scope 或目标将扩张；
2. 两种策略会形成不同长期架构；
3. 将跨越权限或 trust boundary；
4. 即将产生难逆 effect；
5. 当前证据否定原计划；
6. 验证标准本身需要用户判断；
7. 继续执行的预期返工成本超过打断成本。

When Should Users Check? 将确认建模为 Confirmation–Diagnosis–Correction–Redo（CDCR）的最小时间调度问题；其 48 人 within-subjects 研究中，81% 偏好中间 checkpoint，相比只在末尾确认，任务完成时间下降 13.54%。这证明“全程不问”与“每步都问”之间存在可计算的中间策略；但研究任务和参与者不等同于大型真实代码库，数值不应直接作为 coding-agent 产品目标。

2.5 Proactive pause 的 precision / recall

主动询问也是一个分类器：

• false negative：本应问却没问，造成 scope drift、偏好误判或危险 effect；
• false positive：不必问却打断，造成 approval fatigue、失去 flow；
• 高风险 effect 优先 recall；
• 低风险日常实现优先 precision；
• 阈值应随 effect、reversibility、verifier strength 和用户状态变化。

Morae 在盲人和低视力用户的 UI-agent 场景中主动识别选择点并暂停，报告相比基线更能完成任务并匹配用户偏好。这是 mixed initiative 与 user agency 的一手 HCI 证据，但其可访问性人群、网页任务和 UI agent 情境与 coding agent 不同，只能支持机制方向，不能外推效应量。

3. Autonomy Vector：为什么单一模式必然失真

3.1 Autonomy 的八维表示

定义当前 autonomy state：

A = (
  scope,          可操作哪些资源
  capability,     可调用哪些工具和动作
  effect,         可造成哪一级副作用
  horizon,        可连续运行多久 / 多少 step
  budget,         可消耗多少 token、金额、并发和算力
  initiative,     可自行做哪些决策、何时主动发起
  oversight,      哪些状态必须由人确认或可被人监督
  verification    需要何种证据才可继续、提交或完成
)

任何 manual / yolo / auto 都只是：

Mode = Projection(A, product defaults, organization policy)

因此不能说“这个 Agent 是 autonomous 的”，只能说“它在某 workspace 内对 read/search 高度自治，对 edit 有界自治，对 push/deploy 无自治，在给定预算和 verifier 下可连续运行 N 步”。

3.2 Effect 级别比工具名更重要

同一个 Bash 可以执行 pwd，也可以删除数据；同一个 Write 可以写临时测试，也可以覆盖用户未提交修改。权限需要描述 effect：

判断式不是“这个 tool 危险吗”，而是：

Risk(action) = f(effect severity, blast radius, reversibility,
                 observability, verifier strength, environment,
                 data sensitivity, novelty)

3.3 Reversibility 也不是布尔值

Git revert 只能逆转 repository state，不能让已经触发的部署、通知、migration 或 secret 泄漏回到从未发生。

3.4 动态 autonomy 状态机

状态升级需要多次、条件匹配、可验证的成功；降级应更快。所谓 earned trust 不是让权限只增不减，而是允许系统依据证据在局部上下调节 oversight。

3.5 Autonomy 决策矩阵

3.6 Authority 与 autonomy 的单调安全性

必须保证：

effective_authority(action)
<= explicit_user_authority
∩ organization_policy
∩ environment_capability
∩ current_task_scope

动态学习只能在这个交集内部优化“何时询问”；不能突破 hard deny、敏感资源边界或 effect ceiling。

4. 从 Intake 到 Handoff 的完整交互状态机

4.1 状态，而不是聊天 turn

AwaitingDecision 与 AwaitingEffectApproval 要区分：前者是用户选择方向，后者是授权具体副作用。用户批准 plan 不必然等于批准之后所有高风险 effect。

4.2 用户新消息的五种语义

“用户在 Agent 工作时又发了一句话”不是充分的系统语义。若所有消息都自动 append，紧急纠正会太晚；若所有消息都 interrupt，普通补充会破坏长任务。

4.3 Interruptibility 的四层实现

1. UI 层：Stop 必须与 Send 分离，用户知道当前动作是否可停止。
2. Loop 层：在模型流、工具调度、子任务边界检查 cancellation token。
3. Tool 层：定义 cooperative cancel、grace period、kill 与不可取消动作。
4. Effect 层：取消只表示“不再继续”，不能假设已发出的 effect 未发生；必须 receipt reconciliation。

中断协议：

cancel_requested
  -> stop scheduling new actions
  -> signal in-flight action
  -> wait bounded grace period
  -> kill if tool contract permits
  -> collect partial stdout / diff / external receipt
  -> reconcile world state
  -> persist interruption boundary
  -> present resumable handoff

错误实现是把 user cancel 伪装成 retryable provider error，于是 runtime 自动重试用户刚要求停止的动作。

4.4 Steer 的正确语义

Steer 必须满足：

• 只在明确的 interruptible point 注入；
• 先确认在途 tool 是否已提交 effect；
• 原目标未被替换时，保留仍有效的 acceptance criteria；
• 使新指令成为 journal 中有序事件，而不是偷偷改 system prompt；
• model context、transcript 与 durable state 都能解释方向为何变化；
• 如果 steer 与原硬约束冲突，进入 contract revision，而非 last-message-wins。

4.5 Progress 不是模型叙述

进度展示必须区分：

“已启动测试”不能显示成“验证通过”；“模型说代码已修复”不能显示成“任务完成”。Progress UI 应基于 event reducer，而不是模型自由文本。

5. Preview、Commit 与 Undo：交互中的事务语义

5.1 三阶段 effect protocol

高影响动作应该使用：

Prepare / Preview
  - resolve exact target
  - compute proposed delta
  - run policy and preconditions
  - expose effect, scope, risk, reversibility, evidence

Commit
  - bind approval to immutable action intent
  - execute with idempotency key / expected version
  - persist receipt and observed outcome

Reconcile / Undo
  - compare expected vs actual effect
  - rollback when truly reversible
  - otherwise execute explicit compensating action
  - disclose residual effect

批准对象不能只是“允许 Bash”。应绑定：tool、解析后的目标、关键参数、工作目录、effect class、预览 hash、有效期和一次性 / session scope。

5.2 Preview 需要回答什么

Preview 不是把完整 shell command 塞进一行，也不是生成一段“这是安全的”说辞。

5.3 Commit 必须防 TOCTOU

用户批准预览后，执行前世界可能已变化。Commit 需要：

• expected file hash / git HEAD；
• branch、remote、environment identity；
• policy version 与 credential principal；
• action-intent hash；
• expiration；
• idempotency key；
• precondition recheck。

若 preview 与实际 action 不再相同，授权失效，必须重新 preview 或安全退出。

5.4 “Undo”至少有四种完全不同的含义

如果产品按钮只回退 conversation，却让用户误以为代码也回退，这是高危 trust defect。所有 undo 都必须标明对象、边界和残余 effect。

5.5 Undo 的状态与 effect 分离

Conversation time 与 world time 不同。前者可重写投影，后者只能通过新 effect 改变。

5.6 Recovery point 设计

在重要动作前建立：

• git HEAD、dirty state 与 untracked inventory；
• 文件内容 hash 或 snapshot；
• task contract version；
• pending tool intents；
• process IDs 与 background task IDs；
• external resource versions；
• acceptance evidence 已完成项。

恢复不是“重新让模型读一下聊天记录”，而是从 durable facts 重建状态，核对世界，再规划。

6. Explainability、Evidence 与 Uncertainty

6.1 用户需要可判断性，不需要表演式透明

对于 Coding Agent，用户真正要回答的是：

1. 它理解的目标是什么？
2. 它实际做了什么，而不是打算做什么？
3. 哪些事实支持这次改动？
4. 改动影响哪些边界？
5. 哪些验证通过、失败或未运行？
6. 哪些假设仍未证实？
7. 我能在哪里接管、撤销或继续？

原始 chain-of-thought 既不保证忠实，也会制造信息过载和隐私风险。产品应展示可审计的决策摘要、工具事实、artifact、receipt、关键假设和反事实分支，而非隐藏推理的文学化替代品。

6.2 Evidence hierarchy

回答中应明确：什么结论由哪一级证据支持。例如，“push 成功”由 remote receipt 支持；“修复正确”不能只由 push receipt 支持。

6.3 Evidence Packet

交接时不要只给一段 summary，应输出结构化 evidence packet：

contract_version: 7
outcome: candidate_fix
changed:
  - file: src/auth/state.ts
    reason: make consume atomic
    diff_ref: artifact://diff/42
verified:
  - check: concurrent reproducer
    before: fail 7/100
    after: pass 100/100
    receipt: run_8f31
  - check: auth integration suite
    result: pass
    receipt: ci_local_221
not_verified:
  - production callback latency
assumptions:
  - state store provides compare-and-delete atomicity
external_effects: []
recovery:
  workspace_baseline: git:abc123+dirty-manifest-9

用户首先看到 outcome、风险和未验证项；需要时再 drill down 到 file、test、tool receipt。

6.4 Uncertainty 是向量，不是一个 confidence 百分比

模型自报 “90% confident” 不能直接控制权限；它最多是一个弱 feature，必须与环境事实、历史 calibration、novelty、effect 和 verifier 组合。

6.5 只展示决策相关的不确定性

高质量表达：

已确认：并发 reproducer 的首次错误在 state consume 非原子。
尚未确认：生产存储实现是否提供同样的原子原语。
影响：若不提供，当前 patch 只在测试 backend 有效。
下一步：读取生产 adapter；只读操作，无需新增权限。

低质量表达：

我不是百分之百确定，但应该没问题，请仔细检查。

前者把 uncertainty 连接到 evidence、后果和动作；后者把审查责任无差别转嫁给用户。

6.6 Trace presentation 的反直觉风险

2026 年 Overseeing Agents Without Constant Oversight 做了三组各 n=12 的用户研究。其新界面让参与者更快发现错误（Hedges' g=-0.65），但整体准确率没有实质改善（g=0.18）；更危险的是，在漏掉错误时，参与者对 Agent 正确性的信心反而更高（g=0.85）。参与者常因“过程看起来合理”而过度依赖。

这直接否定了两个朴素假设：

• trace 越多不等于 oversight 越好；
• explanation 越清晰不等于 reliance 越 calibrated。

正确方向是 outcome-first、requirements / assumptions 明示、风险聚合、逐层 drill-down，并专门展示未查到什么、未验证什么、哪些替代路径未探索。

6.7 Review 的三级 zoom

2026 年 Trust-Calibrated Code Review 与 JetBrains 合作，从 17 名行业参与者的发现阶段、7 名回访者的设计阶段和 43 人原型验证调查中提出 overview → file analysis → snippet review 的三级结构，并报告 63% 参与者预期降低总体 review effort、52% 预期降低 trust-assessment effort。它是 participatory design 与原型预期，不是对真实生产缺陷发现率的因果验证；最可取的是“按人分配注意力的粒度组织证据”，而不是把问卷预期当成已实现收益。

7. Trust Calibration：从“信不信”到条件化 reliance

7.1 信任的正确单位是条件切片

错误表述：

我很信这个 Agent。

正确表述：

在 repo X、test-only change、无网络、dirty-state baseline 已记录、
targeted verifier 可用的条件下，它最近 40 个同类任务可靠；
对 auth、migration、push 和部署没有继承这份信任。

Trust state 至少按以下 key 分桶：

(user / team, repository, task family, capability, effect class,
 environment, model+harness version, verifier regime, time window)

过粗会错误迁移信任；过细则永远没有足够样本。系统需要层次化先验与 OOD backoff。

7.2 Trust、Reliance 与 Calibration

设某类决策中：

• Y=1：Agent 建议 / 行动正确；
• R=1：用户选择依赖、批准或接受；
• p：系统对该条件下正确性的校准概率。

重要的不是平均接受率，而是：

Appropriate reliance = P(R=1 | Y=1)
Appropriate rejection = P(R=0 | Y=0)
Over-reliance = P(R=1 | Y=0)
Under-reliance = P(R=0 | Y=1)

若系统输出概率，还可使用 Brier score / ECE 衡量预测 calibration；但用户 reliance calibration 还要衡量信息展示后，人是否能区分正确与错误案例。Agent 正确率 90% 但用户在剩余 10% 也全盘接受，仍是失败的人机系统。

7.3 委派 calibration 与采纳 calibration 是两次不同决策

Human–Agent system 至少有两道 reliance gate：

Delegation: 在还没看到 Agent 输出前，是否让它代表我行动？
Adoption:   已看到 Agent 建议 / 产物后，是否采纳、批准或保留？

两者需要不同的信息。委派依赖任务价值、effect ceiling、历史条件化可靠性、sandbox 与 recovery；采纳依赖当前 artifact、证据、替代方案和 error detectability。不能用“用户最后接受了结果”反推最初委派合理，也不能用“用户不肯委派”推断其看见高质量结果后仍会拒绝。

2026 年 AI, Take the Wheel 在一个合作问答竞赛中研究 23 名 expert human、16 个 AI agent、24 场对局，记录 387 次 delegation 与 1,440 次 adoption 决策。该任务中 human–AI team 胜过单独的人或 Agent，但人仍会错过正确建议，也会在 Agent 误导时采纳；在 human 与 AI 分歧时，模型报告 confidence 对判断谁正确接近 chance。它最有价值的不是具体百分点，而是证明“预先授权”和“看见结果后的采纳”应被分别测量。边界也必须说清：这是小样本、特定问答博弈和 expert participants，不是 Coding Agent 的写入、审批或部署实验，不能据此外推生产 safety 或最佳 autonomy level。

因此 calibration matrix 应分别构建：

Delegation calibration:
  should_delegate × did_delegate

Adoption calibration:
  artifact_correct × did_adopt

End-to-end calibration:
  delegated effect × evidence inspected × final outcome

7.4 造成过度依赖的信号

• 流畅、确定的自然语言；
• 过长但不可核验的行动叙述；
• 把 plan completion 显示为 task completion；
• 用绿色成功态覆盖“部分验证”；
• confidence 没有经验 calibration；
• 用户看到一组通过测试，误以为覆盖所有行为；
• approval 默认按钮与视觉层级诱导接受；
• 长期无事故造成 automation complacency；
• Agent 自己生成 verifier、自己解释、自己打分，形成 correlated evidence。

Automation bias 不应被压成“用户太信 AI”一个标签。至少区分：commission（采纳错误建议）、omission（因 Agent 未提醒而漏做必要动作）、monitoring complacency（长时间正常后减少核查）和 incident 后的 algorithm aversion（把一次显著失败外推到所有切片）。Generative Agent 还多了一层：它会生成连贯解释和动态行动轨迹，使“看起来合理”本身成为 persuasion channel。评测必须分别注入 wrong recommendation、missing alert、long clean streak 和 salient incident；单一 acceptance rate 无法区分这些机制。Overseeing Agents Without Constant Oversight 的小样本结果正说明：更快找到错误与更高 confidence 可以同时发生，因此“用户看了 trace”不是 calibration 的充分条件。

7.5 造成不必要不信任的信号

• 每个 read / grep 都请求 approval；
• 常规可逆操作反复发红色警报；
• 未区分已知风险和泛泛免责声明；
• progress、transcript 与真实状态经常不一致；
• resume 后重复动作或丢失决定；
• 不给 receipt，逼用户重复核对；
• 拒绝 / 失败没有可恢复路径。

不信任也会伤害系统：用户重复劳动、提前接管、忽略真正重要的告警，最终退化成“Agent 生成大量需要人工重做的候选”。

7.6 Earned Trust ledger

信任更新应基于可验证事件，而不是情感标签：

slice:
  repo: kimi-code
  task_family: targeted_test_fix
  effect: E2_workspace_edit
  verifier: targeted+full_suite
observations:
  verified_success: 31
  verifier_failure_caught_before_handoff: 6
  user_rejected_after_pass: 2
  escaped_regression: 1
  rollback: 1
  last_incident_at: 2026-07-28
version:
  model: K3
  harness: 0.31.1

原则：

1. 以最终 outcome / verifier / review 结果更新，不以 approval 更新；
2. 风险加权：一次 escaped destructive incident 可抵消大量低风险成功；
3. 时间衰减：旧模型、旧 harness、旧 repo 状态的证据逐渐失效；
4. 变更检测：模型、tool、policy、repo 架构变化触发 trust reset / backoff；
5. 负证据传播更广、正证据传播更窄；
6. 保留可解释的事件，不只保存一个 opaque score；
7. 用户可查看、纠正、删除 learned preference；hard authority 不由 ledger 学习。

7.7 Dynamic autonomy 决策器

function decide(action, contract, policy, world, trust_ledger):
    assert action.effect <= contract.effect_ceiling
    hard = policy.evaluate(action, world)
    if hard == DENY: return STOP
    if hard == REQUIRE_HUMAN: return ASK

    novelty = distance(action.context, trust_ledger.support)
    reliability = calibrated_success(action.slice)
    verify = verifier_strength(action)
    loss = expected_failure_loss(action)
    recovery = expected_recovery_cost(action)
    attention = expected_interruption_cost(user_state)

    if state_is_uncertain(action) or preview_has_drifted(action):
        return RECONCILE
    if novelty high or verify weak:
        reliability = lower_confidence_bound(reliability)
    if loss * (1 - reliability) + recovery > attention:
        return ASK
    if action.long_running and observable and interruptible:
        return RUN_WITH_MONITORING
    return PROCEED

真正的动态 autonomy 不是让 LLM读历史后自由决定是否询问，而是：hard policy、统计 / 规则策略、模型自我不确定性与 runtime state 分层裁决。

7.8 2026 Hedwig 的贡献与边界

Hedwig 基于 21 名使用 Coding Agent 的软件工程师调查，提出按 repo 持久化的 13 维 feature、online logistic regression 与三档 check-in 决策；并把定量 policy path 与文本 guideline retrieval path 分开。这一架构分离非常重要：偏好文本影响如何做，policy 独立决定是否允许自行做。

但其公开 evaluation 主要是两项 backend task、每个条件单次运行、合成 persona / history、LLM judge，作者也明确称为 illustrative 而非统计结论。它证明了可实现性和架构方向，没有证明 learned autonomy 已在长期真实用户中提升安全或效率。尤其要警惕：

• approval history 可能只是 fatigue，而非 trust；
• model self-confidence 可能未 calibration；
• repo 路径相似不等于语义风险相似；
• 用户偏好变化、组织 policy 变化和团队多人共享如何处理仍开放；
• 一旦把安全权限与个性化 check-in 混合，就可能把“少问我”误学为“替我授权”。

8. Oversight 是贯穿生命周期的四种工作

8.1 四类 oversight

2026 年 Human oversight of agentic systems in practice 访谈 17 名有经验开发者，归纳出四种实际工作：

样本规模小且是探索性访谈，不能告诉我们四种模式的最优比例，但它足以否定“human-in-the-loop = 一个 approval API”。

8.2 Oversight 责任分配

“请仔细 review 所有内容”不是有效的责任分配；系统必须先压缩、分层、标记风险，并完成可自动化的验证。

8.3 Checkpoint scheduling

最优 checkpoint 不只由 step 数决定：

Checkpoint pressure ↑ when:
  accumulated error probability ↑
  downstream redo cost ↑
  effect irreversibility ↑
  user preference impact ↑
  state observability ↓
  verifier strength ↓

Checkpoint pressure ↓ when:
  action is cheap / reversible
  reliable verifier follows immediately
  user interruption cost is high
  task is familiar and policy-bounded

将每个 tool call 都变成人工 gate 只是在低抽象层级实施监督。更好的 gate 落在语义边界：plan fork、scope expansion、effect commit、verification failure、handoff。

8.4 真实使用数据：经验用户更少逐步批准，却更常中断

Anthropic 对数百万交互的第一方分析报告：Claude Code 新用户（少于 50 个 session）约 20% session 使用 full auto-approve，约 750 个 session 后超过 40%；约 10 个 session 的用户在 5% turns 中 interrupt，经验用户约 9%。同一分析中，99.9 分位 turn duration 在 2025-10 至 2026-01 从不足 25 分钟升至超过 45 分钟；median 仍约 45 秒。原始报告

这说明成熟 oversight 可能从 per-action approval 转为 monitor-and-intervene，不能推出“经验越多，越不需要监督”。报告本身的边界也必须保留：单一厂商 / 产品、模型分类器、观察性数据、用户和任务构成变化、turn duration 不等于正确率或安全性。

同一报告对 50 万次 human interruption 和 50 万个 completed turns 的分类显示：Agent 停下最常见原因是提供方案选择（35%）；人中断最常见原因是补充技术上下文或纠正（32%）。这是设计 shared intent 与 steer 的强产品信号，但分类由 Claude 完成，不是人工逐条 ground truth。

8.5 不要把“测试通过”变成人类停止思考的理由

访谈研究发现开发者会把测试结果当保证；但 tests 只对其 oracle 和覆盖范围负责。Post-hoc review 应同时问：

• 测试是不是 Agent 自己为自己写的？
• 是否先证明 reproducer 在修复前失败？
• 是否覆盖 negative case、concurrency、compatibility、side effect？
• 是否有既有测试被删除、弱化或 skip？
• verifier 与被验证代码是否共享同一错误假设？

自动 verifier 的价值是压缩人工注意力，不是替代业务判断。

9. Attention 与 Verification Burden

9.1 人的注意力是系统容量，不是免费 fallback

当 Agent 生成速度超过 review 速度，瓶颈从 generation throughput 转为 verification capacity。人的成本至少包括：

Attention Cost
= time reading status / diff / evidence
+ task switching and re-orientation
+ diagnosing first bad decision
+ reconstructing hidden assumptions
+ correcting and re-running
+ anxiety from unclear state / effect
+ maintaining code comprehension after delegation

所以“同时跑十个 Agent”不是十倍产能；如果十个任务同时在高熵 checkpoint 请求注意，人会成为拥塞点。

9.2 Approval burden 与 verification burden 不同

• Approval burden：在 effect 发生前做 allow / deny 的次数与认知成本；
• Verification burden：判断结果是否满足目标的检查成本；
• Monitoring burden：执行中保持 situation awareness 的成本；
• Recovery burden：错误后定位、接管和恢复的成本。

减少 approval prompts 可能增加 monitoring；减少 monitoring 可能增加 post-hoc review；减少 review 可能增加 escaped failure。必须优化总成本与风险，不是单个指标。

9.3 Progressive disclosure

信息层级建议：

Level 0: 是否需要我？当前风险 / 状态 / ETA
Level 1: outcome、changed、verified、unknown、effect
Level 2: 按文件 / 组件 / 决策点聚合
Level 3: 具体 diff、test output、receipt、timeline
Level 4: 完整原始日志与 debug bundle

默认层级要支持 10 秒内判断“接受、继续调查还是接管”；深层信息要支持 root-cause audit。摘要不能丢掉否定证据和未完成项。

9.4 Notification policy

通知应合并同一任务的低优先级事件，避免多个 Agent 同时制造中断风暴；高优先级通知必须包含可行动选项，而非只有错误文本。

9.5 Review debt

未经审查的 Agent 产物形成 review debt：

Review Debt = unverified artifact complexity
            × probability of hidden defect
            × future cost of reconstruction

大 diff、跨模块修改、低可读性、缺测试和低用户理解会共同增加 debt。Agent 不应通过“先生成再让人看”无限积累债务；应主动限制 diff、按语义分块、先证伪再扩张。

9.6 Comprehension 也是长期指标

2026-07 的在途预印本 (Im)Paired Programming 让 54 名学生用 coding agent 或 chatbot 建网站，报告 Agent 提升初始任务完成，却损害代码理解与随后独立扩展能力；低努力交互和 auto-accepted edits 与更低理解相关，用户仍因快速便利偏好 Agent。它是学生、小样本、特定任务且标明 in-progress，不能外推专业开发生产力；但提示一个重要风险：用户主观满意、短期完成和长期可维护理解可能方向相反。

9.7 生产力自我感知不可靠

METR 2025 RCT 在 16 名熟悉自己成熟开源仓库的开发者、246 个任务上报告 early-2025 AI 工具使完成时间增加 19%，开发者事后仍认为加速约 20%。原研究 已被作者明确标记为对当前模型过时。

METR 2026 更新认为晚 2025 工具很可能更有帮助，但新研究受到拒绝无 AI 条件、任务选择、多 Agent 并行计时等严重 selection effects，作者称数据只为弱证据。方法更新 因此可得出的稳健结论不是“AI 一定减速”或“一定加速”，而是：

• self-reported speed 不能替代真实 task / value / quality measurement；
• 并行 delegation 使传统单任务计时失真；
• 用户会改变任务选择，counterfactual 越来越难构造；
• verification、理解和返工必须进入生产力评价。

9.8 过度依赖也会留下交互行为信号，但不能把相关性当诊断

Behavioral Indicators of Overreliance During Interaction with Conversational Language Models 在 77 名参与者、三类任务中注入看似可信的错误信息，观察到较高 overreliance 与跳过初始理解、直接 copy-paste、反复用 LLM 定位而不细查材料、虽犹豫仍接受错误等行为共同出现；较低 overreliance 则与先理解原始材料、细粒度导航和交叉核对共同出现。

这项研究提供的是相关行为指标，不是可直接部署的因果分类器：样本、任务和错误注入都不是 Coding Agent 的真实长期使用。正确用途是形成研究假设、设计 eval 和改善 evidence UI；错误用途是根据用户鼠标 / 键盘模式秘密给人贴“不会审查”的标签、自动收紧或扩大 authority，或把用户行为当作 Agent 正确性的替代 ground truth。若产品记录这类信号，必须最小化采集、明确目的、支持退出，并验证不同 expertise、accessibility 和工作流下是否有系统性偏差。

10. Coding-Agent 交互矩阵

10.1 按行为设计控制，而不是统一 approval

10.2 五种合作模式

同一任务可以在阶段间切换：调查期 delegated，架构决策期 co-planning，workspace edit 期 bounded，deploy 前 confirm，验证期 exception-based。

10.3 Plan mode 的真正价值和常见误解

Plan mode 有价值时：

• 目标含多个子系统；
• 有架构 fork 或用户偏好；
• effect 高、返工贵；
• completion criteria 需要先对齐；
• 需要明确 non-goals 与变更边界。

Plan mode 无价值时：

• 单步、可逆、反馈即时；
• plan 只是把将要调用的工具展开成清单；
• 计划在读 repo 前生成，建立在猜测上；
• 用户批准 plan 后系统把它误解为所有后续 effect 的授权；
• plan 过期却没有 version / drift 检测。

Plan 是决策与控制 artifact，不是 Agent “认真思考过”的仪式。

10.4 IDE、CLI 与异步任务的交互差异

一个 shared runtime 可以有多个 surface，但交互状态必须有单一事实源；不能让 TUI 认为 stopped、Web 认为 running、daemon 实际仍在执行。

10.5 2026 frontier HAI contract：不是一个聊天框，而是任务控制平面

截至 2026-08-03，公开产品 contract 最完整的方向已经从“同一终端里问答”扩展为：人在不同时间、设备和 attention state 下，对多条独立执行线进行启动、steer、审批、review、handoff 与恢复。它至少包含四个平面：

Task plane:       project / chat / goal / branch / worktree / cloud run
Execution plane:  local host / isolated worktree / hosted VM / external integration
Control plane:    queue / steer / pause / resume / stop / approval / notification
Review plane:     summary / diff scope / inline feedback / stage / revert / PR + CI

OpenAI Codex 与 Claude Code 的 2026 公开规范可作为当前产品 contract breadth 的 frontier 参照：

这两个系统还展示了两类不同的 remote execution：Codex Remote 与 Claude Remote Control 都让手机控制仍在开发机运行的工作；Codex cloud / Claude cloud 则把执行 ownership 移到 hosted environment。两者的 offline、credential、data residency、secret、liveness 和 recovery contract 完全不同，UI 不应只用同一个“远程”标签掩盖。

但以上全部是官方产品规范与工程说明，只证明“公开接口承诺了什么”。它们没有提供随机对照或跨产品 telemetry，不能证明跨设备一定减少 attention cost、parallel session 一定提高净生产力、独立 reviewer 一定提高 defect detection，也不能据此给出产品安全排名。需要 measured effect 时，仍应测 active attention、intervention yield、cross-device takeover latency、parallel conflict / review debt、escaped regression 与恢复完整性。

10.6 Permission / approval 只是 frontier contract 的一个切面

Claude Code 当前文档还暴露了一个关键可靠性边界：对话中的“不要 push”会成为 auto classifier 的阻止信号，但若 compaction 移除了该消息，约束可能丢失；需要硬保证时应使用 durable deny rule。它直接支持本文的原则：自然语言约束是 shared intent，持久 policy 才是 authority boundary。 同一文档说明 bypassPermissions 只适合隔离容器 / VM，且不防 prompt injection；因此“跳过提示”不是 security architecture。

产品正在收敛的不是某个 modal，而是一组独立控制面：

durable policy / declared outputs
  + sandbox / capability restriction
  + independent action review
  + human semantic approval
  + receipts / telemetry / recovery

10.7 Interrupt、Queue、Steer、Side-chat 必须是 typed semantics

所以“有 Stop 按钮”只能证明 surface 有控制入口，不能证明 cancellation correctness。必须为 intent accepted → scheduling stopped → cooperative / forced tool stop → partial-effect reconciliation → terminal receipt 分别定义状态与 latency；而且 stop != rollback，已有 commit、push、message 或外部 API effect 不会因控制流停止自动消失。

10.8 pi：极简但强的 session / steering 基线

pi coding agent 在 2026-08-03 commit c6eb628、package 0.83.0 的公开实现没有追求完整云端 control plane，却把两个最容易含糊的对象做得非常清楚：

1. 消息语义。 工作中按 Enter 排入 steering message，在当前 assistant turn 执行完 tool calls 后送达；Alt+Enter 排入 follow-up，等 Agent 完成全部工作后才送达；Escape abort 并把 queued messages 恢复到 editor；Alt+Up 可取回队列。Steer 与 follow-up 不是靠 prompt 猜测。
2. Session 拓扑。 JSONL entry 用 id / parentId 构成树；/tree 在同一 session file 内跳到历史节点并继续；/fork 从旧 user message 创建新 session；/clone 复制 active branch；compaction 是 lossy context projection，但完整 history 仍在 JSONL，可回树查看。Sessions / format

其极简取舍也写得很直白：core 不内置 permission popup、sub-agent、plan mode 或 background bash；推荐用 container、tmux 或 extension 组合。这不是所有产品都应复制的 feature policy，但它是优秀的 interface lesson：先把 branch、queue、steer、follow-up、abort 的状态语义做窄而确定，再叠加云端、移动端与多 Agent。

pi 同样没有提供这些机制带来更高成功率、理解度或安全性的 measured effect；它也不具备 Codex / Claude 的跨设备审批、hosted tasks、可视 diff 和组织控制 breadth。它是数据模型与控制语义的强 baseline，不是综合产品排名的赢家。

由此得到一个更严格的判断：Kimi 当前公共 TUI / CLI 交互是可靠性分析的重要事实源，但不是 frontier UX 的上界。公共 snapshot 没有确认 Codex / Claude 已公开的完整 cross-device control、isolated parallel-session dashboard、local ↔ worktree / cloud handoff、side-chat 与 repository-level review surface；这里的“未确认”不等于内部或未来不存在，只意味着面试中不能把现有公开实现当作终局。

11. Failure Taxonomy：Human–Agent Interaction 怎样真正失败

11.1 Intent 与 contract failure

11.2 Authority 与 effect failure

11.3 Interaction race failure

11.4 Progress 与 evidence failure

11.5 Trust 与 attention failure

11.6 Handoff 与 recovery failure

11.7 First Bad Decision 的审查法

事故复盘不要停在“模型写错代码”。沿时间线找第一个本可阻止后续损失的错误：

contract 是否欠规格？
  -> Agent 是否应先调查或询问？
    -> policy 是否错误放行？
      -> preview 是否隐藏 effect？
        -> 用户是否有真实机会判断？
          -> commit 是否绑定原 preview？
            -> verifier 是否发现失败？
              -> handoff 是否隐藏未知项？

只有这样才能把失败归到 intent、interaction、policy、runtime、tool、verifier 或 UI，而不是统一归咎于“LLM 不稳定”。

12. Human-Factors Metrics 与 Evaluation

12.1 指标树：从结果到人的状态

12.2 关键指标定义

Verified Task Success
= accepted outcome with required evidence / eligible tasks

Active Attention Ratio
= human active oversight time / end-to-end task duration

Approval Burden
= approvals / semantic effect units
  （不能按 tool call 数跨系统直接比较）

Intervention Yield
= interventions that prevent loss or materially improve outcome
 / all interventions

Check-in Recall
= required human decisions surfaced before commitment
 / all required human decisions

Check-in Precision
= useful human decisions
 / all agent-initiated check-ins

Takeover Latency
= time from user stop / takeover intent
 to no-new-effect + reconciled state

Recovery Completeness
= restored invariants and disclosed residual effects
 / expected recovery obligations

Cross-surface Control Latency
= time from steer / approval / stop on device B
  to ack + visible state convergence on every active surface

Parallel Isolation Violation Rate
= tasks that observe or overwrite another task's uncommitted state
  / concurrently writable tasks

12.3 Trust calibration metrics

先标明决策发生在输出前还是输出后；对有 ground truth 的 review task，可构建：

同时记录：

• 输出前是否委派、当时可见的 reliability / effect / recovery 信息；
• 输出后是否采纳、是否检查 artifact / evidence，以及 delegation 与 adoption 是否发生反转；
• 用户对接受 / 拒绝的 confidence；
• evidence UI 前后 reliance 变化；
• 对不同 failure severity 的发现率；
• calibration 是否只在熟悉任务有效；
• 用户是否因解释的流畅性而改变判断；
• 经历一次 incident 后是否过度降级所有任务的信任。

简单的“trust Likert 分数更高”可能恰恰是坏结果；如果 accuracy 不变而 confidence 上升，就是过度依赖风险。

12.4 交互事件 schema

要评测，先能观测：

event: oversight.checkpoint.resolved
task_id: task_42
contract_version: 7
turn_id: turn_18
action_intent_id: act_91
execution_context_id: worktree_7
surface: mobile_remote          # tui | ide | desktop | web | mobile_remote
checkpoint_type: effect_approval
trigger_source: policy          # policy | agent | verifier | user
delivery_semantics: steer       # append | queue | steer | replace | cancel
effect_class: E3
scope_hash: sha256:...
risk_reasons:
  - remote_write
  - new_branch
decision: approve_once
decision_latency_ms: 8400
preview_opened: true
detail_depth: 2
outcome_link: receipt_301

隐私要求：不要把源码、prompt、secret、绝对路径或个人内容直接放入云 telemetry；使用稳定 ID、枚举原因、去标识聚合。深度 debug bundle 应本地生成、默认脱敏、用户显式分享。

12.5 评测阶梯

Level 1：静态 contract tests

• hard deny 永不被动态 policy 覆盖；
• plan approval 不授予 external effect；
• conversation undo 不声称回滚 code；
• preview hash 漂移导致重新审批；
• cancel 后不再调度新 action；
• unresolved tool intent 在 resume 时先 reconcile。

Level 2：离线 trace replay

• 用历史任务重放 check-in policy；
• 标注 required / unnecessary checkpoint；
• 测试新 UI 是否隐藏 negative evidence；
• 做 counterfactual：若当时更早 ask / stop，会减少多少损失；
• 防止只在老分布拟合 approval pattern。

Level 3：故障注入与对抗场景

• tool timeout 但进程继续；
• push receipt 丢失；
• 用户在 tool commit 边界 steer；
• 多 surface 同时 stop / approve；
• mobile steer 发送后断线、重连并重复投递；
• 两个 parallel session 误用同一 checkout / branch；
• dirty workspace、symlink、branch 漂移；
• verifier false positive；
• malicious tool output 诱导扩大 scope；
• compaction 丢失 non-goal；
• learned preference 与组织 policy 冲突。

Level 4：受控用户研究

• 不只测 task completion；测 error finding、confidence、active time、理解与恢复；
• 向参与者注入已知微小但高影响错误；
• 比较 outcome-first / full trace / summary-only；
• 平衡顺序效应与学习效应；
• 按 task expertise 分层，而非只按职业；
• 观察一人多 Agent 时的 attention collision。

Level 5：长期 field evaluation

• 同一用户跨周 / 月的 autonomy preference drift；
• model / harness upgrade 前后 trust 是否错误继承；
• auto-approval、interrupt、takeover 与 incident 的联合分布；
• local / cloud / remote surface 之间的 control latency、状态分歧与 stale approval；
• parallel task 的 worktree isolation、attention collision 与 cross-session message routing；
• 真实 accepted outcome 与 escaped regression；
• review debt、代码理解和维护成本；
• cohort：novice / expert、new / mature repo、task family、effect class。

12.6 Dynamic autonomy A/B 的正确设计

不能只看 approval 次数下降。至少同时设置：

Primary:
  risk-weighted verified task utility

Efficiency:
  active human time
  semantic check-ins / task
  time-to-handoff

Safety guardrails:
  missed-required-checkpoint rate
  unauthorized / unexpected effect
  rollback / incident severity

Calibration:
  over-reliance / under-reliance
  user confidence vs actual correctness

Longitudinal:
  preference drift
  OOD backoff accuracy
  trust reset after version changes

随机化要避免 policy 学习互相污染：可按 user × repo cluster 或时间窗口设计，并处理 carryover；高风险 effect 不应直接在线探索，应先 shadow mode。

12.7 不能单独使用的虚荣指标

• 平均 session / turn duration；
• auto-approve rate；
• 总 tool calls；
• 生成代码行数；
• 用户自报“节省几倍时间”；
• 中断率（高可能代表主动监督，也可能代表低质量）；
• clarification count（少可能是高效，也可能是盲猜）；
• CSAT 或“信任度”单分；
• model-judged success without artifact evidence。

每个指标都必须结合 task difficulty、effect、user expertise、verifier 和 failure outcome 解读。

12.8 最小 Human-Agent Eval Suite

13. 2025–2026 一手证据地图：结论与证据边界

证据阅读纪律：厂商 telemetry 是高生态效度但低跨产品可迁移、常非因果；小样本 HCI 研究能揭示机制但效应外推有限；benchmark 能重复比较但缺少真实用户和真实后果；产品规范只能确认声明的 contract。以上多项为 arXiv 预印本，版本可能修订；截至复核日，最新直接相关材料包括 2026-07-29 提交且明确标为 in-progress 的 (Im)Paired Programming，因此不把“最新”误写成“证据最强”。

14. Kimi Code 公共实现映射

14.1 证据口径

以下只陈述 MoonshotAI / Kimi Code 公共仓库在 commit e22479a（2026-08-01）可观察到的事实；CLI package version 为 0.31.1。公共代码不能证明线上服务的全部策略、真实用户指标或未来设计，未公开部分标为未知。

14.2 交互机制映射

公共依据：

• Interaction and input
• Keyboard shortcuts
• Built-in tools
• Slash commands
• Sessions and context
• Goals
• Permission gate implementation
• Agent telemetry events

14.3 最值得在面试中讲出的 Kimi 判断

判断一：Kimi 已经把交互问题放进 runtime，而非只放在 chat UI

Permission gate、wire event stream、turn interruption、background task、goal lifecycle、undo checkpoint 都说明交互语义会改变核心状态与执行控制。优秀回答应从 UI event → durable journal → reducer / policy → tool lifecycle → user projection 追完整路径。

判断二：manual / yolo / auto 是必要产品入口，但不是最终 autonomy ontology

面试时不能停在“提供三个模式”。应继续解释：同一模式内仍需按敏感路径、plan exit、tool argument、effect 和 session rule 细分；长期可演进为条件化 vector，但 hard authority 必须独立于 learned preference。

判断三：Kimi 对 conversation undo 的边界说明是正确且重要的

公共文档明确“code changes are not reverted”。这说明不能把用户可见上下文回退与世界 effect 回滚混合。可进一步讨论：IDE 可维护 workspace baseline 来提供 file undo，但它依然不能撤销 push、deploy 或外部消息。

判断四：release notes 本身是一份 Human–Agent race-condition failure corpus

公共 changelog 出现过并修复：中断后 tool result 对齐、later user message 丢失、queued prompt / steer、background task 在 resume 后丢失、Stop 与 Send 分离、auto-approved plan exit 被错误理解为用户执行信号、undo 提示边界等问题。Changelog 这说明 Interaction 不是“做几个按钮”，而是异步持久状态机的可靠性工程。

判断五：公共 Kimi UX 是起点证据，不是行业上界

Kimi 公共实现很好地暴露了 permission gate、wire、goal、background task、queue / steer 和 undo 的 runtime 事实；但 2026 的 frontier HAI contract 已包含跨设备控制、并行隔离 session、local / worktree / cloud execution handoff、side-channel、attention routing 与 repository-level review surface。面试时应先准确评价现状，再把差距描述成控制平面能力轴，而不是说“再加一个 Web UI”或武断声称内部没有这些能力。

14.4 公共证据未能确认的部分

截至该 snapshot，不能仅凭公共代码确认：

• Kimi 是否在线使用长期 user-level trust calibration；
• 是否按真实 verifier outcome 自动升降 autonomy；
• check-in precision / recall、approval fatigue、takeover latency 的内部指标；
• 不同 user expertise / repo maturity 的交互策略是否个性化；
• 线上服务是否有公共仓库之外的独立 risk reviewer 或组织策略层。

面试表达应说“公共实现确认 X；由此可推断设计方向 Y；线上机制 Z 未知”，不要把合理猜测说成事实。

14.5 面向 Kimi 的进一步设计判断

不假设内部尚未实现，只给出判断框架：

1. 先定义 task topology：project → session / goal → turn → action intent → effect receipt，让 CLI、IDE、desktop、web / mobile 只是同一事实源的 projection；
2. 将 queued / steer / replace / cancel / side-channel 作为公共 typed event，明确 delivery boundary、ack、dedupe 与 reconnect 行为；
3. 为 parallel session 提供默认 worktree / sandbox isolation、冲突检测与跨任务 attention scheduler，而不是只允许多开进程；
4. 将 permission mode 展开为用户可理解的 autonomy card：scope、effect ceiling、network、background horizon、verification gate；approval 绑定 immutable action intent，重连 / preview drift 后不复用；
5. 把每个 background / cloud goal 的 return contract 做完整：changed、verified、unknown、residual effects、next decision、recovery point；
6. 建 repository-level review surface，至少有 baseline / last-turn / branch scope、inline feedback、按 hunk accept / reject 与 verifier evidence；不要只展示 Agent 自报 diff；
7. 按 policy-triggered / model-triggered / verifier-triggered / user-triggered 分开观测 check-in；加入 cross-device takeover latency、parallel conflict、review debt 与 notification burst；
8. 动态 autonomy 先 shadow evaluation，hard policy 永远在 learned policy 之外；
9. 用 release-note 中的真实 race、resume、lost-message 与 partial-effect defects 构建 human-agent interaction regression suite。

15. 二十组面试深追问与专家回答框架

1. “你怎么定义 Coding Agent 的 autonomy？”

答题骨架： 先否定单一开关，把 autonomy 定义为在明确 authority 内、无需即时人工决策即可选择和执行动作的条件集合；给出 scope / capability / effect / horizon / budget / initiative / oversight / verification 八维向量。再举例：repo search 高自治、workspace edit 有界、push / deploy 低自治。最后强调 model capability、authority 和 autonomy 三者正交。

追问陷阱： “那 YOLO 不就是高 autonomy 吗？”——YOLO 只是 approval policy 投影；它没有自动说明 scope、effect ceiling、budget、verifier 或外部权限。

2. “为什么不能每个 tool call 都让用户确认？”

答题骨架： per-call gate 粒度低于人的语义判断，导致 approval fatigue；复杂任务 step 越多越不可行。监督应落在 scope expansion、架构 fork、effect commit、verification failure 等 semantic checkpoints。Sandbox 负责技术边界，approval 负责越界决策，二者互补。

证据： Anthropic 观察到经验用户 auto-approve 与 interrupt 同时升高，说明监督从逐步批准迁移为 monitor-and-intervene，不等于取消监督。

3. “Agent 什么时候应该问，什么时候应该自己查？”

答题骨架： 先分类缺口：repo / log 可得事实由 Agent 查；业务偏好、真实目标由用户回答；权限由 policy / principal 决定。用 value-of-information：只有提问减少的预期损失超过中断成本时问。高 effect 偏 recall，低 effect 偏 precision。

追问陷阱： 不要把低模型 confidence 直接等同于问用户；先判断不确定性是否可通过工具消除。

4. “怎样建立 shared intent？”

答题骨架： shared intent 是 outcome、constraints、situation、strategy、completion 五层共同状态，不是复述 prompt。把用户目标编译成 durable task contract，显式记录 non-goals、decision points、acceptance evidence；每次 scope / world state 漂移时更新 contract version。

失败例： 新消息 last-message-wins，导致旧的“不要部署”被覆盖。

5. “Plan mode 的价值是什么？”

答题骨架： plan 的价值是暴露重大决策点、变更边界与完成标准；不是罗列工具调用。复杂、高返工、高 effect 任务需要；单步可逆任务不需要。Plan approval 与 effect approval 必须分离，plan 还要绑定 state version，漂移后失效。

Kimi 映射： Kimi 公共实现支持 plan review / revise 和 1–3 个方案，YOLO 也不自动绕过 plan exit；Auto 则另有语义。

6. “用户在工具执行中发新消息，怎么处理？”

答题骨架： 先区分 append、steer、replace、cancel、side-channel。Steer 在下一个安全中断点注入；先核对在途 tool 的 partial effect；把事件写 journal；保留仍有效 contract；若目标被替换则 supersede old goal 并 reconcile。

状态机要点： 新消息不是普通 chat append；tool receipt 可能与用户指令并发到达，需要全序或可解释的因果顺序。

7. “Interrupt 和 cancel 有什么区别？”

答题骨架： interrupt 是控制流事件，cancel 是用户语义意图；具体动作可能 cooperative stop、强杀或不可取消。收到 cancel 后停止调度新动作、传播 token、收集 partial receipt、核对 world state，最后进入 paused / reconciled，而不是假设所有 effect 回滚。

失败例： 把 user cancel 包装成 retryable error，runtime 自动重试。

8. “怎么做真正可靠的 approval？”

答题骨架： approval 绑定 immutable action intent：principal、tool、resolved target、cwd / environment、critical args、effect class、preview hash、expiry、one-shot / session scope。执行前 recheck HEAD / file hash / policy；有 drift 就重新审批；执行用 idempotency key，完成有 receipt。

追问陷阱： “Approve Bash for session”过粗；需要 argument / effect-aware rules 和 hard sensitive boundaries。

9. “Undo 应该怎样设计？”

答题骨架： 先拆四类：input、conversation、workspace、external compensation。Conversation undo 只改 context projection；code / process / remote effect 不自动回退。UI 必须说清对象与残余 effect。Workspace rollback 保护 pre-existing dirty state；external effect 通常只能 compensation。

Kimi 映射： Kimi /undo 文档明确回退 context / todo / plan，不回退代码，也不能越过最近 compaction。

10. “如何让 progress 可信？”

答题骨架： progress 从 event journal / receipts 投影，分 Intent、Started、Observed、Hypothesis、Verified、Committed、Unknown；不能由模型自由文本决定状态。每条进度带 tool_call / process / artifact / verifier ID，重连后由 replay 恢复。

失败例： “命令已启动”显示成“任务完成”。

11. “应该向用户展示 chain-of-thought 吗？”

答题骨架： 不把原始 CoT 当 control surface；它可能不忠实、冗长、泄露信息并诱导 plausible-process bias。展示决策摘要、requirements、assumptions、action receipts、diff、tests、negative evidence、unexplored alternatives 和 uncertainty。

证据： 2026 oversight 研究显示界面可让用户更快找错，却未提升准确率，还可能提高错误时的 confidence。

12. “怎样表达 uncertainty 才不会既吓人又误导？”

答题骨架： 将 uncertainty 分成 intent、state、epistemic、outcome、policy、provenance、distribution、preference；只展示会改变决策的部分，并连接到 evidence、影响和下一动作。未经经验 calibration 的自报百分比不驱动高风险权限。

高质量句式： “已确认 X；未确认 Y；若 Y 不成立会导致 Z；下一步可用低风险动作 Q 消除。”

13. “Trust calibration 怎么量化？”

答题骨架： 不测“信任更高”，测 appropriate reliance / rejection、over-reliance、under-reliance；有概率则测 Brier / ECE，并测用户 confidence–accuracy gap。按 repo、task family、effect、verifier、model+harness version 分层。

追问陷阱： 接受率高不是好；如果错的也都接受，就是过度依赖。

14. “Earned trust 如何避免学坏？”

答题骨架： 用 verified outcome 而非 approval 更新 ledger；hard authority 不进入学习；risk-weight、time decay、version reset、OOD lower confidence bound；负证据传播更广，升级慢、降级快；用户可审阅和删除 learned preference。

失败例： 用户因 fatigue 连续点允许，系统把它学成永久授权。

15. “Dynamic autonomy 怎么落地？”

答题骨架： 四层：hard organization / security policy → task contract → learned conditional check-in policy → model-initiated uncertainty stop；输出 proceed、run-with-monitoring、ask、reconcile、stop。先 shadow-mode 评估 check-in precision / recall，再在低 effect 上逐步启用。

Hedwig 边界： 可借鉴 policy path 与 preference retrieval 分离；不能把其合成 persona、小任务 demo 当成真实生产有效性的证明。

16. “怎样减少 review burden，又不降低质量？”

答题骨架： 先由 Agent 限制 change surface、生成 semantic diff、运行独立 verifier、聚合 negative evidence；UI 用 outcome → file risk → snippet 三级 zoom；把人分配给业务语义、高风险边界和 verifier coverage，不让人机械扫全量 trace。

指标： active review time、error-finding、over-reliance、escaped regression 同看，不能只测“用户觉得省力”。

17. “人监督多 Agent 时最大的系统问题是什么？”

答题骨架： attention scheduling，而非只看 Agent concurrency。需要跨任务 priority queue、合并通知、deadline / effect severity、每任务 return summary、可暂停 checkpoint；避免十个 Agent 同时把人当同步 API。

指标： notification burst、context switch、decision latency、missed-required-checkpoint、review backlog。

18. “怎么设计 resume / handoff？”

答题骨架： append-only journal + checkpoint reducer；resume 先恢复 contract、goal、decisions、pending intents、receipts、background tasks 和 evidence，再核对 world state。无 receipt 的 intent 先 reconcile，不盲重放。Handoff 输出 changed / verified / unknown / external effects / recovery points。

Kimi 映射： Kimi public sessions 以 per-agent wire.jsonl replay；goal resume 时 active goal 进入 paused，表明 resume 本身是控制状态变化。

19. “怎样评测 Human-Agent Interaction，而不是只测 Agent？”

答题骨架： 五层：contract tests、trace replay、故障注入、受控 user study、长期 field eval。联合测 verified outcome、risk-weighted incidents、active attention、check-in precision / recall、trust calibration、takeover / recovery、comprehension。按 expertise、repo maturity、effect 分层。

追问陷阱： simulated user 可做回归，不足以证明真实用户成本和偏好。

20. “如果你加入 Kimi，Human-Agent Interaction 最值得优先做什么？”

答题骨架： 不直接报功能，先从 trace 找高频高损 cohort。一个高杠杆方向是把已有 permission、steer、goal、undo、wire 机制收敛成统一 typed interaction contract 与 Eval Suite：

1. 明确 append / steer / replace / cancel / side-channel；
2. approval 绑定 action intent 和 state version；
3. 把 goal / session 投影到 CLI、IDE、desktop、web / mobile，同一 task identity 下可 queue、steer、approve、review；
4. parallel task 默认 worktree / sandbox 隔离，并做 attention routing；
5. goal 交付 repository-level evidence packet 和可 inline feedback 的 review surface；
6. 用 changelog 的真实 race / resume failure 建回归；
7. 度量 check-in precision / recall、cross-device takeover latency、parallel conflict、review debt、residual effect disclosure。

最后说明 Codex / Claude 的公开 contract 是竞争参照，pi 是极简语义参照，都不是效果证据；优先级仍必须由 Kimi 内部 failure cohort、用户影响和现有 telemetry 校准，不能仅凭公开代码断言。

16. 一页知识压缩

16.1 十条不可退让的原则

1. Interaction 是控制协议，不是 transcript 美化。
2. 能力、权限、自治、可信度、信任是五个对象。
3. 自治是条件向量，产品模式只是投影。
4. 用户可以委派动作选择，不能无意中委派责任与未知权限。
5. Shared intent 要落到 durable contract、non-goals 与 acceptance evidence。
6. Ask / act 由信息价值、effect、reversibility 和 attention cost 联合决定。
7. Progress 由 receipts 和 reducer 生成，不由模型叙述生成。
8. Preview、commit、reconcile / compensate 是 effect 的基本事务协议。
9. Explanation 不是 evidence；合理过程甚至可能放大过度依赖。
10. 动态 autonomy 的升级慢、条件窄、可撤销；降级快；hard policy 永不学习。

16.2 面试白板最小图

16.3 终极回答句式

我不会把 autonomy 设计成一个全局开关。先把用户委派编译为含 scope、effect ceiling、acceptance evidence 和 escalation 的 contract；runtime 用 hard policy 截断 authority，再按 action novelty、effect、reversibility、verifier strength 和条件化 reliability 决定 proceed、monitor、ask、reconcile 或 stop。用户看到的不是模型自述，而是 plan decision points、tool receipts、diff、验证与未知项。所有 steer、cancel、approval 和 effect 都进入 durable journal；resume 先 reconcile，undo 明确区分 context 与 world。最终优化的是 risk-weighted verified utility，约束项是人的 active attention、over-reliance、missed checkpoint 与 recovery completeness，而不是单纯追求更长无人运行时间。

17. 一手资料索引

Human oversight、checkpoint 与 review

• Human oversight of agentic systems in practice
• Overseeing Agents Without Constant Oversight
• When Should Users Check?
• Trust-Calibrated Code Review
• Magentic-UI
• Morae

Dynamic autonomy、clarification 与 delegation

• Hedwig: Dynamic Autonomy for Coding Agents
• Ask or Assume?
• Intelligent AI Delegation
• AI, Take the Wheel: Delegation and Trust in Cooperative QA

真实使用、理解与生产力

• Anthropic: Measuring AI agent autonomy in practice
• Anthropic: Agentic coding and persistent returns to expertise
• Anthropic: Trustworthy agents in practice
• OpenAI: Running Codex safely at OpenAI
• Behavioral Indicators of Overreliance
• METR: Early-2025 developer productivity RCT
• METR: 2026 experiment-design update
• (Im)Paired Programming

当前产品控制、parallel work 与 review contract（按 2026-08-03 快照）

• OpenAI: Mastering remote engineering work from your phone
• OpenAI Codex: Long-running work
• OpenAI Codex: Worktrees
• OpenAI Codex: Cloud tasks
• OpenAI Codex: Code review
• Claude Code: Configure permissions
• Claude Code: Choose a permission mode
• Claude Code: How Claude Code works
• Claude Code: Remote Control
• Claude Code: Desktop
• Claude Code on the web / cloud sessions
• GitHub: About agentic workflows
• GitHub: Review output from Copilot
• GitHub: Manage and track Copilot agent sessions
• GitHub: Steer Copilot CLI
• OpenAI Codex Python SDK API
• OpenAI Codex app-server protocol
• pi coding agent 0.83.0 at c6eb628
• pi sessions
• pi session file format

Kimi / Moonshot 公共实现

• Kimi Code repository
• Interaction and input
• Sessions and context
• Permission gate

知识更新方法：先用公共代码确认机制，再用 field telemetry 观察真实行为，用 HCI 研究解释人类限制，用 trace / incident / eval 验证本产品结论；始终区分事实、推断、设计建议和未知。