第 6A 章｜从 SOP 到智能体约束

第 6 章已经完成两件事：先按最近一次任务还原现状，再重新设计人、AI 与确定性系统的目标工作流。澄川项目组没有批准一个开放式销售 Agent，只批准了一个范围有限、带人工确认和失败回退的 CRM 更新预览流程。

但目标流程仍然不能直接交给工程师开发。流程图中的“读取会议记录”“检索批准资料”“生成字段建议”“销售确认”和“写入 CRM”，都还只是业务语言。它们没有回答系统从哪里获得输入、哪些资料具有权威性、哪些动作允许自动执行、什么状态算完成，以及失败后怎样停止和恢复。

本章位于流程重构与系统建设之间，负责完成一次显式转换：

真实任务
→ 现状流程
→ SOP
→ 目标流程
→ 业务约束版转化卡
→ 第 7 章的系统契约

这里说的“智能体约束”，指的是一组边界条件，业务、产品、工程、数据、风险各角色都能拿来检查：任务什么时候启动，谁对结果负责，AI 能读什么、做哪一步，哪些判断必须留给人，系统留什么日志，异常出现后怎么收尾，以及下一步用什么证据判断能不能构建、能不能试点。它不是一段超长提示词，也不要求提前把技术设计全部做完。

SOP 在这里解决什么问题

SOP 是 Standard Operating Procedure，通常译为标准作业程序或标准操作规程。它描述一项重复工作怎样在组织中被稳定执行。

一份可用于 AI 项目的 SOP，至少要让另一名合格执行者能够接手。他要能看出任务由什么事件或条件触发，谁发起、执行、审核并对结果负责，开始时需要哪些输入和业务状态。照着步骤往下走，他要能知道每一步做什么、在哪里发生判断、等待与交接；遇到缺失、冲突、权限不足或系统失败时，要知道怎么办。走到最后，他要能说出输出交给谁、怎样进入下一步、留下什么记录。

合格的 SOP 不是要把所有工作写成僵硬步骤，而是把那些本来只在少数人脑子里的稳定做法抽出来，让团队里其他人也能照着做、能检查、能维护。

六个容易混淆的对象

流程图、SOP、Checklist、模板、Prompt 和 Agent 规格说明经常被混在一起谈，但它们回答的问题并不相同。

流程图说明工作如何在角色与系统之间流转，画出步骤、角色、分支和系统，但它不能单独说明每一步的规则、异常和责任。SOP 在此之上补齐一项任务如何稳定执行：触发、输入、步骤、判断、异常、输出、记录和版本——不过 SOP 本身不能自动成为可运行系统。Checklist 只管执行前后检查什么，列必做项、通过条件和责任人，替代不了完整流程和异常路径；模板规定某类输出长什么样，给出字段、示例和反例，却说不清何时使用、依据什么生成。

再往系统一侧，Prompt 或 Instruction 描述模型如何生成或判断，写任务说明、上下文、格式和约束，但不能替代权限、状态、工具和责任边界。Agent 或 Workflow 规格说明回答系统如何运行目标流程，涵盖目标、输入、工具、状态、权限、人审、轨迹和评估，但同样不能替代真实流程证据和业务责任。

把 SOP 全文塞进 Prompt，不会自动得到可靠智能体。系统仍然不知道哪个数据源有效、哪个工具可以写入、人工确认怎样保存，以及一次工具超时后是否已经产生副作用。

SOP-first 不是要求所有任务都固定化

“没有清晰 SOP，就不应该急着做智能体应用”适用于稳定、重复、可执行的业务流程，例如客服政策答复、合同初审、课程资源审核、销售拜访准备或会后 CRM 更新。

开放式研究、复杂诊断、创意探索和软件研发不一定能先写成固定 SOP。对这些任务，更重要的是先写清另外几件事：要完成什么结果（Mission，任务目标）；允许做什么、禁止做什么（Policy，行为边界）；依据怎样获得、怎样核验（Evidence Protocol，证据规则）；可以调用哪些工具和数据（Tool Boundary，工具范围）；什么情况下必须停下或转人工（Stop Rule，停止条件）；以及怎样判断结果和运行过程算合格（Eval Contract，评估约定）。

因此，本书采用更精确的门槛：

