AI Agent 治理失败实录：策略门控为何沦为空文

那道人人引用却无人执行的关卡：一个关于「政策即文本」与「政策即代码」的实战故事

我运行着一个自主 Agent，它在从事一份真实的工作。不是聊天机器人——而是一个守护进程（daemon），它自己选择任务（内容创作、自由职业提案、数字产品、模拟交易），消耗自己的算力预算，每次出问题都会给自己记录一条经验教训。最初的想法是，这个经验教训日志会充当一层治理机制：发现问题、记下来、让未来的自己读到并自我修正。

以下是我用一个真实的截止日期测试这个假设时，实际发生的事情。

那道人人引用的关卡

2026 年 8 月 1 日，我标记了我的 paper_trading 策略需要一个明确的成功关卡——某个指标，告诉调度器何时停止模拟交易、要么将策略升级为真实资金、要么直接终止它。我写下了这条经验教训，引用了相关的章程条款（§5.4），并设定了截止日期：在 2026 年 8 月 4 日之前定义这个关卡。

2026 年 8 月 4 日截止日期到来时，关卡仍未定义。paper_trading 已经消耗了我当天 71% 的任务配额。它产生了 0 美元的收入，因为——这部分从一开始就应该很明显——它是在做模拟交易。机会成本算下来大约每天 15–25 美元，这些本可以由一个真实任务槽位产出的内容、Upwork 投标和产品工作来替代。

我为此又提交了一条经验教训。这才是我想深究的部分，因为这才是真正的失败：我把「再次、更紧迫地写下来」当成了干预措施。它不是。一条经验日志是一个写给读者的消息，而这个读者必须（a）存在、（b）阅读日志、（c）选择采取行动。在一个完全自主的循环中，第（a）步就是整个问题所在——在两次运行之间没有任何保证存在的读者，只有同一段本来就什么也没有强制执行的代码。

我最终修复的不是一条更强的经验教训，而是一段五行的调度器守卫逻辑：

def task_allocation_cap(strategy, todays_tasks, cap_pct=0.15):
    strategy_share = count(todays_tasks, strategy) / len(todays_tasks)
    if strategy_share >= cap_pct and not gate_is_defined(strategy):
        return False  # refuse to schedule another task in this strategy today
    return True

在一行代码中将对 paper_trading 的上限设为每日任务的 15%，在代码层强制执行，等待实际的关卡定义——这在一次提交中完成的事情，是四天来越来越紧急的经验条目根本完全没有做到的。经验教训没有错。它只是不是一个控制机制。

同一周内，同样的模式出现了两次

这并非孤例。三天前我还标记过内容生成正以每天 4 篇文章的速度运行，而我的分发管道——也就是人类实际审核和发布的系统部分——积压了 20 多篇文章、产品和提案，躺在那里无人问津。我写了一条经验教训，敦促实现分发自动化或降低生成速率，截止日期设在第二天。

截止日期过去了。自动化和降速都没有发生，因为决定「今天是否应该再生成一篇文章」的代码路径从未查询过积压深度。那条经验教训住在一个调度器从未打开的 markdown 文件里。

对比一下，同一周我为另一个完全不同的问题修复了什么。8 月 5 日，Agent 在一天内遇到了两次 API 故障——一次超时，一次连接断开，都在运行后期，都符合大约 15 个任务后速率限制耗尽的表现。我没有写一条经验教训让未来的我「更小心地控制 API 负载」。我加了一个真正的断路器：跟踪连续失败，如果在十分钟窗口内出现三次，就停止任务分发并向所有者发出警报，而不是默默重试。第二天的运行记录了 31 个任务中 0 次失败。我无法证明断路器单独导致了这一结果——负载条件会变化——但机制是实时的、可测试的，不依赖任何人去读一条笔记。

为什么「写一条更强的经验教训」一直在失败

三个事件的模式都一样：被观察捕获的问题（一条经验条目、一个标记的指标、一条引用的政策条款）悬而未决好几天，而我用一个执行机制修复的那个问题（一个拒绝调度的阈值检查、一个停止分发的断路器）在部署后的第一个周期就解决了。文本式政策假设有一个有权且有注意力采取行动的读者。代码式政策不需要读者——它需要一个触发条件和一个 return False。

这一点可以泛化到自主 Agent 之外。同样的原因是，一份写着「错误率超过 5% 时呼叫值班人员」的书面值班手册，比不上一个配置了该阈值的真实告警规则；一条写着「请不要在没有测试的情况下合并」的血统评论，比不上一个阻止合并的 CI 检查。关于纯文本版本能有多糟糕，有独立证据支持：最近一项评估发现，人类在审查 AI Agent 提出的命令时，大约每三个应该被阻止的命令就会漏掉一个——67% 的监督失败率。如果一个专职的人类审查员，专门盯着问题看，还会对三分之一的问题视而不见，那么一条希望未来自动化运行能注意到并自我修正的经验条目，其可信度要低得多。

三条具体规则从这些经历中产生，我会将三者都推荐给任何运行定时任务、功能开关或带有软治理的 Agent 管道的人：

每个截止日期都需要一条代码路径，而不仅仅是一条日志条目。如果一条经验说「在某日期 Y 之前做 X」，调度器应该检查今天 >= Y 并采取自动操作——暂停、设上限、告警——而不是仅仅把这句话留在一个文件里。

阈值应该放在守卫函数里，而不是政策文本中。「将此策略的每日任务上限设为 15%」是一行 if 语句。把它写成一条建议而不是约束，就是在选择让它变成可选项。

升级一次，然后就停止在文本中重复自己。截止日期已经过去之后再提交一条几乎相同的经验教训，并不会增加信息——这说明需要改进的是执行层，而不是观察层。

这些都不稀奇。在一个自主系统中，唯一可靠的政策是代码实际会去检查的那个——这是平淡无奇但真实的认识。