SRM · AGENT 线 · 外部框架对照 · 2026-09-08

「AI 员工不是给人用的
影刀 AI WorkOS 的 Agent 框架,与我们的对照

这是对影刀 RPA 高管十布 2026 年 9 月 6 日深圳内部分享的分析。 他把企业级 agent 压成一句话:事件触发、AI 判断、AI 执行、持续进化,每一环各有一个硬前提, 并由此推出一连串产品决定:对话改名任务、砍掉企业空间、不做应用市场、知识库与连接器提到一级。 放回市场看,它的定位避开了办公入口的正面战场,赌注全押在 FDE 交付上。 放回我们的仓库看,它解释了 53 号文档没解释的那个数:agent 周会话量从 80 掉到 10

来源是会议语音转写,若干术语有错字,例如「HADES / Honey 框架」「ER / AR 员工」,本文按上下文读成工作规范框架与 AI 员工。 影刀侧的数字全部是十布自述,未独立核实;我们这一侧的读数全部来自仓库实读,主要对照 53 号文档与 modules/agent 代码。

企业级 agent 只有一句定义,四个硬前提比口号更值钱。
事件触发AI 判断AI 执行持续进化
环节硬前提演讲里的反例
触发由事件而非人发起员工合同到期前 90 天自动拉起续约评估,而不是人来问
判断完整的上下文会议纪要 agent,会议之外的上下文拿不到,因此判断不了
执行结构化的输出纪要输出形态千奇百怪,下游系统接不住,只能是建议
进化明确的评价体系战略 agent,好坏一两年后才知道,无法进化

从「AI 员工不是给人用的」推出的产品决定

一个 agent 的构成与上下文纪律

AI 工作规范、知识库、技能、工具、触发器、观测评估。工作规范要写角色、目标、岗位职责、上下文、决策规则、执行流程、输出规范, 明确否定「一句话人设」。只有工作规范每轮上传;知识切片后按需检索,技能与工具按需调用,删掉一段仍能完成任务的内容就删。 评估用另一个模型每日检查每一步,反思结果由人点「接受」后变成一段对话去改规范。

方法论才是他们真正的交付物

几个可核的数字,全部是十布自述

项目读数备注
发票审批单次成本平均 0.4 元现场展示那单 1.4 元
平台费109,800 元 / 年起不限人数,私有化另计
模型通道费8 到 16 个点实际约 8 到 10,量大递减
陪跑服务6,000 元 / 人天目录价,预计成交 4,000
员工人数560 → 500 零几去年初到现在
内部有效 token 占比目标20% → 30% → 40%探索 / 试点 / 生产三阶段按场景配额
放进市场:定位避开了正面战场,赌注全押在 FDE 上。

优势

  • 不做办公入口。明确让出给豆包、WorkBuddy、Codex,自己做「生产 AI 员工的 infra」卖给 FDE,与 Palantir 的 FDE 模式同构。
  • 有执行的手。RPA 存量客户、连接器、飞书审批 API 直连,让「判断之后真的执行」成立。这是纯对话产品缺的最后一公里。
  • 对企业级的认知是对的。稳定取决于框架而非模型、看 1000 次完成率不看单次闪光、必须可测量可治理,与业界共识一致。
  • token 治理有商业闭环。按场景配额、用「持续产生价值的 token 占比」做指标,价格透明只收通道费。
  • 进化 loop 落到了产品里。每日评估、反思、接受即改、版本回滚。

劣势与风险 · 一半是他自己承认的

  • 产品尚未定型。触发器没合入、组织映射没做、运行与修改混在一起、多个页面要砍。内部不建议给客户用,只放 5% 到 10% 的人卖。
  • FDE 既是瓶颈也是壁垒。他自己说「目前几乎没有人能做」。重交付模式难以随客户数线性扩张。
  • 不做应用市场意味着每家从零搭,与同场讲的「美的策略,谁火跟谁」矛盾。
  • 评价仍靠人工打标,每日反思是模型评模型,有自我强化风险,却被讲成自动进化。
  • 案例全是内部管理决策:报销、考勤、简历、续约。「全程无人干预」在对外动作上未被验证。
  • 基本面承压。续费率下降、关掉多条业务线、裁员一成,全押 AI WorkOS。私有化收不到通道费,客户又要自有模型。
  • 生态绑定飞书,钉钉与企微客户是障碍。「国内无对标」是自述,Coze、Dify、来也、弘玑都在同一方向上。
对 SRM agent:它解释了 53 号文档没解释的那个数

