怎样把 Prompt 写成 Agent 真能执行的任务

从成功标准、上下文、工具权限、输出协议到持续评测，写出可执行、可验证、可迭代的 Agent Prompt。

更新于 2026年8月17日约 8 分钟阅读

我是一个 AI Native 的 AI Agent 开发工程师。能可靠交给 Agent 的执行工作，我不会留给自己。资料检索、代码修改、测试和重复操作都可以交出去，我要做的是把目标说清楚，划定权限，决定怎样验收。

这也是我判断 Prompt 好坏的标准。一个 Prompt 写得漂亮没有用，能让 Agent 在真实环境里稳定完成任务，才算写对。

很多失败的 Prompt 都很勤奋。它会要求模型深入思考、反复检查、搜索很多轮，也会塞进一长串语气和格式要求。结果仍然可能偏题、越权，或者交出一份看似完整却无法验证的答案。问题通常不在文字长度，也不在用了多少提示词技巧，而在任务本身没有定义完整。

写 Prompt 以前，先定义成功

Anthropic 的 Prompt engineering 概览把准备工作放在技巧之前。先有清晰的成功标准和可以验证结果的测试，再去调整 Prompt。

这个顺序很重要。没有成功标准，所谓优化只能依赖感觉。答案变长了，看起来更专业了，格式更整齐了，都不能证明任务完成得更好。

以代码修复为例，“修好登录问题”只描述了方向。可验收的目标还需要说明复现条件、预期行为、不能破坏的已有功能，以及应该通过哪些测试。研究任务也一样。“分析三款产品”缺少使用者、决策条件和证据要求，最后很容易得到一份百科式介绍。

写 Prompt 前，我会先回答两个问题。

这次结果要支持什么决定或动作。
我准备用什么证据判断它已经完成。

如果这两个问题还没有答案，继续润色指令通常没有意义。失败也未必都能靠 Prompt 修复。缺少数据、工具不合适、模型能力不足、上下文过期，都会让结果失真。Prompt 只能组织现有能力，不能凭空补出系统没有的条件。

把长期规则和本次任务分开

OpenAI 的 Prompt engineering 指南把高优先级指令和运行时输入分开。前者规定长期有效的行为，后者承载本次任务的数据。它们很像函数定义和函数参数。

在 Agent 项目里，稳定规则适合放在 system 或 developer 层。这里可以写角色职责、安全边界、工具使用原则和长期输出规范。用户这一次要处理的文件、问题、时间范围和交付内容，则放在 user 输入里。

混在一起会带来两个麻烦。每次任务都要复制整套规则，修改时容易出现多个版本。外部资料也可能被误当成指令，尤其是网页、邮件和文档中夹带了要求模型执行的文字。

因此，运行时输入应当有明确边界。可以用 Markdown 标题、代码围栏或 XML 标签区分任务、材料和示例。外部内容只作为待分析的数据，不能自动获得指令权限。

一份可执行的 Prompt 需要七块信息

不必强求每个 Prompt 都长成同一个模板，但复杂任务通常要交代下面这些内容。

目标

写清最终要改变什么，以及结果给谁使用。“整理资料”是动作，“帮助团队在本周决定是否迁移日志平台”才说明了任务价值。

输入和事实边界

列出已有材料、可信来源、时间范围和可以作出的假设。涉及价格、政策、软件版本等会变化的信息，要说明是否允许检索，以及哪些结论必须以当前资料为准。

约束和优先级

约束发生冲突时，Agent 需要知道谁优先。准确性、时效、成本和篇幅不能永远同时最大化。比起写“尽量全面且简洁”，直接说明关键事实不能省略，背景说明可以缩短，更容易执行。

工具和权限

说明可以读取什么、修改什么，哪些动作必须等待确认。搜索公开资料和删除生产数据显然不在同一个风险等级。只写“帮我处理一下”，会把重要的授权判断留给 Agent 猜。

输出协议

交付物要让下游能够直接使用。人读的报告可以规定章节和证据位置，程序消费的数据应该给出字段、类型和枚举值。只要求“返回 JSON”仍可能出现字段漂移，稳定接口应使用 JSON Schema 等机器可验证的约束。

异常处理

资料不足、工具失败、要求冲突时怎么做，也属于任务定义。可以允许 Agent 在不改变目标的前提下作出低风险假设，同时要求记录假设。会影响结论、产生费用或改变外部状态时，应当停下来请求确认。

完成条件

Agent 写完回复不代表任务完成。代码需要测试，网页修改需要检查页面，研究结论需要证据。完成条件应当描述可以观察的结果，而不是“认真检查”“确保高质量”一类态度要求。

示例用来消除歧义

自然语言总会留下解释空间。一个贴近真实任务的示例，往往比几段抽象形容词更有效。OpenAI、Anthropic 和 Google 的官方指南都把 few-shot 示例列为重要方法。

示例的价值在于展示边界。它可以告诉 Agent 何时应该拒绝猜测，字段缺失时怎样表示，引用放在哪里，简洁究竟意味着多短。多个示例还应覆盖正常情况、容易混淆的情况和失败情况，避免 Agent 只学到一个表面格式。

