给 Agent 写任务描述，你可能一直在用错误的姿势

你有没有遇到过这种情况：

把一个在 ChatGPT 里用得很顺手的 Prompt，原封不动地塞进 Agent 框架，然后眼睁睁看着它在第三步开始跑偏，第五步彻底失控，最后要么陷入死循环，要么输出一个完全不符合预期的结果？

我遇到过。而且不止一次。

最让我印象深刻的一次翻车：任务是"搜索竞品的最新定价信息，整理成对比表格"。在 ChatGPT 里，这句话加上几个格式要求，模型能给我一个漂亮的 Markdown 表格。但当我把同样的描述丢给 Agent，它在第二步搜索完之后，开始反复调用搜索工具——因为它不确定"搜索完"是不是一个终止信号，于是就一直搜，一直搜，直到 token 耗尽。

问题出在哪？不是模型变笨了，是我用错了写法。

---

为什么两者真的不一样

很多人把"给 Agent 写任务描述"等同于"写一个更长的 Prompt"，这个认知偏差是后续一切问题的根源。

本质区别在于执行模式：

ChatGPT Prompt：一次性对话。你输入，它输出，结束。模型只需要在单次响应里消化所有信息，然后生成结果。
Agent 任务描述：多步骤自主执行。Agent 会在整个执行过程中反复"回头查看"任务描述，用它来指导每一步的决策——调用哪个工具、判断是否继续、什么时候停止。

用一个类比：给 ChatGPT 写 Prompt，像是给搜索引擎下指令，你要把所有意图压缩进一句话；给 Agent 写任务描述，像是给新员工写 SOP，它要在接下来的几个小时里反复翻阅这份文件做决策。

这两件事，写法能一样吗？

我用 10 个真实任务（涵盖信息检索、数据处理、条件判断三类场景），分别用"ChatGPT 写法"和"Agent 写法"各跑了一遍，记录了跑偏次数和完成质量：

⚠️ 以上数据为作者基于实测记录的体感估算，仅供参考，不同环境下结果可能有差异。

同样的任务描述，ChatGPT 完成率普遍更高——不是因为 ChatGPT 更聪明，而是因为 ChatGPT 的执行模式对"模糊描述"的容忍度更高。Agent 需要更精确的指令。

下面，我把三个最容易搞混的点逐一拆开。

---

第一个搞混点：「目标描述」混入「行为约束」

你可能的错误认知

写 ChatGPT Prompt 时，我们习惯把"做什么"和"怎么做"混在一起：

"搜索竞品定价信息，只看官网来源，忽略论坛和二手信息，整理成 Markdown 表格，按价格从低到高排序。"

这句话在 ChatGPT 里完全没问题——模型一次性读完，一次性输出。

为什么在 Agent 里会出错

Agent 在执行第 1 步（搜索）时读了一遍任务描述，在执行第 3 步（排序）时又读了一遍。问题在于：混写的描述让 Agent 在不同步骤里提取到的"当前相关指令"不一样，它可能在第 3 步忘记"只看官网来源"这个约束，因为那句话在它看来更像是"搜索阶段"的描述。

正确做法：分层写

goal: "搜索主流竞品的最新定价信息，整理成对比表格"

constraints:
- 数据来源仅限官方网站，不采用论坛、评测文章或二手信息
- 如果某竞品官网无法访问，记录为"数据不可用"，不跳过

output:
format: "Markdown 表格"
sort_by: "price_asc"

Goal 和 Constraints 分开写，Agent 在每一步做决策时，都能清晰地区分"我要达成什么目标"和"我在任何时候都不能违反什么规则"。 一句话记忆点： Goal 是终点，Constraints 是护栏——终点只看一次，护栏要一直在。

---

第二个搞混点：用「Few-shot 示例」代替「状态转移描述」

你可能的错误认知

Few-shot 是 Prompt 工程里最好用的技巧之一。给 2-3 个例子，模型就能举一反三。很多人自然而然地把这个习惯带到了 Agent 任务描述里：

