Human in the End：重新思考我们与 AI Agent 的交互方式

Read in English

我最近一直在花时间构建一个新的 Agent 运行时，我叫它 Alan。Alan 用 Rust 实现，核心思路是把 AI Agent 建模为图灵机——无状态的程序在有状态的纸带上执行，产生可观测的副作用。

但越深入运行时设计，我就越频繁地撞上同一个问题：人类在这个系统里到底扮演什么角色？

行业给出的标准答案是「Human-in-the-Loop」。在每个关键决策点放一个人类。让他们审批工具调用、审阅输出、确认操作。安全、负责。但 Anthropic 最近发布的一项研究揭示了一个有趣的现实：Claude Code 用户中，新用户约 20% 的会话使用完全自动审批模式；而当使用超过 750 次后，这个比例飙升到 40% 以上。与此同时，最长运行的 Agent 会话时长从 2025 年 10 月的不到 25 分钟，翻倍增长到 2026 年 1 月的超过 45 分钟。

用户正在用脚投票：他们越来越信任 Agent，越来越不想逐步审批。

这篇文章想聊的是：为什么我认为我们需要一个不同的模型——我称之为 Human-in-the-End——以及它对 Agent 架构到底意味着什么。

无法扩展的循环

Human-in-the-Loop（HITL）是 AI 安全领域的共识模式。思路很直接：AI 提议，人类决定。Agent 执行任何有风险的操作之前，暂停，等待审批。

实践中，这有三种常见形态：

• 审批节点 — Agent 在预定义的检查点暂停（LangGraph 式工作流的典型做法）
• 审核队列 — 任务进入 Inbox，等待人工批量处理
• 工具提权 — Agent 在调用危险操作时请求提升权限（Claude Code 就是这么做的）

这套机制是有效的。在短时间的交互式会话中，人类主动盯着屏幕，它运作得很好。人类能捕获幻觉、阻止破坏性操作、实时纠偏。

但问题是：Agent 正在变得越来越强。它们能规划多步任务、反思自身输出、重试失败的方案、在长执行链中维持上下文。趋势很清晰——Agent 正在从「回答我的问题」走向「完成我的项目」。

而这恰恰是 HITL 崩溃的地方。

当 Agent 连续运行数小时——调研、编码、测试、迭代——审批模式会制造三个相互叠加的问题：

审批疲劳。 人类点了太多次「approve」，以至于不再真正阅读审批内容。安全机制沦为形式。这不是假设——有人专门写了一篇《The Unsupervised Agent Problem》来描述这个现象：「你的注意力已经漂移了……你在自动驾驶模式下批准了一个本该仔细看的操作。」Anthropic 的数据也印证了这一点：经验丰富的 Claude Code 用户中，超过 40% 选择了完全自动审批。

带宽天花板。 每次审批都是对人类的同步阻塞调用。Agent 的并发能力被人类的注意力带宽锁死。OpenAI 内部的 Harness Engineering 团队报告了一个极端案例：他们经常看到单次 Codex 运行持续超过 6 小时——通常是在人类睡觉的时候。如果每一步都要审批，这种长时间自主运行根本不可能发生。

角色错配。 人类被迫评估低层级的执行细节（这个文件该不该写？这条命令该不该跑？），而他们真正的价值在于高层级的判断（方向对不对？结果达标了吗？）。Harness 团队的实践给出了一个更好的答案：他们将人类审查逐步让位给 agent-to-agent review，人类只在「需要判断时」才介入。三名工程师用五个月时间驱动 Codex 完成了约 1,500 个 PR、近百万行代码——没有一行是人类手写的。

讽刺的是：Agent 越强，逐步监督就越没有意义。这就像雇了一个资深工程师，然后站在他身后审批每一次按键。

「Human in the End」到底是什么意思

「Human-in-the-End」这个说法是故意有挑衅性的。它被设计来与 HITL 形成直觉对比——从「每一步都要 approve」到「只看最终结果」。但如果你按字面意思理解，它会产生误导。

人类并不是真的消失到最后才出现。在任何真实系统中，人类在三个阶段都在场：

• Before（任务之前）： 定义目标、设定约束、建立策略、划定不可逆操作的红线
• During（运行期间）： 策略持续生效，异常触发回调
• End（结果交付）： 审阅最终产出，承担问责