示例也会产生反作用。所有样例都用相同句式，模型可能照抄表达。样例与规则冲突，模型会在两套标准间摇摆。加入示例以后，最好把它当成测试数据维护，确认每个样例都代表当前期待。

输出格式要靠机制保证

如果结果会进入数据库、接口或下一段工作流，格式稳定性不能只依赖一句提示。OpenAI 的 Structured Outputs 文档区分了两类场景。Agent 需要调用系统能力时使用 function calling，Agent 只需要返回结构化结果时使用带 Schema 的输出格式。

这层约束解决的是语法和字段问题，业务正确性仍然要单独验证。一个完全符合 Schema 的价格字段，照样可能引用了过期页面。结构验证、事实验证和权限检查是三件不同的事，不能互相代替。

Agent Prompt 必须写清动作边界

普通聊天只产生文字，Agent 会读文件、运行命令、修改代码，也可能操作真实账户。能力进入环境以后，Prompt 就要承担一部分安全设计。

我习惯按动作的后果划分权限。读取公开资料、查看仓库和运行无破坏性的检查，可以在任务范围内自动完成。修改本地文件和运行测试，适合在用户明确要求实现或修复时放行。删除数据、付费、发布内容、向外部人员发消息等动作会改变现实状态，需要更明确的授权和目标确认。

权限之外还要写恢复策略。工具超时后是否重试，连续失败几次后停止，部分修改完成时怎样报告，验证没有通过时能否继续修复，这些规则决定了 Agent 遇到意外以后是恢复任务，还是把错误继续放大。Google 的 Prompt design strategies 也把执行可靠性、恢复和风险控制放进 Agent 工作流的设计范围。

上下文够用就好

Agent 需要完成任务所需的材料，不需要一个无限扩张的知识仓库。上下文越多，关键证据越容易被无关信息淹没，互相矛盾的旧资料也更难处理。

放入上下文时，应当标明材料的用途、时间和优先级。事实会变化时，明确哪些内容必须重新核验。长文档可以把具体问题放在材料之后，让 Agent 先接收上下文，再回答当前问题。跨多个步骤的任务，则可以拆成相互校验的小任务，让上一阶段的结构化结果成为下一阶段的输入。

是否需要搜索也应该由事实类型触发。当前价格、法规、版本行为和用户点名的网页需要实时核验。稳定概念和纯粹的改写任务通常不需要为了显得严谨而额外检索。

Prompt 要像代码一样进入工程流程

生产 Prompt 会影响产品行为，应该有版本、测试和回滚能力。OpenAI 的 Prompting 指南建议把 Prompt 放进明确命名的代码模块，使用类型化输入，并通过 Git、代码评审和评测管理变化。

评测数据要来自真实任务，至少覆盖常见输入、边界输入和容易诱发错误的输入。每次修改 Prompt 后，比较新旧版本在同一批样例上的表现。评分标准应当贴近任务，例如事实是否有来源、建议是否满足约束、工具调用是否越权。笼统的“整体质量很好”很难帮助定位问题。

OpenAI 的评测最佳实践提到，生成结果具有波动性，只靠传统软件测试并不够。更适合的做法是先定义目标，收集有代表性的样例，确定指标，再持续运行评测。线上发现的新失败案例也要回收到测试集里。

这让 Prompt 优化变成一项可以重复的实验。失败案例暴露缺口，规则或示例针对缺口调整，评测确认改动没有破坏其他场景，发布后继续观察。缺少这套反馈机制，Prompt 很容易越改越长，团队却说不清哪句话真的有效。

把一条需求写到可以验收

假设要让 Agent 修复一个前端问题，原始要求只有一句“清空搜索框后列表没有恢复，帮我修好”。Agent 还不知道问题在哪个页面，也不知道可以改到什么范围，甚至不知道怎样才算修好。补全以后，可以写成下面这样。

# 目标
修复当前仓库的搜索列表问题。
用户清空搜索框后，页面应恢复完整列表，不再保留上一次搜索结果。

# 已知现象
输入关键词后可以正常过滤。
删除全部关键词后，列表仍停留在过滤结果。

# 范围
先在现有代码和测试中复现问题，再定位原因。
做解决根因所需的最小修改，不顺手重构无关模块。
保留输入、分页和排序的原有行为。

# 工具与权限
可以读取和修改当前仓库，运行现有测试、类型检查和构建。
不要添加依赖，不要修改外部服务，不要覆盖无关的本地改动。

# 遇到问题时
无法复现时，列出已经检查的路径和仍缺少的信息。
发现修复会改变接口或其他页面行为时，先说明影响，不自行扩大范围。

# 完成条件
清空搜索框后能恢复完整列表。
有合适的测试位置时补充回归测试。
相关测试、类型检查和构建通过。

# 交付
说明根因、改动文件、验证结果和仍存在的风险。

这份 Prompt 没有替 Agent 规定要读几个文件、尝试几种方案。它给出了足够的判断依据，Agent 可以根据仓库现状选择路径。人也能直接检查修改范围和测试结果，不必从一篇过程汇报里猜任务是否完成。

这份示例只是起点。真正有价值的 Prompt 来自真实失败。选一个经常交给 Agent 的任务，保存一批代表性输入，先写出成功与失败的判断标准，再让每次修改接受同一套评测。能稳定通过这些任务的 Prompt，才值得进入生产环境。