"示例1：搜索词'A'，返回结果，提取价格。示例2：搜索词'B'，返回结果，提取价格..."

为什么在 Agent 里会乱套

ChatGPT 看示例是为了"模仿输出格式"，只需要做一次。Agent 看示例是为了"理解我在什么情况下该做什么"——但示例描述的是"正常情况"，一旦遇到分支（比如搜索结果为空），Agent 找不到对应的示例，就会开始"自由发挥"。

我测试了一个含条件分支的任务："搜索关键词，如果结果为空则换词重试，最多重试 3 次"。

Few-shot 写法：Agent 在第一次搜索结果为空时，有 2/3 的概率直接输出"未找到结果"并终止，因为示例里没有"重试"的范例。
状态转移写法：Agent 正确执行了重试逻辑，且在第 3 次重试后按预期终止。

正确做法：显式状态转移

state_flow:
- state: "searching"
action: "使用当前关键词调用搜索工具"
transitions:
- condition: "搜索结果数量 > 0"
next_state: "extracting"
- condition: "搜索结果数量 == 0 AND 重试次数 < 3"
next_state: "retry_search"
action: "更换同义词重新搜索"
- condition: "搜索结果数量 == 0 AND 重试次数 >= 3"
next_state: "terminated"
action: "记录'未找到有效结果'并结束"

这不是在写代码，而是在用 Agent 能理解的方式描述"遇到不同情况该怎么办"。

一句话记忆点： 示例告诉 Agent"正常情况长什么样"，状态转移告诉 Agent"异常情况怎么处理"——后者才是 Agent 真正需要的。

---

第三个搞混点：用「角色设定」代替「工具使用权限声明」

你可能的错误认知

"你是一个专业的数据分析师，擅长从复杂数据中提取关键洞察"——这类角色设定在 ChatGPT 里能有效调整输出的专业度和风格。

很多人把这个习惯带进 Agent，以为给 Agent 设定好角色，它就知道该怎么用工具了。

为什么这在 Agent 里远远不够

Agent 的行为不是由"角色认知"驱动的，而是由工具可用性 + 调用规则驱动的。

我测试了一个"自动发邮件 + 记录日志"的任务：

只写角色的任务描述：

"你是一个高效的助理，负责处理邮件发送和日志记录工作。"

Agent 实际行为： 在 3/5 次测试中，Agent 调用了邮件工具，但没有调用日志工具——因为没有人告诉它"发完邮件之后必须记录日志"。 写清工具调用规则的任务描述：

tools:
- name: "send_email"
when_to_use: "当需要向用户发送通知时"
required_after: "任务执行完成"

- name: "write_log"
when_to_use: "每次调用 send_email 之后，无论成功或失败"
log_fields: ["timestamp", "recipient", "status", "error_message"]

Agent 实际行为： 5/5 次测试均正确执行了邮件发送 + 日志记录的完整流程。 一句话记忆点： 角色设定影响 Agent 的"气质"，工具权限声明决定 Agent 的"能力边界"——后者对行为的影响要大得多。

---

实战模板：可直接复用的 Agent 任务描述框架

把上面三个差异点综合起来，一个完整的 Agent 任务描述应该包含以下五个层次：

# Agent 任务描述标准框架

goal: |
# 用一句话描述最终目标，只写"做什么"，不写"怎么做"
[在这里填写任务目标]

constraints:
# 在整个执行过程中必须遵守的规则，任何步骤都不能违反
- [约束条件1]
- [约束条件2]

state_flow:
# 描述执行过程中的状态转移，重点是"异常情况怎么处理"
- state: "[状态名]"
action: "[在此状态下执行什么]"
transitions:
- condition: "[满足什么条件]"
next_state: "[进入下一个状态]"

tools:
# 声明可用工具及其调用规则
- name: "[工具名]"
when_to_use: "[什么情况下调用]"
dependencies: "[调用前需要完成什么]"

output:
# 明确定义最终输出的格式和内容
format: "[输出格式]"
required_fields: ["[字段1]", "[字段2]"]

三个难度递进的填写示例

