在 Agent 讨论中，最容易出现的一个问题是：
所有东西都塞进 Prompt。
工具、流程、状态、判断逻辑，全靠模型“临场发挥”。
Demo 看起来很聪明，但一上工程环境就开始失控。
从工程视角看，这不是模型问题，而是架构问题。
一、为什么需要三层架构？
在传统软件工程里，我们几乎从不允许：
- 能力定义、决策逻辑、执行流程混在一起
- 上下游边界不清
- 状态不可追踪
但在很多 Agent 系统中，这恰恰是常态。
结果就是：
- 行为不可控
- 难以调试
- 无法复用
三层模型的目标只有一个：
把 Agent 从“即兴智能”，变成“可工程化系统”。
二、工程场景：自动处理「发票报销」
这是一个在企业里非常典型、也非常容易踩坑的 Agent 场景：
目标：
用户提交发票 → Agent 校验 → 填系统 → 给出结果
听起来很简单，很多人会直接这样做：
“把需求写进 Prompt，让 Agent 自己处理。”
三、不分层的 Agent，通常怎么翻车？
常见 Prompt 写法（简化版）
“你是一个报销助手，请读取发票信息，校验规则，必要时查询系统，并完成报销流程。”
工程上的实际问题：
- 校验规则在 Prompt 里，改一次要重测全部
- Agent 有时先提交系统，再发现发票不合法
- 中途失败无法恢复，只能重跑
- 日志只剩一堆自然语言
根因只有一个：
能力、决策、行为混在一起了。
四、三层模型如何拆这个场景？
第一层：能力层（Capability）
能力层只做一件事：提供确定性能力。
例如：
extract_invoice_info(file)validate_invoice_rules(data)query_reimbursement_policy(user)submit_reimbursement(data)
工程特征：
- 输入输出结构化
- 不关心顺序
- 不关心上下文
能力层本身永远不知道“报销流程”。
第二层：决策层（Decision）
决策层回答：
“当前状态下，下一步是什么？”
示例决策输出（结构化）：
{
"next_action": "VALIDATE_INVOICE",
"confidence": 0.92
}
它可能做的事情：
- 判断发票类型
- 判断是否需要查政策
- 判断是否可以进入提交阶段
但它不直接调用任何能力。
第三层：行为层（Behavior）
行为层是真正的“流程引擎”。
报销流程状态机（简化）
INIT
↓
EXTRACT_INFO
↓
VALIDATE
↓
CHECK_POLICY
↓
SUBMIT
↓
FINISH
每个节点：
- 指定允许调用的能力
- 校验输出
- 失败可回滚或中断
五、三层之间如何协作？
一个工程上健康的调用链，通常是这样的：
用户请求
↓
决策层：识别任务类型
↓
行为层：选择并执行对应流程
↓
能力层：在指定节点调用工具
↓
结果校验 / 人工介入
关键点在于：
- 决策层不直接调工具
- 能力层不感知流程
- 行为层不做“自由推理”
「发票报销」一次完整执行是如何跑的？
- 用户上传发票
- 决策层识别为「报销任务」
- 行为层进入
EXTRACT_INFO - 调用
extract_invoice_info - 进入
VALIDATE，失败直接中断 - 合法 →
CHECK_POLICY - 通过 →
SUBMIT - 返回结构化结果
整个过程中：
- Agent 从未“自由发挥”
- 每一步都可记录、可重放
三层模型在工程上的直接收益
对比不分层方案：
| 问题 | 不分层 | 三层模型 |
|---|---|---|
| 调试 | 看对话 | 看状态 |
| 回滚 | 不可能 | 状态级 |
| 复用 | 几乎为 0 | 能力/流程复用 |
| 风控 | 靠运气 | 明确边界 |
六、常见反模式（工程踩坑区）
❌ 反模式 1：所有逻辑写进 Prompt
问题：
- 难维护
- 不可测试
- 一改就崩
❌ 反模式 2：模型自由组合工具
问题：
- 顺序不稳定
- 参数不可控
- 难以复现
❌ 反模式 3：没有显式状态
问题：
- 中途失败无法恢复
- 无法重跑
- 日志无意义
七、给技术人员的落地建议
如果你要做一个可上线的 Agent 系统：
- 先拆三层，再写 Prompt
- 能力层当 SDK 设计
- 决策层限制选择空间
- 行为层用流程和状态兜底
- 所有层级都必须可观测
这是工程稳定性的最低要求。
结语
Agent 并不是“一个聪明的大模型”，
而是一个由能力、决策和行为组成的系统。
把架构拆清楚，Agent 才可能从 Demo 走向生产。
