第3章 创建和第一次调整 Agent

创建 Agent 不是给聊天窗口换一个名字，而是为一类任务准备一套可重复的工作约定。本章不追求一次配置很多功能，只用一份虚构选题说明，完成“第一次测试—发现问题—只改一条规则—再次测试”。

五个组成部分，各自解决什么

可以把 Agent 想成一位刚入职的同事：

部分	它解决的问题	本章的练习写法
身份	它是谁、服务哪类任务	资料摘要助手（练习）
工作说明	它应该怎样处理任务	只提取依据、未知写待确认
能力	它能调用哪些专项工具	本章先不额外添加
资料	它可以依据什么输入	一份虚构选题说明
测试	怎样判断是否达到要求	同一资料前后复测

身份只是入口，工作说明才是日常行为规则；能力是可选工具，不是质量保证；资料提供依据，但不自动意味着 Agent 已完整读取；测试则把“感觉不错”变成可核对的结果。把五者混成一句“帮我做内容”，就很难知道问题出在哪里。

创建前先写设计卡

在当前账号看到新建 Agent 或模板入口后，先不要急着选择很多技能。写一张最小设计卡：

名称：资料摘要助手（练习）
任务：从虚构选题资料提取摘要、来源线索和待确认项
输入：本次提供的虚构选题说明
输出：3 条摘要、来源线索、待确认事项
边界：不补写姓名、日期、平台或传播结果；不发送、不发布
验收人：我自己逐条对照原文

如果当前账号只有默认 Agent，也可以直接在普通对话中按这张卡测试；不要为了“完成创建”而把未经验证的部署、记忆或日程当成必选步骤。

设置身份时，重点不是给 Agent 起一个可爱的称呼，而是让使用者一眼知道它负责什么。名称可以带岗位和场景，例如“资料摘要助手（练习）”，描述则补充输入和输出。这样做的好处是，当你以后有多个 Agent 时，不会把“内容起草”和“事实检查”误派给同一个角色。描述也不应写成“什么都能做”，因为越宽泛的身份越难验收。

工作说明要写成可以执行的规则，而不是口号。“认真一点”“专业一点”很难检查；“只使用指定资料，没有依据就标待确认”则可以在结果中逐项核对。说明中最好同时写顺序和异常处理：先提取，再分类；遇到缺失信息就停在待确认；不执行发送或发布。规则越清楚，第一次测试越容易发现是哪一条没有起作用。

能力和资料应当按需加入。技能可能改变处理方式，资料决定依据范围；两者都可能受账号、权限和文件格式影响。第一次测试不额外添加能力，是为了先验证 Agent 的基本工作说明。等基本路径稳定后，再一次加入一个能力并重复同一测试，才能知道变化来自哪里。

第一次测试：先看问题在哪里

使用下面的固定资料和测试文字：

你是“资料摘要助手（练习）”。
请只使用下面的虚构选题说明，输出：3 条摘要、来源线索、待确认事项。
没有依据的日期、姓名、平台和效果承诺写“待确认”。
不要连接外部账号、发送或公开发布。

虚构选题说明：准备一篇面向 AI 初学者的入门短文，要求少术语、步骤可跟做。

第一次结果重点看三件事：它是否真的只使用了这份资料；是否把“面向初学者、少术语”保留下来；是否把资料没有提供的日期、作者或平台标成待确认。不要因为句子顺畅，就跳过逐条核对。

现有的起名和自我介绍图片可以帮助理解“身份设置”的感觉，但它们不是质量证据：

如果画面中的姓名、身份或头像来自真实账号，正文只保留功能描述，截图应改用虚构练习身份。

发现问题：只指出一条可定位的缺口

假设第一次结果把“作者和发布日期待确认”写成了确定句子。不要立刻增加技能、上传更多资料或重写整套说明。先记录：

问题位置：待确认事项
观察到的结果：补写了资料中没有的日期或作者
依据：原始选题说明没有提供这些字段
需要改变的规则：未知字段必须写“待确认”
其他内容：保持不变

这一步把“我觉得不太对”变成了可以复查的调整目标。若第一次结果完全正确，就记录“核对后无需修改”，不人为制造错误；下一次可以用另一份虚构资料验证规则是否仍然清楚。

只增加一条规则，再次测试

把下面这条调整文字发送给同一个 Agent：

上一版把待确认项写成了确定事实。只增加一条规则：
没有原文依据的日期、姓名、平台和效果承诺必须标为“待确认”。
其他工作说明保持不变。请用同一份虚构选题说明重新测试，并列出本次变化。

