从 AI Agent 到可控系统：一次工程实践中的范式转移

这两年，Agent 成了 AI 工程领域讨论最多的概念之一。

自动规划、自动执行、自动调用工具，看起来非常“工程友好”。
但如果你真的把 Agent 放进长流程、可回溯、需要负责的系统里，很快会遇到一个现实问题：

Agent 很难稳定跑完整个流程。

而且不是偶尔出错，是结构性不稳定。

一、Agent 在 Demo 里很好，在工程里却很“飘”

在 Demo 场景中，Agent 往往表现得非常出色：

流程短

失败成本低

人一直盯着

出错了可以“重来一把”

但工程系统通常恰好相反：

流程长

多阶段

中途不可逆

出错必须可解释、可定位

这时候，Agent 的问题就会集中暴露出来：

行为前后不一致

中途突然“改主意”

无法判断当前处于什么阶段

错误发生后，难以复盘

二、问题不在模型，而在“系统不知道自己在哪”

很多团队第一反应是：

换更强的模型

写更复杂的 Prompt

加 memory

做上下文裁剪

这些办法可以缓解问题，但解决不了根因。

真正的问题是：

系统没有“运行态”的概念。

Agent 只有“对话在继续”，
但系统并不知道：

现在是规划阶段，还是执行阶段

是否具备进入下一阶段的条件

是否应该暂停或拒绝继续

在工程里，这是一个非常危险的状态。

三、上下文不是状态，这是一个常被忽视的区别

很多 Agent 框架试图用上下文管理来代替状态管理：

把关键信息写入 memory

对历史进行总结

压缩上下文长度

但在工程语义中：

上下文只是“说过什么”

状态是“现在允许做什么”

状态决定的是行为边界，
而不是语言内容。

四、为什么 Agent 特别容易“自信地跑偏”

在长流程中，经常会看到这样一种情况：

条件不充分

信息不完整

但 Agent 仍然给出完整行动方案

这不是模型突然“幻觉变多”，
而是 Agent 架构本身在逼模型继续行动。

因为在 Agent 体系里：

不行动 = 失败

没有“暂停”作为一等状态

没有“拒绝”作为合法输出

于是系统只能选择：
继续往前跑。

五、工程范式开始发生转移

当系统开始要求：

稳定

可复现

可审计

可冻结

工程关注点自然发生转移：

从“模型下一步能做什么”，
转向
“在当前阶段，系统允许做什么”。

这一步，就是从 Agent 走向可控系统的起点。

六、什么是“可控系统”（工程视角）

从工程角度看，可控系统并不复杂，它至少包含：

显式阶段
系统知道当前处于哪个阶段

阶段行为约束
每个阶段只允许有限行为集合

失败是一等状态
拒绝、暂停、回退都是合法输出

状态迁移有条件
不能随意跨阶段执行

这不是限制模型能力，
而是防止系统在错误阶段使用能力。

七、这不是否定 Agent，而是给 Agent 定位

需要明确的是：

可控系统不是反 Agent

而是把 Agent 放回合适的位置

在可控系统中：

Agent 可以作为阶段内工具

用于生成、分析、探索

但不再拥有流程主导权

就像：

引擎很重要

但不能决定方向和刹车

八、为什么这是一次“工程范式”的变化

这次变化之所以重要，是因为它改变了默认假设。

Agent 范式假设：

模型越聪明，系统越可靠。

可控系统假设：

边界越清晰，模型越有用。

工程评价标准也随之改变：

从“效果好不好”

转向“是否可控、可解释、可中断”

结语

Agent 并没有失败。

它只是完成了它在技术演进中的阶段性使命。

当 AI 开始进入长流程、高责任、不可试错的场景时，
工程系统自然会选择一条更稳的路。

从“让模型多干点事”，
走向
“让系统知道什么时候该停下来”。

这不是退步，而是成熟。

作者：yuer
Human–AI Co-Work / 可控 AI
GitHub：https://github.com/yuer-dsl/human-ai-co-work