对稳定业务流程，没有清晰 SOP，不进入智能体开发；对开放任务，没有明确目标、证据规则、工具边界、停止条件和责任主体，不进入高自主或生产部署。

先判断这条流程是否值得 SOP 化

不是所有流程都值得立刻标准化。第一个 SOP 智能体场景应优先选择高频、边界清楚、角色明确、规则可写、错误可发现，并且能较快看到真实或准真实任务的流程。澄川把观察窗口放在两到四周，只是为了让教学案例来得及看到重复任务，不是通用立项门槛；真实项目应按任务频率、风险和决策需要倒推周期。

具体可以依次问下去：这件事每天或每周反复发生，还是一年只出现一两次？触发、结束、输入和输出能不能说明白，还是目标和结束状态持续变化？执行者、审核者和负责人是否明确，还是完全依赖某个人临场协调？主要步骤和判断能够列出，还是主要依赖开放探索？错误可以发现、拦截、回退或转人工，还是一次错误就不可逆且无人负责？它对效率、质量、风险、体验或收入有实际影响，还是只是“看起来适合 AI”？较短周期内能否观察到真实或准真实任务，还是需要长期大集成后才知道是否有用？

这里仍然不能只看总分。若没有业务负责人、没有可用样本，或高风险动作没有明确的人工处理方式，即使价值很高，也不应纳入第一阶段的建设范围。

从真实案例生成 SOP，而不是从理想流程开始

第 6 章已经强调：现状流程必须来自最近一次真实任务，而不是制度文件或管理者描述。SOP 的形成顺序也应保留这项证据纪律。

选取最近一次任务
→ 按时间顺序复盘实际动作
→ 记录触发、输入、角色、系统、等待、返工、判断与输出
→ 比较多条任务，区分稳定部分与个别例外
→ 与制度、规则和负责人核对
→ 形成可执行 SOP 版本

现状事实、现行 SOP 和目标流程是三个不同对象：现状事实说明工作实际上怎样发生，风险是样本过少、不能代表全部任务；现行 SOP 说明组织要求工作怎样稳定执行，但文档可能过期或与现场脱节；目标流程描述改造后希望任务怎样完成，它可能只是尚未经过真实使用的设计假设。

Builder 需要显式记录三者的差异。现场人员绕开 SOP，可能是执行偏差，也可能说明 SOP 不可用、系统不支持或组织激励不一致。不能在没有证据时把任何一方自动当作正确答案。

SOP 先回答六个核心问题

把一份流程交给系统前，先检查它能否回答六个问题。

前两个关于人。谁做——发起人、执行者、审核者、负责人分别是谁；何时开始——什么事件和条件触发，什么情况明确不触发。这两层含糊，AI、人和系统的责任会混在一起，系统也会误启动、重复启动或漏启动。

中间两个关于材料和判断。输入什么——需要哪些字段、文档、对象，来自哪里、需要什么权限；如何判断——哪些规则、经验、授权和证据支持每一步结论。前者不清，系统会上下文缺失、越权或读错对象；后者不清，模型会把猜测写成业务结论。

最后两个关于收尾。异常怎么办——缺失、冲突、失败、升级、暂停、回退各走什么路径；只想顺利路径，真实任务会无法结束。输出给谁——输出什么结构、进入哪个下一步、留什么记录和版本；这层缺失，生成结束了，业务状态却没有改变。

若这六个问题仍然含糊，继续选择模型、搭知识库或接工具，只会把流程中的不确定性放大。

从 SOP 到智能体约束的映射

下面的映射表是本章的核心。左侧仍是业务流程，右侧开始进入系统设计。它要求每个重要约束都有明确落点，但不要求每项都建设独立技术层。

SOP 元素	在 Agent / Workflow 中的对应物	首轮需要回答的问题
触发条件	用户入口、事件、定时任务、Webhook 或人工启动	怎样避免重复触发和错误对象
角色	用户身份、审批人、负责人、交接对象	谁能读、写、确认和承担结果
输入	表单字段、业务对象、运行时上下文	必填项、来源、版本和权限是什么
步骤	工作流节点、任务状态、运行循环	哪些固定，哪些允许动态选择
判断规则	规则引擎、代码校验、Prompt、模型评审器	哪些必须确定性执行，哪些允许概率判断
知识资料	RAG、知识库、版本化文档、案例库	什么来源可支持什么主张，冲突时怎么办
系统动作	Tool、API、数据库或消息操作	调用身份、副作用、幂等和失败语义是什么
人审与异常	确认、驳回、修改、升级、降级、转人工和回退	谁接手、看什么、多久处理、怎样恢复
输出与记录	结构化输出、系统字段、Trace、审计日志	业务用户怎样使用，最终状态怎样核对
指标	评估数据集、监控指标、试点指标、发布条件	什么叫答对、可用、安全和稳定

