第 3 课：派活的提示词设计

学习目标：

• 写一份自包含的委派提示词，不依赖子代理能看到你和编排者之间的对话历史
• 在委派提示词里明确写清楚任务的范围、边界，以及该用什么信息来源
• 说明「一个问题域一个代理」这条原则，以及违反它会带来什么后果

前置要求：完成第 2 课，理解编排者-子代理架构和上下文隔离 | 上一课 第 2 课 << | 下一课 第 4 课 >>

复习：子代理看不到的东西，都得你替它写进去

上一课讲过一个关键机制：「每个子代理都从一个全新、独立的上下文窗口开始。它看不到你的对话历史、你已经调用过的技能、以及已经读过的文件。」¹ 这句话到这一课要落到实处——它意味着，你在编排者这一层跟用户聊过的所有背景、之前几轮讨论出的取舍、用户随口补充的一句限制条件，子代理统统不知道。子代理知道的，只有你写进这次派工任务里的那些字。

这不是一句提醒，是一条硬约束：派活的提示词，质量上限决定了子代理产出的质量上限。提示词里没写清楚的东西，子代理要么猜，要么漏，要么自己编一个假设往下做——猜对了算你走运，猜错了这一份子任务基本等于白做。

自包含：这份提示词得自己把话说全

自包含：一份委派提示词读完之后，子代理不需要额外的背景就能准确判断出该做什么。判断一份提示词是不是自包含，有个简单的检验方法：把它单独摘出来，脱离你和编排者之间的全部上下文，读一遍——如果读完还需要靠「猜」才能补全任务细节，这份提示词就不合格。

拿第 1 课「调研三家云服务商定价」的例子举例。如果编排者派给子代理的任务只写了一句「查一下 AWS 的定价」，这句话对编排者自己来说信息量够——因为编排者的上下文里还留着「为什么要查」「查完要拿去跟谁对比」「对比维度是什么」这些背景。但子代理看不到这些，它拿到的就是孤零零一句「查一下 AWS 的定价」，只能自己猜：查哪几类产品的定价？只查现在的价格，还是要查最近一年的变化？查出来之后要交付成什么样子？每一个「猜」都是一次可能出错的赌博。

明确范围与约束：该做什么、不该做什么、用什么信息源

官方给出过一份「合格的子代理任务说明」该包含哪些要素的清单：「每个子代理都需要一个目标、一种输出格式、该用哪些工具和信息来源的指引，以及清楚的任务边界。没有详细的任务描述，Agent 之间会出现重复劳动、留下空白，或者找不到必要的信息。」²

拆开看，这份清单里「目标」和「输出格式」好理解，容易被忽略的是后两项——信息来源指引和任务边界。信息来源指引是告诉子代理该去哪里找答案：是查官网的定价页面，还是查第三方比价网站，还是两者都要、以官网为准。任务边界是告诉子代理这次只做这一部分，不要往外扩：只查现价，不用查历史价格变化；只查主力产品线，不用把所有冷门服务都列一遍。少了这两项，子代理容易两种走偏：要么查漏了你其实想要的信息，要么查得比你想要的多得多，浪费了本可以省下的工具调用和 token。

把云服务商调研的例子改写成一份自包含、有明确范围的任务说明，大概是这样：

这份说明单独拎出来，子代理不需要知道编排者内部讨论过什么，就能准确判断出「查什么、查到哪个程度、交付成什么样」。

反面例子：模糊指令会让子代理各凭本事

不写清楚范围和边界，具体会出什么问题，官方在实践中给出过真实的反例：「我们一开始允许主导 Agent 给出简单、简短的指令，比如『研究一下半导体短缺问题』，但发现这类指令往往模糊到子代理会曲解任务，或者跟别的 Agent 做了完全一样的搜索。」²

「研究一下半导体短缺问题」这句话，读起来像是给了任务，其实什么都没限定——从什么时间范围研究？关注供给端还是需求端还是政策影响？要写成什么形式交付？三个子代理拿到同一句模糊指令，很可能三个都往「查半导体短缺的成因」这个最容易想到的方向去搜，结果是三份高度重叠的调研，真正该被覆盖的其他角度（比如对下游行业的影响、各国的应对政策）反而没人碰。这正是上一课讲过的「重复劳动」问题在提示词层面的根源——不是子代理不听话，是任务说明本身没有把边界划清楚。

一个问题域一个代理

除了单份提示词要写清楚，多个子代理之间该怎么分工，也有一条能从官方实践里提炼出来的经验原则——官方没有给它起名字，这是本课的归纳：一个问题域一个代理——每个子代理应该只负责一类边界清晰的问题，而不是让一个子代理同时兼顾好几件不相关的事。

官方系统里有一个很直接的例子：专门设了一个 CitationAgent，「处理文档和调研报告，专门找出该在哪些具体位置加引用，确保所有论断都被正确归属到对应的来源。」² 找引用位置这件事，跟「调研某家公司的定价策略」是完全不同性质的工作——前者是核对、定位，后者是搜索、判断。把这两件事交给同一个子代理，它得在两种完全不同的思维模式之间来回切换，任务说明也会因为要兼顾两个目标而变得又长又杂，容易顾此失彼。拆成两个各自专注的子代理，每一个的任务说明才能保持简单、边界清晰——这也呼应了第 1 课的判断标准：能拆成互相独立的子任务，就值得拆。

小结

• 子代理看不到编排者的对话历史¹，这意味着一份委派提示词必须自包含：脱离对话背景单独读，也能让子代理准确判断出该做什么。
• 合格的任务说明要包含目标、输出格式、信息来源指引和清楚的任务边界，缺了这些，子代理之间会出现重复劳动、留下空白，或者找不到必要的信息²。
• 官方的真实反例证明，「研究一下半导体短缺问题」这类模糊指令，会让子代理曲解任务或者跟别的子代理做完全一样的搜索²——范围和边界不是可选项，是避免重复劳动的关键。
• 一个问题域一个代理（本课对官方实践的归纳）：每个子代理应该只负责一类边界清晰的问题，像专门设置 CitationAgent 处理引用定位这样，把性质不同的工作拆给不同的子代理²，任务说明才能保持简单、聚焦。
• 判断一份委派提示词合不合格，检验方法很简单：把它单独摘出来读一遍，看看子代理需不需要靠猜才能补全任务细节。

>> 第 4 课：协作模式：流水线、评审、投票