简单单步任务（信息检索）：

goal: "查询当前主流大语言模型的上下文窗口大小"
constraints:
- 仅引用官方文档或官方博客，不引用第三方评测
- 如果官方文档未明确标注，记录为"未公开"
state_flow:
- state: "searching"
transitions:
- condition: "找到官方来源"
next_state: "completed"
- condition: "未找到官方来源"
next_state: "terminated"
action: "记录'未公开'"
tools:
- name: "web_search"
when_to_use: "初始搜索阶段"
output:
format: "Markdown 表格，列名：模型名称 | 上下文窗口 | 来源链接"

多步骤任务（数据处理）：

goal: "从给定的 CSV 文件中提取销售数据，计算各区域月均销售额，输出报告"
constraints:
- 不修改原始 CSV 文件
- 计算结果保留两位小数
- 如果某区域数据缺失超过 30%，标注"数据不完整"而非计算平均值
state_flow:
- state: "reading"
action: "读取 CSV 文件"
transitions:
- condition: "文件读取成功"
next_state: "validating"
- condition: "文件不存在或格式错误"
next_state: "error"
action: "输出错误信息并终止"
- state: "validating"
action: "检查数据完整性"
transitions:
- condition: "验证通过"
next_state: "calculating"
- state: "calculating"
action: "按区域分组，计算月均销售额"
transitions:
- condition: "计算完成"
next_state: "reporting"
tools:
- name: "file_reader"
when_to_use: "reading 状态"
- name: "data_calculator"
when_to_use: "calculating 状态"
output:
format: "Markdown 报告，包含数据摘要表格和异常标注"

核心差异对比表

---

文中所有实测都跑在 [api.884819.xyz](https://api.884819.xyz) 上——它同时支持 ChatGPT 和 Agent 接口，我可以用同一个平台做对照实验，省去了反复切换账号的麻烦。国产模型（Deepseek、通义千问等）完全免费，按量计费，测试成本很低。新用户注册即送体验 token，注册只需要用户名+密码，直接就能上手跑。

---

写给 Agent 的任务描述，本质是在写一份"可执行的工作流说明书"

回到最开始的问题：为什么同一句话，在 ChatGPT 里完美执行，在 Agent 里却翻车？

因为心智模型不一样。

给 ChatGPT 写 Prompt，你的心智模型是"我在和一个很聪明的人对话，我说清楚我要什么，它来帮我想怎么做"。

给 Agent 写任务描述，你的心智模型应该是"我在给一个会自主决策的系统设定规则，它会在接下来的执行过程中反复参照这份文件做判断——我写得越清楚，它跑偏的概率越低"。

这不是技巧层面的差异，是认知层面的升级。

30 秒自检清单

在你提交任何 Agent 任务描述之前，问自己三个问题：

1. 终止条件清晰吗？ Agent 在什么情况下应该停止？如果搜索失败、工具报错、数据缺失，它该怎么办？——如果你没写，它会自己决定，而那个决定很可能不是你想要的。

2. 约束条件独立了吗？ 你的限制条件是混在目标描述里，还是单独列出来的？——混写意味着 Agent 在执行中途可能"忘记"某些约束。

3. 工具调用顺序和依赖关系明确了吗？ 哪个工具在哪个步骤用？用完之后必须做什么？——如果没写，Agent 会按自己的理解决定，结果可能让你大吃一惊。

三个问题都能回答"是"，你的任务描述质量就已经超过了大多数人。

---

下一篇预告：

既然 Agent 任务描述要写状态转移，那问题来了——当 Agent 跑着跑着卡住了、或者陷入重复循环，你怎么在任务描述层面就把"自动恢复机制"写进去？

我整理了 5 种最常见的 Agent 卡死场景（死循环、工具超时、状态丢失、幻觉跳步、无限重试），以及对应的描述层修复方案。写好了，Agent 能自己爬出坑；没写，你只能手动重跑。下篇见。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #Agent开发 #Prompt技巧 #8848AI #人工智能 #工作流自动化 #AgentSDK #AI进阶