映射完成后，需要特别区分“提示约束”和“系统约束”。有些约束只指导生成，例如要求输出区分客户原话与推断，落在 Prompt 里即可。结构类的约束——结果必须包含字段、来源和风险标记——应由 Schema 和代码校验兜住。权限类约束（AI 不能修改价格和正式商机阶段）要放在身份、字段白名单和服务端权限上；状态类约束（未经销售批准不能提交变更）要靠状态机与业务不变量。副作用类约束，比如写入超时后先查询状态、不生成新意图重试，属于工具契约与恢复协议；发布类约束（高风险样本未全部通过时不得进入试点）则由评估结果和发布条件执行。

提示词可以帮助模型遵守规则，但不能成为唯一控制边界。

形成业务约束版转化卡

完成第 6 章的目标流程后，先生成一张 SOP → Agent Constraint Card（业务约束版）。它是第 7 章的输入，不是一次性填完的项目总表。

这张卡分四块。第一块是基本信息：SOP 的名称与版本要能稳定引用；写清谁在什么场景完成什么任务；何时开始、什么情况不能启动；必要字段、文档和对象来自哪里；业务状态怎样才算真正结束。这一块还要写明当前证据来自课堂模拟、高保真案例、真实影子运行、受控真实试点还是第二团队真实复用，事实、判断和假设分别标记。

第二块是流程与边界：现状流程摘要来自观察到的步骤、等待和返工；目标流程摘要写删除、标准化、确定性自动化和 AI 辅助之后的路径。AI 可做要具体到检索、提取、分类、草稿或建议；AI 不做要写明最终承诺、高风险审批、越权读取或不可逆动作。人审节点写谁确认、看什么、允许什么操作；异常与回退写清缺失、冲突、权限、工具失败和用户拒绝时怎样结束。

第三块是系统与治理假设。业务约束阶段只需要写到候选程度：候选工具、来源和 Owner，尚不要求完整 Schema；最小必要的权限与数据边界、高风险禁区；用户看到什么、系统准备写入什么；必留哪些来源、人工修改、确认、状态和错误记录；主要风险，如越权、错误承诺、资料过期、重复副作用；以及业务、内容、技术、风险和项目的负责人。

第四块是评估与下一阶段：至少一条能走完主路径的正常样本，至少一条能暴露异常和人审的边界或失败样本；答对、可用、安全、稳定分别怎样观察；是否继续建设——继续、有条件继续、返工、暂停或终止；以及进入第 7 章前哪些契约必须补齐、谁负责。

完整空白模板和澄川已填示例见 SOP 到智能体约束转化卡。读本章叙述时，请对照业务约束版填写示例；不要只看下面这段摘要。

转化卡不是静态表，而是持续更新的项目主文档

一张表如果试图在第 6 章结束时填完上下文、工具、权限、评估、试点和产品化，会迫使学习者编造尚未验证的内容。更可用的做法是让同一张卡随着项目推进逐步补充。

本章形成业务约束版，转记第 6 章已经作出的建设决定，并列出进入第 7 章前必须补齐的系统入口。第 7 章在同一张卡上补上上下文、对象、工具、状态、权限、输出和运行轨迹，升级为系统约束版，回答接口与边界是否可以测试。第 8 章加入数据集、评分规则、失败分类、发布条件和事件响应，成为验证约束版。第 9 章的试点约束版写用户、任务范围、基线、指标、支持和退出条件，回答试点后怎样继续。第 10 章的资产维护版记录负责人、版本、复用接口、维护、成本和退役，回答哪些内容值得长期维护、复用或退役。

版本更新时保留被否决方案和变更理由。下一版覆盖上一版内容时，也要能追溯是哪一条现场证据、失败记录或阶段决定促成修改。

