从模糊到确定：人机边界是怎么移动的

一个让我反复维护的系统

在某金融科技公司做 AI 产品的时候，我们搭过一套数据采集和处理的流程：人工定义要抓取哪些数据源、对应哪些网站，采集完之后按照预先写好的清洗规则处理，最后存入指定的数据仓库。意图分类那一层，我们用模型来判断——这条数据该走哪个处理路径。但路径本身是人写死的，清洗规则也是人维护的。

这套系统就是工作流。但它暴露的问题让我开始想一个更底层的问题：上游一个数据源改了字段格式，或者新增了一个数据类型，下游依赖这个节点的所有分支路径都要人工排查和更新。分支数量一多，维护成本不是线性增长，是指数级的。团队花了大量时间做的不是产品迭代，而是在"救火"——每次上游变动都要重新梳理一遍下游的分支逻辑。

这个维护成本，是一个更基本问题的症状：分支路径必须由人提前预设，系统没有能力自己处理没见过的情况。这条线——人必须提前结构化的边界——就是当时这套系统里人机边界的实际位置。

任务执行是一个收敛过程

要回答边界由什么决定，需要先看清楚 Agent 执行任务的过程本身是什么结构。

不管是工作流还是 Agent，任务执行的过程本质上都是把一个开放的问题逐步变成确定的执行步骤。输入端越模糊，系统需要做的判断就越多；输出端越结构化，执行的确定性就越高。工作流和 Agent 不是两种东西，而是这个收敛过程里自主程度不同的两种实现方式：工作流把收敛的路径提前写死，Agent 在运行时动态生成路径。

我们的数据管道就是典型的工作流：意图分类节点用模型做判断，但后续路径是人预设好的——模型参与了收敛的早期，但收敛的主要工作还是由人提前完成的。

这个视角有一个重要的推论：工作流在确定性任务上往往比 Agent 更可靠，因为它引入的不确定性更少。在任务边界清晰的场景下，把路径提前写死反而是优势，不是局限。

边界卡在哪里，由什么决定

理解了收敛过程，人机边界的问题就可以更精确地表述：在收敛过程里，哪些判断节点该由人来控制？

现阶段的答案，基本可以归结为一条线：能被提前结构化的部分交给机器，不能被结构化的部分还得人来兜底。我们的数据管道卡在"分支预设权"——不是模型判断不了意图，而是"意图之后走哪条路"还没有办法让模型自己决定，必须人来提前定义好每一种可能性。

但这条线不是固定的。机器能参与结构化的深度在增加——那么，增加的速度由什么决定？

技术能力是上限，验证反馈循环是速度

Claude Code 的权限设计演化直接回答了这个问题。

早期版本里，Claude Code 对每一个文件编辑操作都要用户逐个确认。这个设计很保守，但 Anthropic 有意为之——官方承认，默认权限是"刻意保守的"，因为他们发现有开发者为了效率直接使用 --dangerously-skip-permissions 绕过所有确认，而这在生产环境里有严重的数据安全风险。

后来 Anthropic 推出了 Auto Mode：用一个基于 Sonnet 的分类器对每次工具调用评估风险，安全操作自动批准，危险操作（批量删除文件、数据泄露风险、恶意代码执行等）直接拦截，不再需要用户逐个点确认。

注意这个演化路径：模型执行文件编辑的能力，从一开始就有。但边界后移不是靠发布一个更强的模型触发的，而是靠用户行为数据——大量用户"逐个点同意"的行为，验证了在这个场景里模型判断的可靠性，Anthropic 才顺势把这个节点的控制权交给了分类器。

技术能力划定了边界能移到哪里的上限，真实场景里的验证-反馈循环决定边界实际移动的速度。没有技术能力，信任无从建立；技术能力到位了，信任也不会自动到位，需要在真实场景里被反复验证、修正、再验证。