人类不参与的是 execution——那些日常的、可逆的、在策略边界内的过程性操作，占 Agent 工作量的 95%。

所以真正的变化不在于人类「出现在哪里」，而在于人类「承担什么角色」：

	HITL	HITE
人类角色	操作者（Operator）	拥有者（Owner）
关注点	执行细节	目标与结果
介入方式	逐步审批	基于异常的介入
Agent 定位	被监督的工具	被委托的自治执行体

核心公式是：Human Defines → Agent Executes → Human Owns。

这不是纯理论。OpenAI 的 Harness 团队在实践中已经验证了这个模型——他们的核心原则就是「人类掌舵，智能体执行」。人类定义目标和约束，Agent 端到端地完成从编码到测试到部署的全流程，只在需要判断时升级给人类。

1. Human Defines。 设定目标、预算、风控策略和硬边界。定规则，而非盯过程。
2. Agent Executes。 Agent 在沙盒边界内自主处理所有过程性工作——规划、执行、反思、重试。正常流程完全静默运作。
3. Human Owns。 人类最终为结果承担责任。系统仅在触碰策略边界时才升级——超预算、触发高危操作、检测到异常偏离。这就是基于异常的人类介入（Exception-Driven Human Oversight）。

为什么人类永远不会完全消失

我想把这一点说清楚，因为 HITE 很容易被误读为「完全自主的 AI，不需要人类」。这不是我的论点。

人类不可替代的原因不是技术局限，而是结构性的：

法律责任。 如果 Agent 签了一份有问题的合同或者把有 bug 的代码推到生产环境，承担法律和职业后果的是人类。系统中必须始终存在一个可问责的人——只是不需要在每一步都出现。

战略判断。 AI 可以优化（optimize），但不能定义目的（define purpose）。「我们要不要进入这个市场？」不是优化问题。它是一个涉及风险偏好、文化和品牌的判断——这些东西无法被概率分布捕获。

不可量化的价值。 长期关系、信任网络、行业直觉。这些以模型无法复制的方式影响着决策。

HITE 把人类从执行监督的琐碎中解放出来，让他们专注于真正需要人类判断力的事情：目标设定与结果问责。

从哲学到架构

理念不值钱。难的是把它落地为运行时语义。

我一直在 Alan 中推演这个问题。Alan 把 Agent 建模为图灵机：无状态的程序（AgentConfig）在有状态的纸带（Tape）上执行，产生持久化记录在 Rollout 日志中的副作用。三层清晰的抽象：

AgentConfig  →  "how to think"   (无状态：LLM + 工具 + 策略)
Workspace    →  "who I am"       (持久身份：人格 + 记忆 + 技能)
Session      →  "what I'm doing" (有界执行：纸带 + 轮次 + 执行日志)

Alan 已经具备了基础——无状态 Agent / 有状态 Workspace / 有界 Session 的解耦，加上 rollback、replay、approval、sandbox 等原语。但要让 HITE 从理念变成运行时行为，还需要四件事。

提交边界与策略即代码

如果 HITE 有任何具体含义，那就是：大多数 Agent 操作应该自由流转，人类介入应该被收敛到提交边界（Commit Boundaries）——那些真实世界后果开始生效的不可逆检查点。

传统审批流把拦截绑定在特定的工具调用上。这太死板了。在自治系统中，读取文件、运行本地计算、尝试一个可能失败的方案——这些都应该放行。人类的注意力应该被保留给真正重要的时刻：签署合同、转账、push 到生产分支。

这些边界需要被定义为声明式的 Policy-as-Code：

• 动态风险评估。 拦截的触发基于上下文而非单个动作——Agent 是否越权？支出是否逼近预算水位线？代码变更规模是否异常？
• 异常作为一等公民。 自治 Agent 的核心能力不在于正常时跑多快，而在于异常时降级得多优雅。正常操作静默运行；只有策略违规或异常偏离才升级给人类 Owner。

用图灵机的语言来说：提交边界就是纸带上的特殊符号。当读写头遇到它时，状态转移函数不再由 LLM 独立决定，而是 yield 给人类，等待人类写入决策后再 resume。这与 Alan 已有的 Yield/Resume 协议对称结构天然契合。