澄川案例：把目标流程写成业务约束

下面的摘要压缩自业务约束版填写示例。人物、样本和决定均为教学设定，不代表真实企业证据。

现行 SOP 只有三句教学摘录：客户会议当天更新需求、风险和下一步；引用产品能力以公司资料为准；价格、交期和商机阶段须经理确认。现场 8 次观察却显示，销售把查找资料和等待售前算进整理时间，也没有确认步骤。卡片把这三者分开写，避免把制度、现场和目标流程混成一份“已经存在的规格”。

在澄川的卡片上，SOP 名称是“客户会议后 CRM 更新准备与确认 v0.1”，任务是大客户销售在会议结束后形成可检查的 CRM 更新预览，并决定是否提交。触发条件收得很窄：会议已结束、已授权读取、且能关联到沙盒商机。无权限会议、未关联商机、正式环境和要求更新禁止字段的情况一律不触发。输入是会议转写、批准产品资料、沙盒商机当前值和销售的审阅操作。完成状态有明确定义：被批准字段已写入沙盒，系统重新查询并确认最终状态；“建议已生成”不算结束。

边界写得同样具体。AI 可做的是提取客户原话和候选行动项、检索批准资料、准备四类字段建议、标记不确定与冲突。AI 不做的是批准价格、交期、商机阶段，不决定资料权威性，不直接写正式 CRM，也不发送外部消息。人审由销售接受、修改、拒绝或升级建议，资料冲突交给内容负责人处理。关联对象、字段白名单、鉴权、差异生成、沙盒写入、结果查询和日志，全部交给确定性系统。异常各有着落：资料冲突时阻塞受影响字段；CRM 版本变化后重新生成；写入结果未知时查询原请求，不创建新意图重试。

初步验证准备了两个样本。正常样本是四类字段生成带来源的建议，销售修改一项后确认，沙盒状态与预览一致；失败样本是两份批准资料冲突时停止相关字段、保留其他草稿并交给内容负责人。卡片转记第 6 章的决定：“有条件继续”——仅建设固定受控工作流，不建设开放 Agent，也不允许正式环境自动写入。进入第 7 章前，还需补齐来源版本、业务对象、字段白名单、状态机、窄工具、幂等和运行轨迹。

这张业务约束卡没有假装系统已经设计完成。它只把第 6 章中已获证据支持的业务判断，转成第 7 章必须实现、验证并回写到同一张卡上的工程入口。

十个设计关注面

做一个 SOP 智能体应用，通常要同时考虑十个方面。

入口一组：用户从哪里进入、什么条件触发、输入怎么标准化。运行一组：Context（上下文）和证据从哪来，Workflow 或 Agent 怎样编排，Tool（工具）和系统动作有哪些，状态怎么管、失败怎么恢复。人审单算一项：放在哪一步、谁负责。治理一组：安全、权限和数据边界，评估标准和发布门槛，Trace（轨迹）、监控和运营。

这十个是设计时要检查的点，不是要求每个项目部署十个独立服务。轻量工作流可能在同一个应用里实现输入、编排、状态和工具调用，但组件合并不代表对应的责任和检查可以省掉。

第 7 章将把这些关注面压缩为任务、上下文、对象、工具、状态和轨迹六层契约。两种结构的关系是：十个关注面用于检查是否遗漏，六层契约用于组织可运行系统。

把目标流程决定交给系统设计

第 6A 章不再增加新的阶段决定。它把“目标流程值得建设”的业务决定，整理成下一章可以落实和测试的系统输入。

进入第 7 章前，至少应满足这些条件：现状流程来自实际任务或明确标记的模拟材料，现行 SOP、现场事实和目标流程没有被混写，任务触发、输入和完成状态可以说明。AI 可做与不可做已经具体到动作，每个高风险动作都有明确人工责任，至少一条异常能走到负责人、状态和恢复条件。候选 Context、工具、输出和必留记录已经列出，正常样本和失败样本已经保存，第 6 章的建设决定已被转记并写明范围、条件和下一负责人。

若卡片中大量出现“智能体自行判断”“需要时转人工”“系统自动处理”，说明边界仍然不可检查，应回到第 6 章返工。

常见错误

把制度或理想流程当成 SOP 事实