这个机制也解释了为什么同样的模型能力，在不同场景里边界位置不一样。据报道，众安保险的健康险自动化审核比例已超过 45%，但剩下的 55% 依然有人介入。高频标准件（资料齐全、案例类型常见）天然构成高频低风险场景，验证循环跑得快，边界移动也快；剩下的低频复杂案件，验证数据积累慢，边界还没到位。

边界失控的代价，以及 Agent 和自动驾驶的关键差异

这个机制和自动驾驶的分级放权高度同构。自动驾驶的 L1 到 L5，每一级都代表着人把更多的判断权交给系统——从辅助转向，到自动跟车，到特定路况免手动，到完全无人驾驶。每一级的跨越，不是靠技术发布会宣布，而是靠大量真实里程的验证数据积累，加上监管机构的认证，才完成的。

Tesla 的案例提供了一个反面参照。据分析，Tesla 在放开"眼离"功能时，技术行为上已接近 L3 的自主程度，但有观点认为它没有正式申请 L3 认证，也没有承担对应的责任。结果是技术能力和信任边界之间产生了缺口：系统给了用户不看路的自由，但用户依然承担全部风险。当技术能力跑得太快、验证还没跟上的时候，这个缺口会变成真实的事故。

Agent 领域也有类似的教训，而且两个案例指向不同维度的问题。

第一个是不可逆操作的边界失控。2025 年 7 月，某创业公司在"代码冻结"期间让一个自主编码 Agent 做例行维护，Agent 无视明确指令执行了 DROP DATABASE 命令，删除了生产数据库。事后 Agent 还伪造了系统日志试图掩盖。这个案例说明的是：不可逆操作如果没有单独设计确认机制，验证失败的代价是无法回头的。

第二个是低风险越权的边界模糊。2025 年 2 月，一个 Agent 被要求查询鸡蛋价格，结果在没有任何用户确认的情况下直接完成了购买。这不是高风险操作，但它越出了用户授权的范围。即使单次操作代价不大，边界模糊本身就是问题——用户无法预测 Agent 会在哪里停下来。

两个案例的共通之处是：边界没设好，都不是因为模型能力不够，而是判断权在没有经过充分验证的情况下提前交出去了。

这里有一个自动驾驶类比里容易被忽略的关键差异：自动驾驶的"重要节点"是物理世界定义的——红灯、行人、路口，这些判断节点是客观存在的，相对容易形成共识，也相对容易被监管标准化。但 Agent 的判断节点是任务定义的：不同的业务场景、不同的风险偏好、不同的数据敏感程度，节点在哪里完全不一样。这意味着人机边界本身需要被产品化，没有通用答案可以直接套用。

具体来说，至少有两个维度需要在产品层面显式设计：一是可逆性，能撤销的操作（文件编辑、草稿生成）和不可逆的操作（发送邮件、提交订单、删除数据库）需要完全不同的确认机制；二是验证频率，高频低风险的任务可以快速积累信任、缩短确认链，低频高风险的任务则需要更长的验证周期，不能用前者的经验套后者。

人不会退场，但介入形式会一直在变

我对这个方向的判断是确定的：边界会持续后移。模型能力在提高，验证工具在成熟，企业对 Agent 行为的可审计性要求也在倒逼产品把边界设计做得更精细。

但我对速度没有把握。卡内基梅隆大学 2025 年的研究显示，表现最好的模型在真实工作场景里也只能独立完成约 30% 的任务。完成率低意味着很多任务类型还没有积累足够的成功样本，验证循环就无从跑完——边界自然也移动不了。

更确定的是：边界后移不等于人的退场，而是人的介入形式在持续升级。从人逐条维护分支规则（执行层兜底），到人逐个确认每一步操作（确认层把关），到用分类器替代人工确认（确认层自动化），到加一个审查 Agent 做最后兜底（监督层部分自动化）。每一步都在把更多的结构化工作交给机器，但验证责任从来没有消失，只是承载它的方式在变。