行动库（Action Library）与受控上下文
在当前阶段，系统已经明确了：
- 执行权只属于 Controller
- AI 不得直接修改系统状态
此时，剩下的核心问题不再是“权力”， 而是：
如何在不放权的前提下，
让 AI 获得理解系统所需的上下文？
BookiAI 给出的答案是： 行动库（Action Library）。
原始上下文的危险性
许多 AI 系统向模型提供上下文的方式是：
- 直接注入数据库结果
- 拼接大量 JSON
- 无限扩展 Prompt
这会带来一系列问题：
- 上下文不可控
- Prompt 难以维护
- 行为难以预测
- 安全边界被模糊
更多上下文 ≠ 更好的理解。
未治理的上下文是一种负担。
什么是 Action Library
Action Library 是系统向 AI 暴露的一组受控能力接口。
每一个 Action 都具有：
- 明确的名称与语义
- 结构化输入
- 结构化输出
- 严格的权限与范围
最重要的是：
Action 暴露的是“意图”，
而不是底层实现。
AI 不直接访问数据库， 而是请求系统执行某个 Action。
默认只读的行动设计
在 BookiAI 中， Action Library 从 只读 Action 开始。
例如：
- 获取科目表快照
- 查询近期账本汇总
- 解析币种或税务上下文
- 校验策略约束条件
这些 Action：
- 提供必要信息
- 不产生任何副作用
- 可安全重复调用
这使 AI 可以推理， 而不会改变系统状态。
受控上下文优于完全暴露
通过 Action 统一管理上下文， 系统可以控制：
- AI 能看到什么信息
- 数据的新鲜度
- 暴露的细节层级
- 隐含的业务规则
AI 看到的是 被治理过的系统视图， 而不是原始系统本身。
这有效避免了：
- 数据泄露
- 错误假设
- Prompt 间上下文漂移
行动日志与可观测性
每一次 Action 调用都会被记录：
- 调用的 Action
- 输入参数
- 调用时间
- 调用角色（Generate / Review）
这些日志支持：
- 追踪 AI 行为
- 回放决策过程
- 审计上下文使用情况
- 持续改进 Prompt
上下文使用从“隐式” 变成“可观测”。
Action 不是执行工具
必须明确一个边界：
Action Library ≠ 执行引擎
Action 的职责是：
- 提供信息
- 校验约束
- 解释系统状态
它们不能：
- 写账
- 修改余额
- 执行决策
执行权始终只属于 Controller。
为什么 Action Library 可持续扩展
由于 Action 是显式且可版本化的：
- Prompt 可以保持稳定
- 上下文可以安全演进
- 新能力可以逐步加入
这避免了 Prompt 膨胀， 也使系统具备长期可维护性。
Action Library 成为：
系统与 AI 之间的正式契约层
接下来
当系统已经具备：
- 清晰的权力边界
- 明确的对象契约
- 受控的上下文接口
最后一个问题浮现出来：
Prompt 与指令本身，
应该如何被管理与治理？
👉 Prompt 治理与持续演进
本文由 ChatGPT 撰写，经 BookiAI 团队审阅。