别再把 SOP 直接丢给 Agent 了，它真的看不懂

花椒技术 2026-08-19 0 阅读12分钟

别再把 SOP 直接丢给 Agent 了，它真的看不懂

本文来自花椒技术部真实工程实践。

如果你也在关注 AI 工程化、企业 Agent、MCP、Skill 或研发工具链，文末有「花椒技术交流群」入口，每日帮你从海量信息中捞干货，每天几分钟，快人一步看懂 AI 趋势。

最近很多团队都在试着把部门里的 SOP 交给 Agent。

想法很自然：既然流程已经写好了，那是不是把文档丢进去，再补几句 Prompt，Agent 就能照着干了？

实际跑起来经常不是这样。

同一份 SOP，新同事照着做都还要问老同事几轮。到了 Agent 这里，那些没写出来的默认知识不会自动出现，只会变成它执行时反复猜的地方。

比如：

• 什么时候才算这个任务应该开始？
• 材料不够时，是先继续写，还是先追问？
• 哪些判断来自规则，哪些判断要让人拍板？
• 结果做到什么程度才算能交付？

这些在人那里经常是“心里有数”的东西，在 Agent 这里都得明写。

所以我们后来判断：写给人的 SOP，不等于 Agent 能执行的 Skill。中间缺的是一整层可执行语义，不是多写几句 Prompt。

这篇就聊一个很具体的问题：一份 SOP 到底要补齐哪些东西，才可能变成 Agent 真能执行、能验收、能维护的 Skill。

先说结论：Agent 最容易丢的不是格式，是默认知识

很多人第一次把 SOP 交给 Agent，会先去优化话术。

比如把“帮我整理一下”改成“你是一个资深运营专家，请严格按照以下步骤……”，再加上输出格式、语气要求和注意事项。

这些有用，但不够。

真正让结果跑偏的，往往是默认知识缺失。语气和格式反倒容易补。

人写 SOP 的时候，会天然省略一部分内容。因为默认读者是同事，是熟手，至少也是一个会追问的人。

文档里写一句：

根据这批素材整理一篇品牌文章。

熟手看到这句话，脑子里会自动补很多东西：

• 先判断素材够不够；
• 缺关键信息就先问，不要硬写；
• 写法方向要先确认；
• 文章骨架通过以后再展开；
• 不满意就回到当前章节改，不要直接推进到结尾；
• 最后还要按品牌规范检查一遍。

但 Agent 不知道这些。你没写，它就只能猜。

猜对的时候，你会觉得模型很聪明；猜错的时候，问题通常不会直接暴露成一个报错，而是变成方向偏了、口径错了、结果看着完整但不能用。

这也是 SOP 转 Skill 最容易被低估的地方：关键不是复制流程，而是把人脑里的默认判断补出来。

一份 SOP 交给 Agent 前，先补这 6 件事

我们内部做 Skill 沉淀时，会先问 6 个问题。

这 6 个问题不复杂，但很管用。它们可以帮你判断：这份 SOP 现在到底只是写给人看的说明，还是已经接近 Agent 能执行的能力包。

1. 什么时候开始做

Agent 要先知道：当前请求是不是这个任务。

很多 SOP 默认人能判断任务边界。比如用户发来一堆素材，到底是要写文章、整理提纲、提炼观点，还是只想让你帮他判断素材够不够？人能根据上下文猜，Agent 如果没有入口判断，就容易一上来直接执行。

这里要写清楚：

• 什么输入会触发这个 Skill；
• 什么输入不属于这个 Skill；
• 材料缺到什么程度要先追问；
• 任务是否已经到了该接手的阶段。

如果这一步没写，后面步骤再详细也没用。它可能从错误入口开始，一路认真地跑偏。

2. 先做什么，再做什么

流程顺序不能只靠“按常识来”。

有些任务要先补信息，再生成结果；有些任务要先看规则，再做判断；有些任务中途发现材料不够，就应该停下来追问，而不是继续往下编。

对 Agent 来说，顺序尤其重要，因为它很容易把“看起来能完成”当成“应该继续完成”。

这里要写清楚：

• 第一步先判断什么；
• 哪一步可以继续，哪一步必须等待；
• 失败时回到哪里；
• 用户修改方向时，从哪一步重新进入。

这部分决定了 Skill 是一条可控流程，还是一段“生成完再说”的 Prompt。

3. 凭什么判断

很多业务判断不是模型突然变聪明就能解决的。

