第10章 给 Agent 一套稳定的工作说明

第 9 章的任务定义卡是给人看的：它说明我们要不要重复做一件事。工作说明则是给 Agent 看的操作协议：收到资料后先做什么，什么内容必须有依据，遇到冲突怎样停下来，输出前要检查什么。

工作说明不是越长越好，也不保证每次结果完全相同。它的价值在于把经常遗漏的要求放到同一个地方，让你能比较“这次为什么错了”，再针对性地修改。只要任务还在变化，工作说明就应当保留版本，而不是一次写完便当成定稿。

五层结构：每一层解决一个问题

可以把工作说明想成给新同事的入职卡，而不是一段神秘咒语：

1. 角色限定负责范围，例如“会议资料整理助手”，而不是“万能助理”。
2. 任务说明要完成的主要动作和产物。
3. 步骤规定先确认资料，再提取，再套模板，避免直接跳到结论。
4. 边界说明不能补写什么、不能代替谁做决定、不能连接哪些外部系统。
5. 检查把交付前的验收动作写出来，例如列出待确认项并回到原文核对。

这五层不是固定按钮，也不一定要分别放在五个输入框里。当前 Coze 可能让你把它作为 Agent 说明保存，也可能只能在对话中作为固定 Prompt 使用。重要的是内容层次，而不是界面上有没有一个叫“五层结构”的入口。

先谈优先级：冲突时听谁的

说明里最容易被忽略的是优先级。比如一条要求说“把所有栏目填完整”，另一条要求说“没有原文依据就写待确认”。如果没有优先级，Agent 可能为了排版完整而编造事实。初学者可以采用下面的顺序：

第一优先：输入资料中的明确事实和用户本轮纠正。
第二优先：不补写事实、保护隐私和需要人工确认的边界。
第三优先：输出模板、栏目顺序和语言风格。
第四优先：示例中的表达方式和排版偏好。

这不是 Coze 的系统设置，而是你写进工作说明的判断规则。它能帮助 Agent 在冲突时先报告问题，而不是自行挑一个看起来完整的答案。

主案例：第一版说明为什么还不够

下面是一个可运行但不够具体的第一版：

你是会议资料整理助手。收到会议纪要后，整理成目标、现状、行动、风险、待确认事项。
请尽量完整、清楚地输出方案。

它没有说明资料范围、证据要求和异常处理。“尽量完整”还可能诱导 Agent 补齐日期、负责人或预算。把它放在任务定义卡旁边看，缺口会更明显：没有规定先确认文件，没有规定冲突时怎么办，也没有写人工检查点。

修订版应是这样：

你是“会议资料整理助手”，帮助我把虚构或脱敏的会议纪要整理成可人工核对的行动方案初稿。

优先级：只使用当前提供的资料；没有原文依据就写“待确认”；不补写事实和敏感信息；输出格式服从前面三项边界。

工作流程：
1. 先确认收到的资料名称、版本线索和处理范围。
2. 只从资料中提取目标、现状、行动、风险和待确认事项。
3. 区分已经确定的内容、讨论建议和仍缺少的信息。
4. 按固定模板生成初稿，并在末尾列出人工核对点。

异常处理：资料缺失、文件冲突、输入超出会议资料范围，或用户要求发送/发布时，先暂停并说明问题，不继续生成结论。

禁止：不猜测日期、预算、负责人或外部事实；不替用户做最终决策；不发送邮件、不发布内容、不连接外部账号。
输出语言：中文。

第一版和修订版的差异不是“修订版更长”这么简单。它增加了可以观察的行为：先确认输入、遇到缺口停下、按证据分类、交付前列检查点。每一条新增规则都应该能对应一个真实翻车场景。

旧图 coze-ch10-02-instructions-draft.png 只展示输入草稿，不作为本章主流程证据。正文中的第一版/修订版差异直接用文字展示，避免让一张截图承担概念解释。

在 Coze 中先复述，再试跑

如果当前账号提供 Agent 说明或项目说明入口，可以把修订版放进去；如果没有，就在本轮对话中粘贴。入口名称、保存位置和可见范围以当前账号为准，不要因为看不到按钮就假设功能不存在，也不要把普通 Prompt 的一次性使用写成永久配置。

保存或粘贴后，先让 Agent 复述规则：

请在执行前复述你理解的工作说明，最多 5 条。
请特别说明：哪些内容必须来自资料，哪些情况要暂停并让我确认，哪些动作你不会执行。
如果说明之间有冲突，先列出冲突，不要执行任务。
工作说明：
{工作说明}

复述是低成本的验收。若它把“列出负责人”说成“确认负责人”，说明边界还不清楚；若它忽略“资料缺失就暂停”，就先改说明再上传会议纪要。

这张图要证明的是 Agent 是否理解优先级和暂停条件，而不是工作说明有没有被永久保存。即使复述正确，也要用虚构资料试跑一次。

资料、工作说明和本轮要求怎样分工

初学者常把所有内容都塞进工作说明，结果说明越来越长，反而难以判断错误来自哪里。可以把信息分成三层：工作说明保存“处理这类任务时始终遵守的规则”；资料文件保存本次任务的事实；本轮 Prompt 保存这一次的特殊要求，例如“只修改行动栏”。当三层内容冲突时，先暂停并指出冲突，不要默默用较新的聊天句子覆盖资料事实。

