SRM agent 何去何从：
做采购的 agent 运行底座

摆在面前的三条路：继续现在的 agent 对话模式、围绕豆包工作与 WorkBuddy 打通、还是学影刀做 AI 员工生产系统。 结论是它们不是三选一，而是同一个产品的三层，其中两层已经在做。 方向定为：SRM 做采购的 agent 运行底座；对话入口让给豆包工作与 WorkBuddy； 从影刀只拿「事件驱动的 AI 员工」这一个形态，落在 SRM 自己的业务事件上。不学他们做通用 WorkOS。

读数来源：53 号文档的生产实测（2026-08-22）、61 号文档与 modules/mcp 的 WorkBuddy 真机读数（2026-09-06）、63 号开源对标。影刀侧内容见姊妹页「影刀 AI WorkOS 的 Agent 框架对照」。

路 A · 继续现在的 agent 对话模式

内核是资产，壳不是，要分开看。

部分	读数	判断
聊天壳	周会话峰值 80 掉到 10；60% 会话只有一轮；技能库 2 条全部停用	入口之争，赢不了豆包与飞书
内核	T0 / T1 / T2 分级、T2 确认卡、按人算字段可见性与能力位、留痕、触发底座 V123	63 号实查：没有任何开源框架提供这四样

按影刀的分类，聊天壳是「个人助手」，追求灵光一现，用户天然流失。这解释了掉量，也说明再往壳上投入是在优化一个没人碰的东西。

路 B · 围绕豆包工作与 WorkBuddy 打通

这条已经做了一半：V233 与 modules/mcp 在生产，WorkBuddy 真机跑过 134 次调用。它替掉的是对话壳，不是内核。销售易接 WorkBuddy、Salesforce 出托管 MCP 是同一形态，Agentforce 没被替掉。边界也很清楚：只读，T2 确认卡在协议里没有对应物；自定义连接器只在本地电脑可用，覆盖不了定时、手机与无人跑的场景。

24% 的拒绝集中在三个检索工具上，是外部模型「换个词再试」的形状，说明工具描述与容错匹配还没对齐，这是可修的。关于「让 agent 调 srm cli」：豆包工作只收 HTTP 与 STDIO 两种传输，一个薄的 srm CLI 做 STDIO 桥接，底下还是同一个端点、同一份令牌，成本低，适合进企业提供目录和给桌面 agent 用。它与 HTTP 端点是同一层的两个插头，不构成独立方向。

路 C · 学影刀

影刀做的是横向 infra，卖给 FDE，每家企业从零搭 AI 员工。我们是垂直行业软件，客户买的是采购业务能力，不是搭 agent 的能力。不该学「做生产系统卖工具」，该学的是他那四个前提：事件触发、完整上下文、结构化输出、评价体系。这四条正好是我们内核此刻各缺一半的东西，而我们有影刀没有的优势：业务事件、规则、单据、供应商都已经在同一个库里，不需要连接器去拿。

再对照已定的价值口径：降本、提效、提质、风控、合规，锚在年采购额上。对话查询只碰提效，而且弱；事件型 AI 员工直接碰风控、提质、降本，例如发票验真闸门、IQC 让步或退货、对账差异、交付风险。价值口径也指向能力层。

主轴 · 事件型采购 AI 员工 · 接下来 3 个月

1. 把事件接进 V123 触发底座。首批两个场景：交付风险跟催，触发器已有，卡在主数据映射；对账差异与发票验真，规则已在库里。后续按五条判据排：IQC 判定、到货确认超期、准入预审。
2. 每个场景一份岗位说明书，六段落库带版本：岗位定位、目标、判断规则、工作流、边界、验收标准。系统提示不再是一个 Java 常量。
3. 结论结构化：ACCEPT、CONCESSION、REJECT、REVIEW 加证据字段。结论走确认卡、审批流或飞书卡，不走聊天。
4. 规则注入先于 RAG。准入策略、供货闸门、字典别名直接进提示；RAG 按 63 号 A-1 用 PgVector 后排。
5. 评价体系随第一个场景一起建：准确率、完成率、人工介入率、单次成本；每场景先人工标 50 到 100 条。人工介入率与 T2 拒绝率今天就能从工具调用表算出来。
6. 模型网关 failover 仍是 P0：8 条错误里 5 条是它，客户要求自有模型也靠这一层，走 Spring AI 的 OpenAI 兼容接入。

副轴 · 外部入口连接器 · 按 61 号文档 P1 到 P3 走，别停

• 修那 24% 的拒绝：三个检索工具改容错匹配，tools/list 描述里写清参数形状。
• 加 srm CLI 做 STDIO 桥接，同令牌同白名单。
• 事件型 AI 员工的结论也推进飞书群，这条链已经有了。
• 写权限不开，直到客户端支持「服务端要求确认后再执行」的协议语义。MCP 新版规范里的 elicitation 是要盯的那一格，三家客户端是否实现尚未核实。

收缩清单 · 明确不做

• SRM 自己的聊天壳降级为管理员与 FDE 的调试台和委派入口，不再作为采购员主入口投入。
• 不做通用 agent 平台、不做技能市场、不做多 agent 角色团队。企业里角色交接就是会签流，我们已有。
• 不换内核，底座借 Spring AI，挂在 ChatModelClient 后面，不绕开确认卡。

对客户的一句话产品形态

SRM 业务系统，加随实施交付的采购 AI 员工，加在你现有 AI 入口里问 SRM 的连接器。AI 员工按场景计价，岗位说明书是交付物之一，这一点直接借影刀。

半年后判断方向对不对，看这四个读数，不再看聊天会话数

读数	目标方向	今天的值
事件型 AI 员工处理的单据数	持续上升	0，触发器默认关
人工介入率	按场景下降	无读数，先建标注集
连接器月活令牌数	大于 0 且不集中在一人	真机 1 人，生产令牌 0 行
每场景结论准确率	有标注集、有数	无

三条路里，两条已经在做，第三条只需要拿走一个形态。真正要改的不是方向，是投入的重心： 从「让人来跟 agent 聊」转到「让事件把 agent 拉起来，把结论送到人面前」。 这件事不需要新架构，需要的是把已经躺在库里的规则、事件和留痕接到 agent 上。