按十布的分类,我们的 agent 是「给人对话用的助手」形态。助手追求灵光一现,用户会流失。这是形态问题不是架构问题,与 53 号文档「架构优化不是瓶颈」的结论互相印证。下面两张图都是生产读数,2026-08-22 实测。

189
个 agent 会话 · 其中 165 个来自采购总监一人 · 07-20 至 08-22
TICK STRIP · 一格 = 1% ≈ 1.9 个会话 · 墨色 = 只有一轮用户消息 · 浅灰 = 多轮 · 平均每会话 3.1 次工具调用
RUNG BARS · 每周新建会话数 · 一档 = 1 个会话 · 每五档一个圆点 · 08-17 那周只剩 1 个用户

他讲的四个前提,我们此刻各缺一半

先摆我们有而他们没讲严的:T0 / T1 / T2 分级与 T2 确认卡、技能渐进加载、系统触发底座 V123、操作足迹挖技能候选、模型与思考三态偏好。缺的正好是那四个前提。

他们的前提我们此刻
事件触发只有 2 个定时触发点,默认关;跟催那套最成熟的事件引擎与 agent 零连接
完整上下文无知识库无 RAG;准入策略、供货闸门、字典别名都在库里,一条都没注入提示
结构化输出输出是自由文本加工具调用,没有结论 schema
评价体系无测试集、无准确率、无提示版本;技能库 2 条全停用;系统提示是一个 Java 常量

建议吸收的,按可落地程度排

  1. 把事件接进 agent,这是第一件事。底座已经有了,缺的是触发点。按五条判据筛,最合格的场景是发票验真三态闸门、IQC 判定后的让步或退货建议、对账单与 ERP 差异、到货计划确认超期、交付风险跟催、供应商准入预审。不合格的是战略寻源与谈判方案,上下文不完备且评价滞后。
  2. 给每个事件型 agent 写岗位说明书并落库版本化。把系统提示拆成岗位定位、目标、判断规则、工作流、边界、验收标准六段,一个触发场景一份,带 revision,与技能表的 revision 同形。
  3. 先做规则注入,不急着做 RAG。「prompt 放规则不放知识」正是我们的短板。准入策略、供货闸门档位、字典别名已经是结构化数据,注入成本远低于建向量库。我们 39 个 T0 工具本质就是他说的连接器,这一层不缺。
  4. 定义结构化结论。照他的 pass、reject、review、需更多信息四态,给事件型 agent 定 ACCEPT、CONCESSION、REJECT、REVIEW 加证据字段的 schema。「交给人审核」那半我们已有 T2 确认卡。
  5. 建评价体系。准确率、完成率、人工介入率、单次成本四个指标。人工介入率与 T2 拒绝率今天就能从工具调用表算出来,缺的是「结论对不对」的标注。V140 偏好反馈表刻意不回灌运行时,正好当人工评审来源。每个场景先人工标 50 到 100 条。
  6. token 与成本记账。只有一行 usage 日志,V220 已存 provider,加 usage 列后才算得出「有效 token 占比」。
  7. 技能按能力拆。我们的技能是 SOP 流程文本,足迹挖掘出的也是序列。重启时改按能力建:供应商价值评估、报价异常识别、合同关键条款判断。两条技能当天停用的原因库里没有答案,要问人。
  8. 场景 owner。对仙津,每个上线的事件型 agent 先定业务 owner。这与 53 号文档的 P2「去问郑总监」是同一件事。
三条不该照抄。 「全程无人干预」在我们这不成立,我们的 T2 会真的给供应商发邮件、真的下单,他们的案例全可回滚,确认卡是优势别拆。 「用什么模型都一样」被读数否定,8 条错误里 5 条是模型网关,思考开关在不同模型上差异从 7% 到几十秒,模型网关 failover 仍是 P0。 「不做应用市场」对我们是反的,他们做单客户 infra,我们做行业 SRM,行业预置的采购岗位说明书正是他们缺位、我们有壁垒的地方。

他们讲的东西里,最贵的不是哪个功能,是「判断一个 agent 是不是企业级」的那四个问题。 拿它们回头看我们的 189 个会话:触发靠人、上下文靠工具现查、输出是散文、好坏没人量。 这四条改掉任何一条都不需要新架构,需要的是把已经躺在库里的规则、事件和留痕接到 agent 上。

下一步:先接事件,再写岗位说明书,评价体系跟着第一个场景一起建
SRM AGENT 线 · 外部框架对照 · 2026-09-08 来源 · 影刀 2026-09-06 分享转写 + SRM 仓库实读