让 AI 改一段文案，满意就保存。让它把文案发给客户，这两件事可能从同一个聊天框、同一句指令开始。第一种错误大多留在草稿里，第二种错误已经到了别人的收件箱。

界面同样流畅，后果隔着一个系统边界。

聊天框让操作变得简单，也容易把这种差别压平。用户看见的都是输入一句话、等待回复，工具背后可能已经在读文件，也可能改内容、运行命令，甚至准备调用外部系统。只看回答自然不自然，已经无法判断一项工作能不能放心交出去。

本文把这些机制合称为"控制面"，包括权限和批准，也包括中断、过程记录和结果验证，以及检查点与人工接管。这是一个方便讨论的概括，并非某家厂商的正式分类。聊天框可以继续当入口，控制面决定工具能走多远。

会行动之后，谁来限制行动

Claude Code 提供了一个现成例子。Anthropic 官方文档把它描述为可以读取代码库、编辑文件，还能运行命令并接入开发工具的编程 Agent。官方所说的 Agent 循环包含三个环节：收集上下文，然后采取行动并验证结果。工具调用的结果还会进入下一步，影响后续动作。

进入这个循环后，模型会根据环境反馈继续处理任务。用户也在循环里，可以中断当前执行、补充信息或者改变方向。AI 从给建议走进了执行环境。

行动范围需要由谁来限制？

Claude Code 的官方资料对只读操作、命令执行和文件修改，以及网页访问分别处理，并支持允许、询问和拒绝等权限规则。这些规则由产品层执行，不靠模型临时记住一句提醒。提示词表达用户意图，权限系统画出硬边界，两者承担不同责任。

近期中文讨论中，Claude Code 和 Codex 都常被当作编程 Agent 的代表名称。截至 2026 年 10 月 9 日，本文没有取得可核验的 OpenAI 官方材料，因此不讨论 Codex 的当前功能、权限和沙箱，以及自动化或回退能力，也不做两者横评。

可以确定的变化是，AI 工具正在从回答问题进入执行环境。评估标准也要从"回答得好不好"延伸到"行动如何受控"。

文件能恢复，远程后果可能收不回来

"可回退"这个词经常说得太宽。

Anthropic 的官方说明给 Claude Code 划了一条清楚的边界：文件检查点可以恢复文件编辑，但数据库、API 和部署等远程副作用不在这个恢复范围内。

如果 Agent 改错了一份本地文档或代码文件，检查点保存的是文件状态。用户可以查看差异，发现问题后恢复文件。这个过程仍然需要人判断改动对不对，但至少有一个明确的返回点。

动作离开文件系统后，情况就变了。消息已经发出，收件人可能已经看见。表单提交后，后端流程可能开始运行。部署请求进入远程平台，新的服务状态已经产生。删除、付款或其他不可逆的 API 动作，还可能继续触发下游流程。本地文件即使回到旧版本，这些外部后果也不会跟着消失。

这些例子只用于解释"副作用"的范围，不代表 Claude Code 原生完成了上面所有动作。工具改变了自身工作区之外的状态，恢复责任也跨出了文件检查点的边界。

暂停同样有范围。用户可以中断 Agent 当前进行的过程，已经提交到外部系统的请求却未必会撤销。一个动作如果在中断前生效，后续只能依靠目标系统自己的撤销、补偿或人工处置机制。目标系统没有这些能力时，叫停只能阻止下一步，无法擦掉上一步。

人工确认需要放在副作用发生之前。读取资料、整理内容和生成草稿通常可以先自动执行。文件编辑适合保留差异，再由人审查。发送和提交、部署和删除，以及付款或其他难以逆转的动作，应在放行前确认对象、范围和结果。

日志、暂停按钮和检查点也不能保证结果正确。过程记录可能不完整，检查点只覆盖部分状态，人工同样可能误批。控制面能缩小错误影响，给人留下发现和接管的机会，它无法消灭风险。

Jev 创始人的主张，尚缺独立验证

Jev 创始人 Diogo Almeida 主张，用 RLCD 让模型输出可供代码消费的选择、评分和概率，再由开发者按置信阈值决定自动执行，或者把任务交给人工。

这个思路触及了聊天界面的一个局限。模型在自然语言里说"应该可以"，程序很难据此决定是否放行。如果不确定性能够成为结构化信号，工作流就有机会设置明确的接管点。

现有证据无法支持更强的结论。本次研究取得的是对创始人访谈的编译材料，没有定位到 Jev 或 TypeSafe 的官方技术页面，也没有校准数据、失败样本和独立评测。Diogo Almeida 同时是产品利益相关方。他对 RLCD 的解释和对其他工具的判断，都应视为 Jev 创始人的主张，置信度较低，不能当作已经验证的行业结论。

概率不会自己变成可靠性。概率需要经过可信校准，阈值也要与错误代价匹配。结构化输出和确定性业务规则、自动测试和权限限制，再加上人工审批，同样可以组成控制系统。RLCD 由 Jev 创始人提出，目前缺少独立验证，值得继续观察，但现阶段没有证据证明它是唯一答案。

为了理解这些讨论，可以把对话助手、编程 Agent 和工作流 Agent，加上概率化决策接口，粗略看成四种接口。这个框架不是厂商标准，也不是固定的升级路线。它们可以重叠、组合。聊天框让人表达意图，程序接口传递约束，权限系统限制动作，人工在关键位置接管。

选工具前，先看一次错误的代价

普通读者没有必要先研究整套 Agent 架构。拿出一项准备交给 AI 的具体工作，连续问五件事：结果能否验收，动作有没有外部副作用，权限能否收窄，过程能否观察和叫停，失败后能恢复到哪里。

验收标准越明确，任务越容易提高自动化程度。格式与差异、测试结果或可核对事实都能成为检查依据。文案"读起来不错"、方案"感觉合理"仍需要人判断。结果难以验证时，长链路执行更容易积累错误。

副作用和恢复范围需要多看一层。读取、整理和草拟通常容易收回。外发和提交会让错误越过个人工作区。文件检查点恢复的是文件，目标系统的撤销机制处理的是目标系统状态，现实世界的后果往往还需要沟通和补救。

权限范围也应跟任务走。工具只需要读取一个目录，就没有理由获得更多写入权限；只需要生成草稿，就不必直接拿到发布能力。权限收窄后，即使模型判断失误，影响也会受到限制。

过程还要看得见。用户至少要知道工具正在调用什么、改动什么，异常时能否暂停并补充信息。不过，过程可见只能帮助发现问题，不能替代结果验收。日志里出现了一个动作，也不代表动作符合业务要求。

这五个判断不需要平均打分。任务有明显的外部副作用，或者失败后无法恢复，仅这两项就足以提高人工确认门槛。任务只有在结果可自动验证，权限能够收窄，过程可观察，并且失败也容易恢复时，才适合逐步增加自动执行范围。

聊天界面仍然适合一次性、低风险且容易检查的工作。为了简单任务搭建复杂编排，可能只会增加维护成本。等到 AI 开始修改环境、连接系统和触发真实动作，前端体验只能回答"好不好用"，回答不了"出了问题怎么办"。

你现在准备交给 AI 的那项工作，做错一次会影响谁，错误发生后又能恢复到哪一步？