Task/Job：跨越上下文窗口

Session 受限于 LLM 的上下文窗口。对于单次对话来说这没问题，但真实世界的 Agent 任务——「重构这个模块」「排查并修复这个生产问题」「调研竞品并写一份报告」——可能跨越数小时甚至数天。

这需要在 Session 之上新增一层抽象：

• Task/Job — 业务最高层实体，携带全生命周期的目标、SLA、资源硬约束和 Owner 身份
• Run — 一次任务执行，支持跨天轮转、自动重试、指数回退调度
• Session — 退化为单次计算窗口，图灵机的一段有限纸带

核心难题是连续性。当新 Session 接手一个 Task 时，它需要足够的上下文来继续推进，而不是从头推导。这意味着需要结构化的交接产物——不是「这是对话历史」，而是「这是当前状态、已尝试的方案、剩余的工作」。

这个分层与 HITE 公式映射：Task 承载 Human Defines（目标与约束），Run/Session 承载 Agent Executes（自治执行），Task 的最终状态交付给 Human Owns（结果问责）。

Checkpointed Reasoning 作为信任基础设施

Alan 已经把每一步思考、动作和观察都持久化记录在 Rollout 日志中——我称之为 Checkpointed Reasoning。但要让 HITE 真正运作——让人类真正放心地「不盯过程」——Rollout 需要从展示型日志进化为可验证的证据链：

• 幂等性。 每个工具调用携带幂等键（Idempotency Key）。引擎层拦截有副作用的请求以保证安全重放。
• 溯源审计链。 最终产出附带防篡改的溯源信息——每一步处理被哪项策略放行，参考了哪些源头数据。这消除了「我必须盯着每一步」的焦虑。

人类之所以敢放手，不是因为盲目信任 Agent，而是因为任何时候都可以回溯完整的决策链条。Checkpointed Reasoning 从「技术特性」升格为「信任基础设施」。

Skills over Plugins：Unix 哲学

在 HITE 范式下，Agent 需要在长时间内自主编排大量工具。工具编排的架构选择直接决定了系统的可控性和可维护性。

当前行业趋势倾向于围绕 MCP（Model Context Protocol）构建 Agent。但 MCP 的设计违背了 Unix 哲学的核心——「一个程序只做一件事，并把它做好」以及「程序之间通过文本流通信」。它引入了重型的 Client/Server 架构、握手协议和状态维护机制。为了让 Agent 使用一个简单的工具，你必须把它包装成 RPC 服务器。

OpenAI 自己也踩了这个坑。在构建 Codex 的 App Server 时，他们最初尝试把 Codex 作为 MCP 服务器发布，但很快发现「难以维护 MCP 语义」，最终转向了自己的 JSON-RPC 协议。当你需要支持丰富的 Agent 交互——线程生命周期、流式进度、审批中断——MCP 的抽象层级就不够用了。

Alan 选择了一条不同的路径：Skills over Plugins。

• 微型 CLI 工具。 开发者用最顺手的语言写命令行工具。从 stdin 读取，向 stdout 输出。没有 Server，没有协议负担。
• Skills 作为管道。 Markdown 格式的 Skills 用自然语言将孤立的 CLI 工具串联起来——像 Unix 管道，但由 Agent 阅读流程说明书来编排。

在这种架构中，MCP 和 OpenAPI 只是众多原子执行器中的一种。Skills 才是编排层——逻辑控制器。

这解决了真实的工程痛点：上下文隔离（模型只加载当前 Skill，而非所有工具 Schema）、组合确定性（Skill 定义了显式的数据流转路径）、鉴权解耦（每个工具自己管理认证状态）、开发者主权（写一个 CLI + 一个 SKILL.md，不需要常驻 Server）。

更新（2026 年 3 月 2 日）

今天我在 Hacker News 上看到 Eric Holmes 的文章：MCP is dead. Long live the CLI。其中一句话和上面的判断高度一致：“The best tools are the ones that work for both humans and machines.”

这也印证了上面「Skills over Plugins」的观点。在 Alan 里，Skills 仍然是编排层，底层执行默认优先走小型 CLI 工具。MCP 和 OpenAPI 依然有价值，但更适合作为按需接入的适配器，而不是唯一入口。这样在组合性、可调试性和权限边界上都更清晰。