企业把制度、操作手册和流程图都喂给了 AI，得到的往往还是一个会背流程的客服。想让 Agent 真正接手工作，得先把人类靠经验补齐的那些条件，变成机器能够理解、执行和验证的工作契约。
设想一家企业准备上线退款 Agent。
项目组把售后制度、客服话术、退款流程图和几十篇知识库文章全部放进去。演示时很顺：问它“怎么申请退款”，回答清楚，语气也像一个熟练客服。
真正接入订单系统，问题马上变了。
同一个“申请退款”，可能包含完全不同的情况：未发货、已经签收、部分商品损坏、优惠券过期、组合订单拆单、客户重复申请。订单状态在电商系统，付款记录在支付平台，物流又在另一套系统里。
客服 SOP 上只写了一句：
“核实订单，符合退款政策的予以处理，特殊情况请主管审批。”
人看见这句话，大概知道该怎么办。
Agent 看见以后，问题一大堆：
- “核实”到底要查哪些字段？
- 以订单状态、支付状态还是物流状态为准？
- 哪一版退款政策有效？
- “符合”包含哪些条件和例外？
- 主管是谁，怎么发起审批？
- 它可以创建退款申请，还是可以直接把钱退回去？
- 接口超时以后能不能重试？重试会不会退两次？
- 做完以后，以一句“退款成功”为准，还是必须拿到退款流水号？
这才是企业 Agent 从演示走向生产的分水岭。
我先把观点摆出来：
传统 SOP 是给受过训练的人看的记忆辅助。Agent 需要的是一份可执行、可授权、可验证的工作契约。
给 Agent 多塞几十页文档，补不上这道差距。
SOP 里省略的东西，人一直在偷偷补
企业里的 SOP 很少从零教会一个人做事。
新员工先接受培训，再跟着师傅处理真实案例。遇到文档没写的情况，他会看同事怎么做，理解部门之间的默契，慢慢知道哪些规则必须严格遵守，哪些步骤可以灵活处理。
几年以后，员工看到一句“酌情处理”，脑子里可能已经调出了二十个旧案例。
这部分经验不会完整出现在文档里。
2025 年一项关于流程挖掘前期工作的研究发现，流程例外、系统特性和操作习惯等关键信息，经常以隐性知识的形式留在个人身上，主要依靠会议、讨论和日常协作传播。正式文档记录的是显性知识，真实流程还需要业务、系统和分析人员共同拼出来。研究原文
Agent 没有这段入职经历。
它不会自动知道“老客户一般先安抚”“财务月底关账时不要重复提交”“这个字段三年前就不用了”。它也不会因为担心被追责，主动找主管再确认一遍。
人类员工执行的是：
文档 + 培训 + 经验 + 现场信息 + 组织关系 + 责任压力。
Agent 拿到的往往只有文档。
所以它能把制度复述得很漂亮，一到真正的分支、例外和系统动作，就开始猜。
这张图里的差距，才是很多企业知识库已经建好、Agent 仍然不敢上线的原因。模型可以阅读显性文字，却无法凭空继承师傅带徒弟时传下来的判断，也不会自动拥有员工对风险和责任的感知。
会回答 SOP，不等于会执行 SOP
这两个能力很容易在演示里混在一起。
问 Agent：“签收七天以后还能不能退？”它可以从知识库找到条款，给出一段解释。这个任务主要考验检索和语言生成。
让 Agent 处理一笔真实退款，它需要完成一条行动链：识别用户意图、确认身份、读取订单、核对商品类型、判断时间窗口、检查历史售后、计算金额、选择工具、申请审批、执行退款、回写状态，再向客户解释结果。
每一步都可能改变下一步。
2025 年发布的 SOP-Bench，用 1,800 多个任务测试 Agent 执行复杂工业 SOP 的能力。在论文所测试的架构中，Function-Calling Agent 和 ReAct Agent 的平均任务成功率分别只有 27%和48%。当系统向 Agent 暴露远多于当前任务所需的工具时，错误工具调用接近 100%。SOP-Bench
这些数字来自特定模型、架构和合成任务，不能拿来代表今天所有 Agent 的能力。但它揭示的风险很现实：
长流程会累积局部错误，工具越多也不等于能力越强。
美团研究团队随后发布的 SOP-Maze，从真实业务材料中整理了 23 类复杂 SOP 场景。他们把常见失败归纳为三类：走错流程路径、经不起真实对话里的干扰，以及在时间和算术判断中犯错。SOP-Maze
有时 Agent 最后的答案看起来没问题，执行过程却已经违规。
比如退款金额算对了，但它跳过了身份核验；客户确实拿到了钱，但同一笔申请被接口重试了两次；结论符合政策，却调用了不属于自己权限的客户数据。
企业不能只看最后一句话对不对。
还得看它用对了数据没有、走对了路径没有、调用了什么工具、谁给了权限、过程中有没有越界。
真正缺的，是机器能执行的工作说明书
OpenAI 的 Agent 构建指南也建议从现有 SOP、客服脚本和政策文档出发，但后面还有三步：把密集材料拆成更清晰的小步骤，让每一步对应具体动作或输出，并补全信息缺失、用户提出意外问题等边缘情况。OpenAI Agent 指南
这意味着，企业不能把“上传文档”当成 SOP 改造的终点。
一份能驱动 Agent 的工作说明，至少要回答八组问题。
可以先记住这张架构图：理解层负责把业务对象和当前事实弄清楚，决策层决定任务怎样走，行动层限制 Agent 能调用什么、最多做到哪一步。日志和评测再把真实执行结果送回流程，推动下一版规则更新。
第一，目标是什么？
“处理退款”只是任务名称，不是目标。
企业究竟想缩短处理时间、减少错退、降低人工量，还是改善客户满意度？几个目标冲突时，哪个优先？
如果目标没有写清楚，Agent 很容易把“尽快解决”理解成“尽快把钱退掉”。效率上去了，风险也一起上去了。
第二，任务什么时候开始，什么时候结束？
开始可能是收到一条退款申请，也可能是人工已经完成身份核验以后，把工单交给 Agent。
结束也不能只写“处理完成”。成功状态可以是取得退款流水号并回写工单；失败状态可以是生成一张信息完整的人工待办；超时、系统不可用或达到最大重试次数，则必须停止。
开始和结束不清楚，Agent 就不知道自己负责哪一段，更不知道什么时候该停手。
第三，它面对的业务对象是什么？
订单、支付单、包裹和退款单，看起来都带一个编号，却不是同一个对象。
一张订单可能对应多次付款、多个包裹和多笔退款。Agent 必须知道这些对象之间的关系，也要知道字段来自哪个权威系统、多久更新一次、数据冲突时听谁的。
这正是前一篇 Ontology 文章讨论的业务语义层：它让 Agent 按照企业自己的对象、关系和口径理解业务，而不是看见几个相似字段就自行脑补。
第四，哪些判断应该写成确定性规则？
金额、日期、资格、库存和权限校验，不适合每次都让大模型临场发挥。
传统流程工程早就在处理这类问题。BPMN 用来描述活动、事件、分支和交接；DMN 用决策表精确表达多条件业务规则，并支持验证和执行。BPMN、DMN
企业不一定非要采购一套 BPM 平台，但应该吸收这个原则：
能稳定写成规则的部分，用规则守住；需要理解语言和处理模糊信息的部分，再交给模型。
以退款为例，“签收是否超过七天”“商品是否属于特殊品类”“金额是否超过自动处理上限”都可以确定性计算。客户描述究竟是质量问题、物流损坏还是主观不喜欢，才更适合让模型辅助判断。
第五，每一步对应什么工具？
“查询订单”对人来说是一项操作，对 Agent 来说必须是一个明确的工具契约。
它需要知道工具叫什么、用于什么场景、输入哪些参数、会返回哪些状态、出错意味着什么，以及调用会不会改变系统数据。
同样是退款，可以拆成四种完全不同的能力：
- 查询退款资格；
- 计算建议退款金额；
- 创建待审批退款单；
- 正式执行退款。
把这四件事塞进一个万能接口，Agent 很方便，企业很危险。
Anthropic 将工作流和 Agent 做了一个很实用的区分：工作流沿预先定义的代码路径运行，Agent 则由模型动态决定步骤和工具。对于边界清楚的任务，工作流通常更稳定；只有路径难以提前写死、确实需要动态判断时，Agent 的灵活性才值得它带来的成本和风险。Anthropic：Building Effective Agents
第六，它以谁的身份做事？
很多企业给 Agent 接工具时，直接使用一个权限很大的公共服务账号。
这样做的结果是：系统知道某个接口被调用了，却不知道是哪一个 Agent、受谁委托、为了哪项任务、在什么权限范围内调用。
NIST 在 2026 年专门发布了 AI Agent 身份与授权概念文件，提出身份识别、授权、审计和不可抵赖等问题。世界经济论坛同年提出 Agent Capability and Authorization Profile，希望把 Agent 的委托政策、能力边界和运行监督写进一份可执行的授权档案。NIST、WEF
翻成企业能用的话，就是四个问题：
- 它是谁？
- 谁让它做这件事？
- 它最多能做到哪一步？
- 出事以后能不能还原全过程？
第七，什么情况必须交还给人？
“特殊情况请主管处理”没有告诉 Agent 什么叫特殊。
可执行的交接条件应该更具体，例如：身份信息无法匹配、两套系统状态冲突、政策没有覆盖当前商品、超过金额上限、连续两次工具调用失败，或者客户明确提出投诉和法律主张。
人工介入也不能只给 Agent 一个“呼叫人工”按钮。它应该把已经核实的事实、走过的步骤、发生冲突的规则和建议选项一起交过去。
否则员工接手以后还要从头查一遍，Agent 只是给流程增加了一次转发。
第八，怎样证明它真的做对了？
传统聊天机器人常用“回答看起来是否正确”做评测。进入业务流程以后，至少还要增加四层检查：
- 事实正确：订单、客户、金额和时间是否读对；
- 路径正确：该走的核验、审批和交接有没有走；
- 动作正确：工具、参数和执行次数是否正确；
- 业务有效：处理时长、人工接管率、错退率和客户重复投诉是否改善。
微软 2026 Work Trend Index 调研了 2 万名 AI 用户。即使在使用 Agent 较深入的 Frontier Professionals 中，也只有 25%表示 Agent 工作流、人工交接和质量标准已经在组织层面形成可重复文档。Microsoft 2026 Work Trend Index
这组数据是受访者自报，只能说明现状，不能证明因果。但它提醒我们：真正稀缺的已经不只是会写提示词的人，而是能把工作拆清楚、把评测建起来、把失败经验沉淀回流程的组织能力。
把前面的八组问题放进退款案例，大致会形成下面这条执行链：
图里最关键的节点是“风险与权限”。同一个 Agent 可以先帮助所有客户理解政策，却只被允许对少量低风险订单执行退款。能力范围和行动权限分开以后，企业才能逐步增加自动化比例，而不用在“完全不让做”和“全自动放权”之间二选一。
规则都写这么清楚了，还要 Agent 干什么？
这是一个很合理的反问。
如果每一种输入、路径和输出都能提前穷举，普通工作流、RPA 或业务系统就能完成任务。引入大模型只会增加成本和不确定性。
Agent 的价值出现在规则和现实之间那块长期存在的灰色地带：
- 用户用自然语言描述问题，表达不完整；
- 输入来自邮件、图片、合同和聊天记录；
- 下一步取决于前一步返回的新信息；
- 任务路径无法提前完全枚举；
- 需要在多个工具之间动态规划；
- 遇到模糊情况时，需要提出问题或请求判断。
所以，生产级设计通常不是让 Agent 接管整个流程。
更稳妥的结构是：
工作流守住主干，规则引擎处理硬条件，Agent 负责理解和动态判断，人类承担高风险决策与最终责任。
模型被放在它擅长的位置，确定性系统负责兜住底线。
别让 AI 根据制度文档自动生成“最终 SOP”
现在已经有不少工具可以把一堆制度自动整理成流程图、提示词甚至 Agent。
它们很适合生成第一版草稿，却无法替企业确认真实流程。
纸面 SOP 记录的是“应该怎么做”，系统日志记录的是“实际怎么做”，一线员工知道的是“为什么有时不能那么做”。三者经常不一致。
流程挖掘领域通常从事件日志出发：一条记录至少要能关联到某个业务案例、一次活动和一个时间点，再通过多条轨迹还原实际流程。ProcessMining.org
企业改造 SOP 时，可以把三类材料放在一起：
- 看制度和流程图，找到正式规则；
- 看工单、订单和审批日志，找到真实路径；
- 访谈一线员工，追问例外为什么发生。
模型可以帮助总结、对比和提出冲突，但业务负责人必须确认最终含义。
否则 AI 会把旧制度、临时习惯和错误操作一起整理得井井有条。
真要开始，先改一个“小而完整”的流程
别从“梳理全公司 SOP”开始。
挑一条满足四个条件的流程：发生频率高、结果能量化、存在一定语言理解或动态判断、出错以后容易发现和撤回。
第一轮只做一个小闭环。
比如退款场景，可以先让 Agent 完成资格核验和退款建议，把正式退款留给员工确认。项目组同时建设真实案例集，记录它在哪些分支走错、哪些信息经常缺失、哪些工具容易混淆。
等到事实准确率、路径合规率和人工接管条件都稳定，再开放低金额、低风险、可回滚的动作。
整个过程可以按五步推进：
- 选任务：说清楚哪个岗位的哪一步，而不是笼统地做“智能客服”；
- 还原现场：对照文档、日志和员工经验，找出真实流程；
- 重写契约：明确目标、状态、规则、工具、权限、例外和验收；
- 影子运行：Agent 给建议，人照常执行，对比路径和结果；
- 逐级授权：先读、再写草稿、再做低风险动作，最后才讨论更高自治。
Agent 项目的第一份重要交付物，不该是一段很长的系统提示词。
它应该是一张所有人都能共同检查的工作契约：业务能看懂规则，IT 能看懂系统边界，安全团队能看懂权限，管理者能看懂成败指标。
SOP 暴露的，其实是组织欠下的流程债
以前这笔债由员工承担。
字段口径不一致，老员工帮忙解释；制度没写例外，主管临场拍板；系统之间没有打通，基层员工复制粘贴；出了问题，再靠群消息和电话补救。
人很擅长在模糊环境里把事情凑合做完，所以企业一直感觉不到问题有多严重。
Agent 不会替组织长期掩盖这些缺口。它把模糊规则、数据冲突、权限混乱和责任不清同时暴露出来。
这并不是坏事。
当一家企业能够把一项工作描述清楚，让机器在边界内执行，让人能在关键点接管，并且用真实结果持续修正规则，这项能力就不再只属于某个老员工。
它开始变成可以复用、可以审计、也可以不断改进的组织资产。
到了这一步，Agent 才算真正开始干活。
参考资料
- ClawSphere 研究院，《什么是 AI Native 企业？从个人提效到组织重构的四阶段路线图》，2026。
- Microsoft，《2026 Work Trend Index》，2026。
- OpenAI，《A practical guide to building agents》。
- Anthropic，《Building Effective Agents》，2024。
- Nandi et al.，《SOP-Bench: Complex Industrial SOPs for Evaluating LLM Agents》，2025。
- Wang et al.，《SOP-Maze: Evaluating Large Language Models on Complicated Business Standard Operating Procedures》，2025。
- Ye et al.，《SOP-Agent: Empower General Purpose AI Agent with Domain-Specific SOPs》，2025。
- NIST NCCoE，《Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization》，2026。
- World Economic Forum，《AI Agents in Action》，2026。
- Object Management Group，BPMN 与 DMN 标准。
- van Dun et al.，《Process mining starts here: on expertise, exchange, and the gaps between》，2025。