一、能力和入口

工作流是能力：给它一个主题，它给你文案和配图提示词。它不会主动说话。 智能体是入口：用户跟它聊天，它判断什么时候调哪个能力。 所以工作流做得再好，入口没挂好，用户就用不上。这两件事的验收标准不一样。

工作流看「能不能跑通」，智能体看「该调的时候调不调」。后者是概率问题，不是能不能的问题。

二、说明怎么写：四份说明的对照

「通用工具」这四个字，什么都盖，什么都不指。五句请求里它一句都对不上。 「写推文」稍好一点，只对上了含「推文」那一句——另外两句该调的它都没接住。 两份详细说明都是 3 / 5。 这个 3 不是「只对了三个」，是满分——五句里三句该调、两句不该调，它全判对了。

三、说明不是简介，是触发条件

写说明的时候别想「这是个什么工具」，想「用户说什么话的时候该用它」。 具体做法：把用户可能说的五句话列出来，全塞进说明里。 「用户提到写文案、写推文、发朋友圈、出海报、出图文内容时调用」——这句话就是五句用户原话的压缩版。

反过来，「推文生成工具」这种写法是介绍，不是条件。模型读完不知道什么时候用。

四、好说明的三部分

三部分里第一部分最关键。第二、三部分是给模型参考的，帮它判断「这件事我办得了吗」。 「输出什么」这一部分还有个作用：模型会拿它跟用户的要求比对。 用户要图片，说明里写输出是文字， 它就不调了。

五、挂上之后的第一次测试

三句话：一句该调的、一句不该调的、一句含糊的。 该调没调 → 说明写窄了。加同义词（写文案、写推文、写稿子）。 不该调却调了 → 说明写宽了。加限定条件（仅限图文内容）。

含糊的看它怎么办：追问一句，还是硬调？两种都能接受，但你要知道它选哪种。 第三种最值得试。用户说话本来就不清楚，模型这时候追问比硬调好——追问属于对话流的能力，第 13 章会讲。

六、还有两处容易忘

一、工作流改了要重新发布。 发布之后智能体才看到新版本。 表现是「我明明改了，它还是老样子」——十次里有八次是这个。 二、人设里要提一句这个能力。 如果人设写「你是售后客服」，然后又挂了「推文生成器」， 模型会犹豫：客服为什么要写推文？ 所以要么人设写宽一点（「你是内容助手」），要么在能力说明里写清适用场景。

人设和能力打架，模型会选择一个最保守的做法：不调。

七、到这里这个案例就完了

五步链、九个章节、一个智能体入口。回头看，用到的都是前七章的东西： 插件（抓热点）、提示词（写文案）、代码节点（转提示词）、图像生成（出图）、结束节点（交付）、 智能体（入口）。 没有一样是新东西。这一章的价值不在学新功能，在看它们怎么拼。

后面第 9 到 16 章八个案例，形状全是这个：一条链加一个入口。换掉的只是中间那几步。

八、动手 Demo：挂给智能体：说明怎么写它才会调

四份说明，五句请求。看每份说明判对几次。 判法是「说明和这句话有没有一个共同的词」——真模型理解语义，这里只比字面。

DESC = [
    (u'推文生成器', u'写推文'),
    (u'推文生成器', u'用户要生成图文推文、需要配图和文案时调用，输入一个主题词'),
    (u'workflow_3',  u'通用工具'),
    (u'文案助手',   u'用户提到写文案、写推文、发朋友圈、出海报、出图文内容时调用'),
]

def will_call(name, desc, ask):
    return bool(set(Q._grams(desc)) & set(Q._grams(ask)))

实跑输出：

--------------------------------------------------------------------
挂给智能体：说明怎么写它才会调
--------------------------------------------------------------------


  ① 四份说明，五句请求
  --------------------------------------------------------------------

| 工作流名 | 说明 | 判断会调的次数 |
|---|---|---:|
| 推文生成器 | 写推文 | 1 / 5 |
| 推文生成器 | 用户要生成图文推文、需要配图和文案时调用，输入一个… | 3 / 5 |
| workflow_3 | 通用工具 | 0 / 5 |
| 文案助手 | 用户提到写文案、写推文、发朋友圈、出海报、出图文内… | 3 / 5 |


  ② 抽象说明的问题
  --------------------------------------------------------------------
  「通用工具」这四个字，什么都盖，什么都不指。五句请求里它一句都对不上。
  「写推文」稍好一点，只对上了含「推文」那一句——另外两句该调的它都没接住。
  两份详细说明都是 3 / 5。
  这个 3 不是「只对了三个」，是满分——五句里三句该调、两句不该调，它全判对了。
  说明不是简介，是触发条件。 写成简介，它就永远不被触发。

  ③ 好说明的三个部分
  --------------------------------------------------------------------

| 部分 | 写什么 | 例子 |
|---|---|---|
| 什么时候用 | 用户会说的话 | 用户提到写文案、发朋友圈、出海报时 |
| 输入什么 | 要哪些参数 | 一个主题词，或一段原文 |
| 输出什么 | 给回什么 | 文案与配图提示词 |

  三部分里第一部分最关键。写这一部分的方法：把用户可能说的话列五句出来。

  ④ 挂上之后的第一次测试
  --------------------------------------------------------------------
  三句话：一句该调的、一句不该调的、一句含糊的。
  该调没调 → 说明写窄了，加同义词。
  不该调却调了 → 说明写宽了，加限定条件。
  含糊的看它怎么办——追问还是硬调，两种都能接受，但要知道它选哪种。

  ⑤ 还有一处容易忘
  --------------------------------------------------------------------
  工作流改了要重新发布。发布之后智能体才看到新版本。
  表现是「我明明改了，它还是老样子」——十次里有八次是没重新发布。
  ! 这一节和第 3.1 节讲插件描述是同一件事：模型只读到你写的那几个字。
  写「通用工具」它就不调，写「用户要生成图文推文时调用」它才调。

①第一张表四行，第三列是判对次数：「通用工具」0、「写推文」1、两份详细 3、3。 ②注意这个判法是「有没有共同的词」，不是余弦相似度。 用余弦会得出「说明写得越长越难被调」的假结论——说明长，分母就大。 ③两份详细说明都是 3 / 5，但那 3 是满分：五句里三句该调、两句不该调，全判对。 ④第二段讲为什么抽象说明不行：「通用工具」什么都盖，什么都不指，一句都对不上。 ⑤最后那段是最容易忘的：工作流改了要重新发布。十次「我明明改了」有八次是这个。

30 秒实验

1. 把你的工作流说明改成「用户说这五句话时调用」，把你想到的五句话全写进去。
2. 挂上之后试三句：该调的、不该调的、含糊的。三个都记下结果。
3. 检查一下你的智能体人设和挂的能力有没有打架。打架的话模型会选最保守的做法：不调。

常见误区

1. 「说明写个名字就行。」名字是介绍，不是触发条件。模型读不出什么时候该用。
2. 「说明写越详细越好。」详细不等于覆盖用户说法。要写用户会说的话，不是功能介绍。
3. 「改了工作流立刻生效。」要重新发布。十次「我明明改了」有八次是没发。

第一个案例完了。下一章换主题：让智能体做事而不只是写字——从一句话生成一份 PPT。

• ☐ （本篇完，下一篇 9.1 智能体开发设计思路）

相关笔记

• 什么是插件：插件描述怎么写
• 完整工作流测试：端到端测试
• 扣子平台设置提示词案例：提示词该放哪个位置
• 🐦 扣子开发 AI Agent · 索引