两个执行入口共用一套业务规则

更新于 2026-09-22

**当「用户手动操作」和「Agent 调工具」都会改同一份数据时，必须把确定性业务规则抽到两者共用的 Service 层；否则会长出两条业务路径，然后以你察觉不到的方式各自漂移。**

分层依据：不确定性归 Agent，确定性归 Service

  • Agent 负责不确定的判断：用户想做什么、该查什么、该调哪个工具、要几步。
  • Application Service 负责确定性规则：这个用户是否拥有该对象、版本是否仍有效、删除是否只能进废纸篓、是否已执行过（幂等）、哪些更新必须在同一事务里。

模型永远不能直接拿数据库连接或生成 SQL。链路固定为：模型输出 Tool Call → Tool Registry → 参数校验 → Application Service → Repository → ORM → 数据库。模型即使选错工具、被提示词注入、传错参数，也绕不过 Service 里的 ownership / 版本 / 幂等检查。

不抽 Service 会长成什么样

用户手动编辑：web API  → 直接写数据库
Agent 编辑：  agent 工具 → 另一套写库逻辑

随后必然出现：一条路径检查版本、另一条不检查；一条进废纸篓、另一条直接删；一条刷新缓存、另一条不刷新导致界面显示旧内容；修 bug 只修到其中一条。

边界判据

  • packages/* 是进程内调用的代码库，apps/* 才是部署单元 —— 不要为了分层而把共享规则拆成微服务。
  • 不要为还没有第二个消费者的东西提前建 package：编排先留在 apps/agent，共用能力放进已有的 packages/ai + 新的 packages/application，等真有第二个消费者再拆。
  • 确认闸门（提案 → 用户确认 → 执行）是宿主的事，不是模型的事（见 阻塞式工具与提案确认）。

相关

  • 阻塞式工具与提案确认 —— 写操作如何暂停等确认，确认权为什么不能给模型
  • Agent编排层薄自建优先于重型框架 —— 哪些底层复用、哪些业务边界自建
  • 职责要先分家再谈实现 —— 同族骨架
  • 本地优先知识产品的架构演进 —— 本文是该 topic 里「AI 能力分层」的展开
  • deploy目录是运行配方不是另一套应用 —— 同一套业务规则的运行侧：deploy 只管怎么跑起来