文档会说话,Agent 不一定会照做:问题到底卡在哪

上一篇我们说了一个不太舒服的事实：规则写得越多，并不意味着 Agent 越可控。

如果只是”写的不够好”，解法很简单——继续改 Prompt、补文档、加更多 skill。

但真正让人焦虑的是：即使写得足够好，Agent 还是可能不照做。

这一篇，把问题从”Agent 不听话”升级为一个更精确的判断——治理机制本身有结构性断点。

一、先看清楚：我们已经做了什么

在正式拆断点之前，有必要先看现有体系已经做了什么。不是为了自我表扬，而是为了精确定位”缺的是什么”。

我们的 Agent 治理资产分为四层：

规则层——几十条红线和强制入口，告诉 Agent 什么不能做、什么必须先读。

路由层——十来个 workflow 类型，告诉 Agent 命中什么任务后走哪条路。

流程层——二十多个 skill，告诉 Agent 具体执行步骤。

工具层——正式脚本入口，告诉 Agent 只能用什么工具。

这四层加在一起，已经把”让 Agent 知道应该怎么做”这件事做得很完整了。

二、真正把体系卡死的四个断点

既然规则、路由、流程、工具都有了，问题出在哪？

出在一个容易被忽略的地方：这四层全部存在于文本层。它们的作用机制是”被读到 → 被理解 → 被遵守”。但没有一个独立的运行时来强制保证这个链条不断裂。

断点 1：状态不落盘

Agent 执行多步骤任务时，进度只存在于当前聊天上下文里。做到第 3 步了？哪个产物已经落盘了？哪个门禁已经通过了？——这些信息没有被持久化到任何地方。

上下文被 compact 或对话重新开始，所有进度信息都丢了。Agent 只能重新读文档，重新猜自己走到哪了。

断点 2：依赖关系无强制

文档可以写”必须先完成环境前置，才能做工具选型”。但如果 Agent 直接做了工具选型呢？没有任何机制把它挡回去。

依赖关系在文档里只是一句自然语言描述，不是一个可计算、可校验的约束。

断点 3：中断后不可恢复

一个测试实施任务可能跨越多天、多轮对话。中间 Agent 被打断，隔天再继续——恢复靠的是 Agent 重新理解上下文。

但上下文里没有”当前状态快照”。文档能告诉它”应该走 8 步”，但不能告诉它”你已经走了 4 步，第 5 步的产出还缺两个标题”。

断点 4：无阻止机制

这是最关键的。前面三个断点加在一起，造成的结果是：Agent 可以跳过任何步骤，没有后果。

它可以不确认环境就产出实施指南。它可以跳过测试工程反思就宣布流程完成。

没有人拦它——因为”拦”这个动作，在纯文档体系里不存在。

三、一个类比

十年前，代码质量靠 code review 和编码规范文档。有人不遵守？事后发现再打回。

后来有了 CI/CD：lint 不过、测试不过、覆盖率不够——merge 不了。规则从”靠人自觉”变成了”靠机器拦截”。

Agent 治理面临的处境很类似。现在的规则文档、workflow、skill，相当于那个年代的编码规范和 review checklist。有价值，但缺一个”不过就不让合”的环节。

我们不需要做到 CI/CD 那么重。但至少需要一道门。

四、这不是模型问题

有人会说：等模型更强、指令遵循更好了，这些问题不就解决了？

不会。

因为这不是”理解规则”的问题，而是”在执行过程中保持状态一致性”的问题。即使模型能力翻倍，它仍然面临：上下文窗口有限，状态会丢；多轮对话之间没有持久化中间状态的标准机制；模型无法自我验证”我是否已经走完了所有前置步骤”。

这些是工程约束，不是智能约束。工程问题需要工程解法。

五、断点补上了，规则才生效

我们不是缺规则——规则已经够了。

不是缺流程描述——skill 和 workflow catalog 已经做了。

缺的是一层执行保障：让规则从”被读到”变成”被执行时可检查、不通过时会阻断”。

下一篇，我们正式讲：为什么做 Workflow Runner，以及它解决的到底是什么问题。