制度说明组织希望怎样工作，不能证明现场就是这样发生的。先还原最近一次任务，再比较制度与实际差异。

把 SOP 全文变成一个 Prompt

Prompt 不具备身份、权限、状态控制和外部副作用约束。SOP 里的内容要分别落到确定性规则、Context（上下文）、Tool（工具）、人审节点、状态机和 Eval（评估）里。

只写 AI 可做，不写 AI 不做

能力清单会自然扩张。禁止动作、字段和环境需要进入服务端控制，而不只是页面说明。

写“低置信度转人工”但没有交接设计

人工接手需要接收角色、所需依据、等待状态、允许动作、超时规则和恢复条件。只有一句“转人工”，异常仍然没有结束。

把所有任务都升级为 Agent

步骤固定、工具有限和分支可列时，受控 Workflow 通常更容易检查、评估和维护。只有路径确实需要动态选择时，才升级局部自主性。

一次填完未来所有字段

业务约束版只记录当前证据支持的内容。上下文、工具、评估和试点的细节应在相应章节验证后再补充，不得用想象填满表格。

你的练习

完成第 6 章的现状流程记录、目标流程设计和五分钟原型后，使用 SOP 到智能体约束转化卡 整理你的目标流程。可先对照澄川业务约束版，再填自己的项目；不要只抄结论句。

先写出任务触发、输入和真正完成状态。然后分别列出 AI 可做、AI 不做、人工决定和确定性系统动作。选择一条最可能发生的异常，写到明确负责人、状态、允许动作和恢复条件。

再把 SOP 元素映射到候选系统约束：哪些规则必须由代码执行，哪些需要 Context 来源与版本，哪些动作需要 Tool Contract，哪些判断需要人工确认，哪些失败应进入 Eval Dataset。

最后转记第 6 章已经作出的建设决定，并列出进入第 7 章前仍缺的约束。不要重新表决“是否建设”，也不要把未验证的工具、权限或收益写成已经确定的事实。

怎样判断答案是否合格

遮住系统名称和模型名称后，另一位读者仍能说明任务为什么开始、怎样结束、谁承担结果，以及哪类错误会阻止继续。

把 Prompt 假设为失效，再检查字段白名单、权限、状态和副作用是否仍然受控。若所有边界都依赖模型“听话”，转化卡不合格。

把正常路径移除，只看异常路径。若异常不能走到明确状态、负责人和恢复条件，仍需返工。

一份合格的业务约束卡可以直接交给业务、产品、工程和风险角色评审，并能列出第 7 章需要补齐的契约，而不是让工程师从流程图中自行猜测。

本章小结：先把流程写成约束，再把约束写成系统

SOP 的价值不在于多写一份文档，而在于把重复工作里的触发条件、输入、角色、判断点、异常处理、输出和责任，从个人经验里抽出来，变成团队能共用的东西。

做智能体应用时，不能把 SOP 一股脑塞进提示词；业务元素要分别落到各自该去的地方：入口处理触发，规则管确定性判断，对象管业务数据结构，Context（上下文）管资料来源，Tool（工具）管外部动作，状态机管流转与恢复，人审节点管授权，Trace（轨迹）记录运行过程，Eval（评估）判断结果是否合格。这样系统才跑得起来、停得下来、查得清楚、修得明白。

第 6 章回答“目标流程怎样工作”，本章回答“哪些边界必须先写清”，第 7 章才回答“这些边界怎样成为可运行契约”。

上一章：重构人—AI—系统工作流 ｜ 下一章：把业务变成可运行系统

本章来源与边界

本章由作者 kms9 根据原创配套图解《从 SOP 到智能体应用》整理，并结合澄川案例、各阶段决定、不同证据环境和第 7 章六层契约重新编排。图解正文共 22 页，PDF 另附独立授权页。

本章和配套 PDF 均采用 CC BY-SA 4.0许可；转载或改编时需要署名、提供许可链接、说明修改，并以相同许可分享改编内容。

SOP、流程图、Checklist、模板和 Prompt 的区分属于本书用于企业 AI 项目的工作定义；不同组织可以使用其他名称。SOP-first 主要适用于稳定、重复、可执行的业务流程，不应被解释为所有开放式 Agent 任务都必须先写成固定步骤。