TIL：AI Agent 的四个控制层模式
原文 提出一个判断，构建 AI 产品时，把时间花在「控制层」上，比花在选哪个模型上更重要。模型本身是无状态的函数调用，在把它变成产品的过程中，所有可控的部分都由它外围的工程代码来实现。作者把这层代码叫做控制层（control layer）。这篇从原文中提取四个核心模式记录下来。
之前写过两篇更详细的拆解，代码契约层 聚焦 agent 不直接执行副作用操作的设计，Agent 七阶段 讲从 API 调用到完整循环的递进，可以作为深入阅读。
模式一：状态机管流程，模型管单步
用确定性状态机把总体流程固定下来，形成比如 categorize → validate → confirm → persist 这样的管道，模型只负责当前阶段该做的事，比如分类就只管分类，不需要决定下一步干什么。因为流程是代码写死的状态机，不是模型临时决定的，所以测试、打日志、断点调试这些常规手段都能用。
代码契约层那篇文章中的 submit 函数就是这个模式，幂等检查、试运行、审批、持久化，四道关卡全是写死的逻辑，agent 只负责构建 ExpenseAction，碰不到执行。
模式二：用接口把模型包起来
模型应该藏在接口后面，成为可替换的函数调用。服务层依赖接口，而不是具体模型。这样可以很容易对模型进行切换，可以给简单分类任务配便宜模型、复杂推理配贵模型。
测试也变得简单起来了，传一个满足 Protocol 的 mock 就能跑通整条管道，不用真的调 API。
模式三：生成器和评估器分开
这个模式里，模型是生成器，验证层是评估器。模型吐出来的东西不能直接丢给用户，格式对了不代表内容对了：金额可能是负数，分类可能不存在，文本里可能藏着敏感信息。所以解析完结构化数据之后，还得过一道内容校验，检查业务规则、过滤敏感信息，甚至让另一个模型对结果打分。
验证层不通过的时候通常不报错，而是把反馈循环回去让模型重试，减少错误结果被下游直接拿去执行的概率。
模式四：用结构化输出管格式
模型默认返回的是一段纯文本，你拿这坨文本没法干活：存数据库要字段名，验证要格式，测试要可断言的东西。所以得要求模型按指定格式输出，比如让它吐 JSON，再用 Pydantic 解析成带类型的数据对象。这样下游代码拿到的就是普通数据结构，该存存，该验验。格式对了不等于内容对了，内容层面的校验是模式三的事。
Agent 七阶段那篇文章的 Stage 2 详细讲了这个过程，提示词当契约写，Pydantic 兜底验证，两道防线。
把四个模式串起来
这四个模式不是各管各的，更像一条流水线上的四道关卡。
- 状态机 决定「现在该干什么」（流程约束）
- 接口隔离 决定「模型在哪介入」（位置约束）
- 验证层 决定「模型输出能不能用」（质量约束）
- 结构化生成 决定「模型只能输出规定格式」（格式约束）
这样一来，到模型被调用时，它的下一步动作已经被约束到安全范围内了。模型在允许范围内仍然可能做出意料之外的事，但爆炸半径被限住了，不会波及到整个系统。