它们来自规则、口径、案例、模板和反例。

比如文章怎么判断“像不像品牌稿”，运营诊断怎么判断“头部、腰部、尾部”，后台查询怎么判断“能不能继续执行”。这些判断如果只写成一句“请专业判断”，最后大概率会变成模型拿通用语料硬猜。

这里要写清楚：

• 判断依据来自哪份规则；
• 哪些案例可以参考；
• 哪些反例必须避开；
• 什么时候读哪一份知识，不要一次性全塞进上下文。

所以 Skill 里通常会有 references。它更像判断依据区，而不是资料堆放区。

4. 哪些动作交给系统

并不是所有动作都应该交给模型。

有些适合模型做，比如识别状态、整理结构、起草内容、归纳差异。有些更适合脚本、接口或确定性工具做，比如计算、校验、查询、写入。

还有一些动作不应该自动执行，比如影响范围大的修改、高风险操作、最终业务拍板。

这里要写清楚：

• 哪些动作由模型完成；
• 哪些动作交给脚本或工具；
• 哪些动作只给建议，不直接落地；
• 哪些动作必须等待人确认。

这一步如果不分清，最常见的问题是：模型把本该计算的数字编出来，把本该确认的决策直接替你做掉。

5. 何时必须让人确认

很多 Agent 翻车，并不是卡在“不会做”，而是太顺滑地继续做了。

方向没确认，继续写；影响范围没确认，继续改；用户其实不满意，它还是推进到下一步。

Skill 里需要明确 confirmation gate，也就是人机确认点。

常见确认点包括：

• 写法方向确认；
• 文章骨架确认；
• 关键字段或查询范围确认；
• 高风险动作确认；
• 结果发布或写入前确认。

确认点的作用不是拖慢流程，而是避免 Agent 把错误一路放大。

6. 怎样才算完成

人和人协作时，“差不多”有时能成立。

Agent 不行。

如果不写完成标准，它可能给你一个看起来很完整、但没法验收的结果。

这里要写清楚：

• 输出格式是什么；
• 必须包含哪些部分；
• 哪些检查项必须通过；
• 失败时怎样说明；
• 无结果时是不是也算一种有效结果。

完成标准写清楚以后，Skill 才能被验收，也才可能被维护。

Skill 不是一段 Prompt，它更像一个能力包

如果把上面 6 件事补齐，Skill 就不再只是一段提示词。

它至少会包含几类东西。

每个目录不一定都要有，但职责要分清。

SKILL.md 更像任务调度和流程编排，负责说明什么时候命中、先问什么、按什么顺序推进、哪里停下来确认、失败怎么处理。

references 放判断依据，比如规则、口径、案例、模板和反例。它解决的是“凭什么判断”。

scripts 放确定性动作，比如校验、计算、接口封装。它解决的是“哪些动作不能靠模型自由发挥”。

assets 放输入输出模板、示例素材、配图提示词等交付相关材料。它解决的是“最后交付成什么样”。

agents/openai.yaml 这类配置则按需承载运行侧配置，不是每个纯方法型 Skill 都一定需要复杂配置。

所以一个可维护的 Skill，至少要回答两类问题：

流程问题：什么时候开始、先做什么、在哪里确认、怎么结束。
依据问题：凭什么判断、调用什么能力、结果怎么验收。

如果只有一段 Prompt，它通常只能解决眼前这一次对话。
如果变成 Skill，它就开始具备团队复用和持续维护的可能。

一个纯 Skill 什么时候就够了

并不是所有 Agent 应用一上来都要接 RAG、Tool、Gateway 或独立 UI。

有些任务第一层先落 Skill 就够了。

判断标准也很简单：

比如一类任务主要依赖追问、判断、结构和表达，规则相对稳定，不需要实时读取外部数据，也不需要直接写入业务系统。它最该先补的是方法层，重系统可以往后放。

这类任务适合先做纯 Skill：

• 根据素材整理文章；
• 根据固定口径做运营诊断；
• 按团队规则生成说明文档；
• 按模板整理发布前检查；
• 按已有规范做初步审查。

反过来，如果任务必须读取实时知识、调用内部系统、处理权限责任或提供复杂交互体验，那就不能只靠 Skill。

可以粗略这样判断：

知识经常变：考虑接检索或知识库。
结果必须真实落地：考虑接工具或脚本。
涉及内部系统和权限：考虑 Gateway / 业务能力连接。
聊天入口装不下流程：考虑独立 UI。