例如“不补写负责人”应长期放在工作说明；《XX项目第三次筹备会议纪要》中的负责人空缺属于资料事实；“这次只输出风险栏”属于本轮要求。这样分层后，下一次换资料时不用重写边界，换任务时也不会把旧会议内容误当成长期规则。

用最小测试验证一条新规则

每次修改工作说明，准备一份能触发问题的最小资料，而不是立刻换成一堆长文件。要测试“没有日期就待确认”，就提供一份明确没有日期的两行文本；要测试“文件冲突先暂停”，就提供两份同名但状态不同的虚构版本。测试的目标不是让 Agent 通过，而是观察它有没有按新增规则停在正确位置。通过后再用完整会议纪要复测，才能知道规则没有破坏原来的栏目结构。

异常处理不是一句“请谨慎”

把常见异常写成可执行的动作，Agent 才有机会停在正确的位置：

异常	看到的现象	工作说明应要求
资料缺失	只有文件名，没有正文	回显缺少的资料，暂停生成
文件冲突	两版纪要结论不同	列出冲突来源，让人选择版本
输入越界	用户要求补预算或发邮件	说明超出范围，不执行
结果不合模板	少了“风险”栏	标出缺失栏目，重新检查而非悄悄补写
需要外部权限	出现授权或发送提示	停在预览，等待人工确认

这样的写法比反复说“不要出错”更有用，因为它告诉你下一步应该看到什么。

迁移案例：商品资料整理

如果把工作说明迁移到商品资料，角色变成“商品信息整理助手”，输入变成虚构商品说明，输出栏目变成名称、已知规格、待补字段和引用依据。规则仍然是“无来源就待补充”，但新增边界是不能根据常识添加“耐用”“高品质”或价格承诺。迁移时要重新定义异常：尺寸字段缺失、单位不一致和同名版本冲突都应暂停核对。

迭代方法：一次只改一个原因

工作说明出现问题时，不要把所有规则重写一遍。先记录三件事：原句是什么，Agent 做了什么，哪条规则没有起作用。然后只改一处，再用相同资料复测。例如它把“讨论建议”写成“已确定”，就增加“输出时保留原文状态标签”，不必同时改角色、语气和文件命名。

建议给版本命名：meeting-plan-instructions-v1 是第一次可运行版，v2 只修复状态分类，v3 再处理文件冲突。版本号不是 Coze 必有的功能，可以在自己的文档中记录；如果当前界面支持版本或复制，就以真实入口为准。

失败排错：两条要求互相打架

现象：Agent 一边说“预算待确认”，一边又在结论中写“预算已安排”。

先检查：工作说明是否出现“尽量完整”“必须填满”等宽泛句子；示例是否含有具体预算；当前对话是否还带着旧版本资料。

修正：把“原文依据和不补写事实”放到优先级第一层，删除会诱导补齐的表达；明确遇到冲突先列问题，再等待确认。用一份只写“预算待确认”的虚构资料重新测试。

恢复标准：输出只保留原文事实，预算、负责人和日期明确标成待确认；Agent 能说出停止原因；未要求修改的栏目没有被顺手改写。

如果修订后出现新的问题，先回退到上一版说明，用同一份资料确认问题是否由新规则引入。保留一个可回退的版本，比把多次修改合成一段“最终说明”更容易排错。

工作说明的长度边界

说明写到一定长度后，继续增加句子未必会改善结果。可以把内容分成“每次都适用的规则”和“这次资料的补充说明”：前者保留在 Agent 说明或固定 Prompt，后者放在任务消息或项目文件中。若一条规则只有某一个项目会用，就不要塞进所有任务的长期说明，否则下一次换场景时会带入无关限制。

一个实用检查是删掉一句后再试跑：如果删掉后没有任何可观察差异，这句话可能只是重复解释；如果删掉后 Agent 开始补写事实，说明它是关键边界，应保留并放到更高优先级。这样迭代出来的说明通常更短，却更容易复查。

工作说明还要和输出模板对齐。说明里写“按五栏输出”，模板就应明确五栏的名称和缺失项写法；如果模板临时增加一栏，要同步检查说明的步骤和验收点。规则、模板和资料分别放在合适位置，后续换任务时才不会把旧栏目、旧示例一起带过去。

在实际使用中，先把工作说明作为普通对话输入一两次，观察 Agent 是否能复述和暂停，再决定是否放入长期说明。这样可以避免把还没测试的规则带进所有后续对话。若当前界面支持保存，保存前先复制一份纯文本备份；若不支持，备份本身就是可复用资产。

完成测试后，给这份说明加一句适用范围，例如“只用于脱敏项目资料的内部初稿”。范围越明确，越不容易被误带到客户沟通或公开发布任务中。

本章产物与验收

本章应产出一份有版本号的 Agent 工作说明，以及一张第一版/修订版差异记录。人工检查：

• 角色是否只覆盖一个清楚的任务？
• 优先级是否解决“完整输出”和“不得补写”的冲突？
• 步骤是否先确认输入，再处理，再检查？
• 缺资料、冲突、越界和权限请求是否都有暂停方式？
• 说明是一次性 Prompt 还是可保存设置，是否与当前账号真实情况一致？
• 使用相同资料复测后，是否只改变了预期问题？

本章小结与下一步

工作说明的核心不是堆字，而是把角色、优先级、流程、边界和异常处理写成可检查的协议。下一章继续解决“结果长什么样、怎样才算合格”，用模板、示例和验收标准把输出变得更容易比较。

阅读第 11 章：让输出更稳定。