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 员工不是给人用的」推出的产品决定
对话改名任务 ,历史对话改历史任务。首页与新任务合并,个人用途让人去用 Codex。
砍掉企业空间,不做应用市场。 理由是每家企业的上下文、规则、权限、系统都不同,agent 无法跨企业共用。
知识库与连接器提到一级菜单。 没知识就不能稳定交付,没连接器就只是 demo。
触发器移进 agent 本体 ,运行与修改要拆开,要加版本管理与回滚。这三件在演讲当天都还没做完。
飞书组织映射进产品做权限 ,企业级与团队级各一层「思想钢印」自动带进每个 agent。
一个 agent 的构成与上下文纪律
AI 工作规范、知识库、技能、工具、触发器、观测评估。工作规范要写角色、目标、岗位职责、上下文、决策规则、执行流程、输出规范,
明确否定「一句话人设」。只有工作规范每轮上传 ;知识切片后按需检索,技能与工具按需调用,删掉一段仍能完成任务的内容就删。
评估用另一个模型每日检查每一步,反思结果由人点「接受」后变成一段对话去改规范。
方法论才是他们真正的交付物
选场景五条判据 :高频重复决策、流程相对稳定、数据来源明确、规则清晰、效果可衡量。优先认知劳动,不找 AI 场景找人的工作。
场景 owner 一票否决 :owner 必须是对业务结果全权负责的业务专家,没有 owner 的场景不做。
上下文五要素 :企业知识、业务数据、任务信息、组织决策记忆、工作流与决策规则。
设计说明书六问 :为什么存在、负责什么、依据什么判断、如何执行、哪些不能做、如何判断做得好不好。他说这份说明书比 agent 本身重要。
进化三阶段 :能运行、能稳定、能进化。Skill 按能力拆而不按流程拆 ,「候选人画像分析」是 skill,「筛简历」是 agent 的任务。
几个可核的数字,全部是十布自述
项目 读数 备注
发票审批单次成本 平均 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 常量
建议吸收的,按可落地程度排
把事件接进 agent,这是第一件事。 底座已经有了,缺的是触发点。按五条判据筛,最合格的场景是发票验真三态闸门、IQC 判定后的让步或退货建议、对账单与 ERP 差异、到货计划确认超期、交付风险跟催、供应商准入预审。不合格的是战略寻源与谈判方案,上下文不完备且评价滞后。
给每个事件型 agent 写岗位说明书并落库版本化。 把系统提示拆成岗位定位、目标、判断规则、工作流、边界、验收标准六段,一个触发场景一份,带 revision,与技能表的 revision 同形。
先做规则注入,不急着做 RAG。 「prompt 放规则不放知识」正是我们的短板。准入策略、供货闸门档位、字典别名已经是结构化数据,注入成本远低于建向量库。我们 39 个 T0 工具本质就是他说的连接器,这一层不缺。
定义结构化结论。 照他的 pass、reject、review、需更多信息四态,给事件型 agent 定 ACCEPT、CONCESSION、REJECT、REVIEW 加证据字段的 schema。「交给人审核」那半我们已有 T2 确认卡。
建评价体系。 准确率、完成率、人工介入率、单次成本四个指标。人工介入率与 T2 拒绝率今天就能从工具调用表算出来,缺的是「结论对不对」的标注。V140 偏好反馈表刻意不回灌运行时,正好当人工评审来源。每个场景先人工标 50 到 100 条。
token 与成本记账。 只有一行 usage 日志,V220 已存 provider,加 usage 列后才算得出「有效 token 占比」。
技能按能力拆。 我们的技能是 SOP 流程文本,足迹挖掘出的也是序列。重启时改按能力建:供应商价值评估、报价异常识别、合同关键条款判断。两条技能当天停用的原因库里没有答案,要问人。
场景 owner。 对仙津,每个上线的事件型 agent 先定业务 owner。这与 53 号文档的 P2「去问郑总监」是同一件事。
三条不该照抄。
「全程无人干预」在我们这不成立,我们的 T2 会真的给供应商发邮件、真的下单,他们的案例全可回滚,确认卡是优势别拆。
「用什么模型都一样」被读数否定,8 条错误里 5 条是模型网关,思考开关在不同模型上差异从 7% 到几十秒,模型网关 failover 仍是 P0。
「不做应用市场」对我们是反的,他们做单客户 infra,我们做行业 SRM,行业预置的采购岗位说明书正是他们缺位、我们有壁垒的地方。
他们讲的东西里,最贵的不是哪个功能,是「判断一个 agent 是不是企业级」的那四个问题 。
拿它们回头看我们的 189 个会话:触发靠人、上下文靠工具现查、输出是散文、好坏没人量。
这四条改掉任何一条都不需要新架构,需要的是把已经躺在库里的规则、事件和留痕接到 agent 上。
下一步:先接事件,再写岗位说明书,评价体系跟着第一个场景一起建