复测时比较同一资料的前后结果。理想情况是只有待确认字段发生变化，摘要和来源线索保持原意；如果 Agent 顺手改了标题、增加了网络来源或声称已经发布，就把这些变化记录为不符合“只改一条规则”，退回继续核对。这样你学到的是迭代方法，而不是追求某次回复看起来更漂亮。

比较时可以使用一个简单的差异记录：

保持不变：{摘要、来源线索等已正确部分}
新增规则：{本次只增加的规则}
应该改变：{被指出的字段}
意外改变：{不应改变却被改动的内容}
人工决定：{继续测试 / 退回 / 停止使用}

这张记录让 Agent 的调整变成可回放的过程。若第二次结果仍然遗漏，同一份资料可以继续测试；若两次结果都正确，再用一份结构相近但内容不同的虚构资料做迁移验证。只有在不同输入下仍能遵守边界，才有理由把 Agent 说明保存下来长期使用。

记忆和日程只作边界说明

Coze 当前文档可能提供记忆、日程或其他工作台入口，但本章不把它们作为创建 Agent 的主流程。记忆解决的是是否长期保留某些信息，日程解决的是是否按计划运行；它们不能替代工作说明，也不能替代人工测试。第一次练习只使用当前对话和虚构资料，等后续章节专门讨论资料、记忆和日程。

迁移案例：学习资料助手

把选题说明换成一段虚构课程文字，身份改为“学习资料助手”，输出改成概念、例子、不会的问题和复习建议。新增边界是：课程没有讲到的知识点标为待查，不把 Agent 的解释当成教材结论。若只处理一段文字，普通对话足够；只有需要长期整理同一门课程时，才值得保存成专属 Agent 或项目。

失败排错

现象：创建入口找不到，或第一次测试结果漏掉待确认项。
最可能原因：当前账号没有独立 Agent 创建入口；工作说明只写了目标，没有写输入范围和未知处理；测试资料太长，无法定位问题。
先检查：当前对象是否正确、账号是否显示模板/云端 Agent 入口、工作说明是否包含边界、同一资料是否被重复使用。
修正或停止：没有入口就用默认 Agent 完成同一测试；只增加一条规则并复测，不同时改能力和资料。
恢复标准：同一资料前后差异可以指出，未知字段没有被偷偷补全，最终由人工决定是否继续配置。

本章产物与下一步

你应得到设计卡、第一次结果的问题记录、调整文字和复测结果。验收时问：身份是否清楚？工作说明是否可执行？资料范围是否可回指？能力是否真的需要？调整后是否只改变了指定规则？

不要把“创建成功”当成本章的终点。真正的终点是：你知道它为什么这样输出，能指出哪一段来自资料，能解释一次调整带来了什么变化，并且知道下一次遇到不同资料时要重新核对。若当前界面无法显示某项设置，也可以把该项标为待实测，先用固定 Prompt 完成低风险任务。

创建 Agent 的过程可以看成一次小型实验：先固定输入，再改变一个变量，最后比较结果。如果同时换了模型、技能、资料和工作说明，你即使看到了变化，也无法判断是哪一项造成的。新手最稳妥的做法是先用默认能力跑通，再逐项增加配置。每次测试都保留资料版本和规则版本，未来看到不同结果时才有回溯依据。

把输入固定下来还有一个实际好处：当结果变化时，你可以把差异归因于工作说明或能力设置，而不是资料本身变了。这个习惯会让后续排错更快，也能避免为了一个偶然结果反复修改 Agent。

如果 Agent 的第一次结果已经满足设计卡，也不要急着宣布“配置完成”。换一份结构相近的虚构资料再测一次，检查它是否只依赖某几个词语才表现良好。若第二份资料暴露出新问题，记录问题而不是不断叠加规则；当规则开始互相冲突时，回到任务目标，删掉不必要的要求。一个小而清楚的 Agent，通常比一份包含几十条口号的说明更容易维护。

测试记录还应注明测试时间、资料版本和当前 Agent 名称。以后界面或模型变化时，你才能判断是规则变了、资料变了，还是系统行为发生了变化。

若调整后结果变差，不要删除第一次结果。保留 v1 和 v2，写出退回原因，再决定是恢复上一条规则还是继续缩小任务。

这份版本记录也能帮助别人接手练习：他知道哪条规则经过测试，哪项能力尚未验证，哪些字段必须由人确认。

因此，本章的 Agent 是一个可复查的练习，而不是一次性演示。

后续章节会在此基础上增加资料和复用层级。

先把这次练习做稳，再扩展功能。

下一章会把“动作、对象、要求、格式、边界”拆开，学习如何把一句模糊需求变成可检查任务。

阅读第 4 章：把一句需求变成可检查任务。