业务系统里的 Agent 这个词，早就有主了

前阵子我在一套跑了两年多的业务系统里找"能不能接智能体"的落点，第一件事就是全文搜 agent。65 处命中，没有一处指 AI。它们指的是经销商和代理商：agentId、AgentSundry、一张代理商业务日志表。

这个撞名不是段子，它是接智能体时最先撞上的墙——你打算放进去的那个东西，在权限模型、表名、菜单项、审计字段里都已经有一个同名的主人了。

那套系统的形状

规模可以说清楚：二十个左右的服务仓，前后近两年、三十多人在写，我的提交分布在 19 个仓里，重心在平台层——认证、网关、日志链路、配置治理、错误码。单据侧的业务逻辑由三个团队各自实现，我做的是它们脚下那一层平台。

单据这一侧的形状是这样的：

• 单个核心服务里近两百张表，全是单据和它的变更件——订单、发货、发票、应收、结算，每张主表后面跟一张 _change 和一张 _item。
• 上百个 *StatusEnum。不是十几个状态在流转，是每个单据族都有自己的状态机，而且互相不对齐。
• 三百多处跨服务调用声明。一次"这张单子什么状态"的查询，链路上要过四五个服务。
• 二十多处分布式事务配置，加一套 Flowable 审批流。
• 每个服务一条流水线：主干分支出生产镜像、其他分支出开发镜像，推到私有仓库后用 compose 重建容器。

这个形状里藏着三条判断，是我读代码读出来的，不是试 demo 试出来的。

一、什么算异常，这条判断住在枚举里，不在模型里

「这张单子为什么卡住了」——这个问题的答案，系统里已经有了，写在某个 StatusEnum 的注释和某个 if 分支里。上百个状态枚举，就是上百份已经写进代码里的业务判断。

所以智能体的第一步不该是"把文档喂进去做问答"。文档是二手的，枚举和流转规则是一手的。我会先做一个状态字典工具，模型要回答任何问题都得先调它：

tool: read_status_dict
input:
  document_type: sale_delivery      # 单据族
output:
  - code: 30
    name: 待结算
    meaning: 货已发出、发票未开，账期未到期
    next_allowed: [31, 40, 90]      # 合法迁移
    owner_role: 结算专员
    blocked_when: 存在未核销的收款登记

有了这一层，模型的输出第一次变得可核对：它说"卡在待结算"，你可以回去查 next_allowed 里到底有没有那条路。没有这一层，你只能靠人读回答来判断回答对不对。

二、检索面是分布式的，难点不是权限而是"一个单号在多个库里指不同东西"

三百多处跨服务调用意味着：单据号不是全局键。同一个字符串在订单服务里是主键，在物流服务里是外部引用，在财务服务里可能根本没落地。接智能体时最容易低估的就是这一步——你以为在收权限，其实在对齐主数据。

能落地的做法我不绕弯子：在客户库旁边建一张只读的跨服务索引视图，把"单据号 → 单据族 → 所属服务 → 当前状态 → 最近一次变更时间"抽平，智能体只读这一张。它绕开了两件事：不用改 20 个服务的接口，也不用给模型发一套大于任务所需的凭据。

这条路的成本要提前讲清：这张视图本身是一个需要跟版本的数据工程，不是配置一下就能出来的。我见过最快的止损是先用一个服务的一条单据链跑通，验证"答案变准了"再扩面。

三、模型不能碰写，因为写要过事务和审批

那套系统里二十多处分布式事务配置不是装饰：一次发货确认要同时动库存、账期、应收三处。审批流是 Flowable 走的，节点上挂着角色和金额阈值。

把这种写操作交给模型自动执行，等于把两条一致性和一条合规链交给一个没有身份的调用方。我的边界固定三条：

1. 默认只读，读的范围由工具定义而不是模型自便。
2. 所有写动作交回原来的审批流——智能体最多生成一张待确认的草稿单，落库那一下必须是人点出来的。
3. 处置建议只输出到"下一步该谁做"，不输出"该改哪一列"。

第 3 条容易被砍掉，但它决定了这套东西上线后是帮人还是背锅。

评测集不必等客户授权

服务介绍里我写过"标注过的评测集"这一项，很多人问我样本哪来的——客户通常不愿意标，也没有能力标。

在这类系统里，标注集其实一直在自动生成，只是没人捡：

• 状态枚举的合法迁移给出"什么算异常"。凡是 next_allowed 里没有的迁移，就是负样本。
• 操作日志表给出"异常之后谁做了什么"。那张代理商业务日志表和每张单据的 operate_log，就是真实处置记录。
• 两者一JOIN，就得到一批天然的「异常现象 → 实际处置」对，一条标注都不用新做。

取材顺序反过来才是错的：先找客户要标注，多数项目卡在这一步就开始用模型自己造问题自己答。

一件现在就能做的事

把手上最核心的那条单据链的状态枚举导成一张表：状态码、中文名、允许迁移到哪几个状态、这个角色能不能改、什么条件下会卡住。

这张表不用接模型就已经有价值——它大概率是你们第一份有人维护的单据状态文档。而它一旦存在，智能体的工具定义和评测集种子就同时有了。多数团队不是卡在选哪个模型，是卡在这张表还没出现过。