先写 Skill，不代表后面不接能力。它只是把第一层最容易失控的方法问题先固定下来。

拿文章创作助手看一下，为什么它不需要一上来写脚本

我们内部有一个文章创作助手·运营版，服务于生态运营部内容组。它接收结构化素材，按照品牌规范整理成可以发布的文章。

这个案例很适合说明“纯 Skill”。

它的难点主要在编辑方法，不在计算和接口调用：

• 用户现在是空想法、简单 brief、完整素材，还是已经写到一半？
• 缺少具体经历、数据、反例、判断依据时，应该怎么追问？
• 写法方向什么时候让用户选？
• 文章骨架什么时候确认？
• 每一节不满意时，是回到当前节改，还是重开结构？
• 最后怎样自检和交付？

这类任务如果直接写成“请帮我写一篇文章”，很容易得到一篇结构完整但方向不对的稿子。

所以它没有先上复杂脚本，而是把流程拆成了 6 步：

1. 识别当前状态
2. 针对性追问
3. 选择写法方向
4. 确认文章骨架
5. 逐节起草
6. 自检与交付

中间还有三个确认点：

确认写法方向
确认文章骨架
逐节确认内容

这个 Skill 的稳定性，来自“什么时候让人做决定”被写清楚了，而不是指望模型自己更会写。

它的目录也比较轻：

wechat-article-author/
├── SKILL.md
└── references/
    ├── skeletons.md
    ├── recommendation-dimensions.md
    ├── wechat-domain-knowledge.md
    ├── illustration-templates.md
    └── anti-ai-checklist.md

没有 scripts 也成立，因为这件事的确定性主要来自流程约束、人机确认和输出检查，而不是计算或接口。

这也是很多团队做 Agent 时容易忽略的一点：稳定性不只来自代码，有些稳定性来自流程边界写得足够清楚。

把部门 SOP 改成 Skill，可以按这张清单检查

如果你手里已经有一份 SOP，可以先不用急着写 Prompt。

先按下面这张 checklist 过一遍。

1. 任务入口

• 用户说什么时命中这个 Skill？
• 哪些请求不应该命中？
• 材料不够时先追问什么？
• 什么情况下直接拒绝或转人工？

2. 执行顺序

• 第一件事是什么？
• 哪些步骤必须串行？
• 哪些步骤可以跳过？
• 中途失败时回到哪里？
• 用户改方向时从哪一步重新开始？

3. 判断依据

• 判断来自规则、案例、模板还是历史口径？
• 哪些依据必须随任务加载？
• 哪些依据只在特定阶段加载？
• 有没有反例和禁区？

4. 能力边界

• 哪些事情由模型判断？
• 哪些事情交给脚本或工具？
• 哪些事情只输出建议？
• 哪些事情不能自动执行？

5. 人机确认

• 哪些节点必须让人确认？
• 用户不确认时流程怎么停？
• 用户否定结果时回到哪一步？
• 高风险动作有没有单独确认？

6. 交付验收

• 最终输出是什么格式？
• 必须包含哪些内容？
• 怎么判断完成？
• 失败、无结果、信息不足时怎么返回？
• 后续维护谁来改规则和案例？

如果这些问题回答不出来，说明你还没有真正写出 Skill，只是把 SOP 换了一种说法。

最后：别让 Agent 猜你的业务常识

把 SOP 交给 Agent，不能只是把文档复制过去。

真正要做的是把那些原本藏在人脑里的默认知识补出来：

• 什么时候开始；
• 先做什么；
• 凭什么判断；
• 哪些动作交给系统；
• 哪里必须让人确认；
• 怎样才算完成。

这 6 件事补齐以后，Agent 才会少猜一点，结果也才更容易验收和维护。

所以如果你正在做部门 Agent，不妨先从一份最常用的 SOP 开始。

不要先问“模型能不能完成”。
先问一句更具体的：

这份 SOP 里，哪些判断其实还藏在熟手脑子里？

把这些判断写出来，才是 SOP 变成 Skill 的第一步。

花椒技术交流群

还在孤军研究 AI 工程化、AI 编程、Agent 落地，没人同行交流、没人拆解实战？
这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手真实实战落地。想紧跟 AI 前沿动态、交流工程落地经验、少走踩坑弯路，欢迎直接加入**「花椒技术交流群」**。群内专属福利拉满：每日精选 AI 行业日报、文章独家延伸资料、文中未展开的技术细节，全部同步共享。