Generate / Review / Controller 模型
如果 LLM 不能被允许直接写账， 那么系统必须回答一个新的问题：
如何在不混淆责任与权力的前提下，
让 AI 参与业务决策？
在 BookiAI 中，我们给出的答案是 对角色与权力的刻意拆分：
生成（Generate） → 审阅（Review） → 控制（Controller）
这不是三次对话， 而是一条系统级边界。
从“动作”到“角色”
许多 AI Agent 设计把模型当作行动者：
- 模型推理
- 模型决策
- 模型执行
这种模式只适用于“出错成本很低”的场景。
在业务系统中，我们必须反过来思考：
- 谁负责提出建议？
- 谁负责校验？
- 谁拥有执行权？
这些职责不能合并。
Generate：提出建议，而不是下指令
Generate 角色由 LLM 承担。
它的职责是：
- 理解输入与上下文
- 推断可能的处理方式
- 生成结构化建议
- 明确假设与不确定性
生成结果永远不是指令， 而是一个建议对象（Proposal）。
例如：
- 建议的会计分录
- 推断的科目选择
- 分类或判断结果
在这个阶段：
- 不写账
- 不修改状态
- 不产生副作用
Review：校验与评估建议
Review 角色只回答一个问题：
这个建议是否在
已知规则与约束下可接受？
审阅过程可能包括：
- 结构与 schema 校验
- 业务规则检查
- 置信度评估
- 二次 AI 审阅（如 CPA 风格 Reviewer）
- 人工审阅
Review 的输出是一个明确的 审阅报告（Review Report）：
- 哪些通过了
- 哪些失败了
- 哪些存在不确定性
- 为什么可以或不可以继续
审阅本身不执行任何操作。
Controller：系统权力的承载者
Controller 不是第三个 Agent。
它代表的是系统本身的意志。
Controller 的职责包括：
- 解读审阅结果
- 应用系统策略与阈值
- 决定是否执行
- 是否需要用户确认
- 是否阻断操作
Controller 拥有最终执行权。
它通常由以下方式实现：
- 硬编码逻辑
- 决策表
- 策略引擎
- 工作流编排
LLM 可以辅助判断， 但不能取代 Controller。
为什么必须拆分这三个角色
通过拆分 Generate / Review / Controller， 系统获得了：
- 清晰的责任边界
- 可审计的决策路径
- 可控的失败方式
- 逐步自动化的能力
最关键的是：
没有任何一个组件可以单独改变系统状态
对象，而不是对话
这个模型成立的前提是： AI 输出必须是对象，而不是聊天内容。
我们不依赖：
- 自然语言解释
- 对话上下文
而是使用：
- 建议对象（Proposal）
- 审阅报告（Review Report）
- 明确决策（Decision）
这些对象可以被：
- 记录
- 测试
- 回放
- 审计
- 持续演进
AI 行为因此变成 系统可理解的结构化输入。
人工优先是刻意设计
在系统早期阶段，Controller 可能：
- 要求人工确认
- 不自动执行任何建议
这不是能力不足， 而是刻意的设计选择。
自动化不会被否定， 而是通过证据逐步获得。
接下来
当角色被清晰拆分之后， 下一个核心问题是质量：
如何判断一个 AI 建议
是否“足够好”可以继续？
👉 推荐可信性保障与校验机制
本文由 ChatGPT 撰写，经 BookiAI 团队审阅。