把 Agentic AI 接进业务系统（我们的场景是 Odoo 20），外行看是"给系统加个会聊天的助手"，工程上其实是给自动化开放了一个有权力的执行通道。权力越大，边界越要写清楚。我们的 agentic_ai 工程最终拆成四层——核心 + 销售桥 + ERP 工具包 + MCP 桥，各自安装、各管一段边界。以下五条原则来自 v2 的设计评审，完整实现文档在产品站（文末链接）。
原则一：工具即业务动作，不是数据库通道
工具清单里最诱人的设计——"执行任意查询"的万能工具——恰恰是不能要的。每个工具必须对应一个业务语义明确的动作：「查询某客户的未结订单」「为订单生成跟单任务」。
理由有二：权限能对齐（业务动作有天然的权限归属，"任意查询"没有）；审计能说清（日志里是"改了什么业务对象"，不是"跑了一段 SQL"）。工程上的对应做法是受信注册表：工具执行不做任意路径导入，只从白名单里取已登记的原生处理器——未登记的一律拒绝（fail-closed）。
原则二：权限双重对齐，自然语言不是旁路
一个工具能否被调用，取两层交集：
- 操作者在 Odoo 里的真实权限（记录规则、多公司过滤全部生效）；
- Agent 配置的工具白名单。
自然语言入口不能成为任何权限的旁路——这是把 Agent 接进业务系统的底线。任何一次越权访问（哪怕只是"看到了不该看的数据"）都是阻断级问题，不是"优化项"。
原则三：护栏前置，而不是执行前才拦
安全检查分两层：规划阶段过滤 + 执行阶段检查。
- 规划过滤负责体验：无权使用的工具、上下文不可用的动作，在生成计划时就剔除，不让用户看着助手走死路；
- 执行检查负责兜底：检查链在执行前仍完整运行，防绕过。
两层都挂速率与成本限制：计划层估算，执行层扣减。
原则四：写操作按影响面分级确认
"所有写操作都要确认"最后会逼用户闭着眼点确认；"都不确认"是事故预备役。按影响面分级：
| 风险级 | 示例 | 确认方式 |
|---|---|---|
| 低 | 生成草稿、内部任务 | 自动，事后可撤销 |
| 中 | 单据字段修改、状态推进 | 汇总确认 |
| 高 | 超阈值金额、删除、对外发送 | 逐项确认 + 前后对比 |
分级规则本身可配置——确认流不是产品写死的，是企业策略的表达。同时，每一步执行都进不可变审计：谁发起、看了什么、做了什么、谁确认——事后必须能完整还原。
原则五：诚实验收，不用"演示效果"签字
Agent 的验收最容易被一次漂亮的演示糊弄。我们按任务集分级验收：
- 只读问答 → 单步写操作 → 多步跨模块，逐级通过才能进入下一级；
- 指标里包含越权率（必须为 0）、确认流触发正确率、可回溯率；
- 专门收录"应当拒答/转人工"的用例——助手拿不准时，正确行为是停下问人而不是猜；答对拒答，才算通过。
这不是纸面方法：产品侧的 agentic_ai 模块当前有 13 个测试文件、133 个用例，其中安全与确认链路的占比最高——测试分布就是工程立场的表达。
写在最后
这五条原则里没有一条是"AI 技术"，全部是工程边界。这可能就是 Agentic AI 落地最真实的样子：模型能力决定上限，工程边界决定能不能交付。
我们把这套设计规范在 Odoo 20 上收敛成了完整实现文档——《Agentic AI for Odoo 20 — 设计规范与实现文档（v2）》，含架构、工具系统、安全护栏与验收方法，发布在产品站博客（相关文章见文末链接）。