Prompt 不是越长越好，但也不是只写目标就够了

和一次性回答为主的 Chat 场景相比，Agent 可以自己读取文件、搜索资料、调用工具、执行命令，再根据结果继续调整。

所以，Prompt 的确不必再像一份操作说明书：把先做什么、再做什么、每一步用什么方法，全部替 Agent 安排好。

但另一个极端同样有问题：

只告诉 Agent 一个目标，剩下的全部让它自己决定。

Agent 可以自己找路，却不能替你决定：

• 真正要解决的是什么问题；
• 哪个结果更重要；
• 哪些代价不能接受；
• 做到什么程度才算完成。

OpenAI 在 Codex 官方最佳实践中，给出了一套很直接的默认结构：

“A good default is to include four things in your prompt: Goal, Context, Constraints, Done when.”

也就是：目标、必要背景、约束和完成标准。这能帮助 Codex 缩小任务范围、减少自行假设，也让结果更容易审核。

Anthropic 对 Agent context 的建议也不是“越短越好”，而是寻找足以完成任务的最小高信号信息集合，并特别提醒：

“Minimal does not necessarily mean short.”

该写的信息仍然要写，只是不要让关键要求淹没在无关背景和重复规则里。

所以，更准确的说法是：

Agent Prompt 不必做到执行过程完整，但需要做到关键决策完整。

用一场会议看懂这四项

假设你把一场 90 分钟的会议录音交给 Agent，只说：

帮我整理一下这场会议。

它大概率能生成一份条理不错的摘要。

但摘要未必解决真正的问题：

• 会议最后决定了什么？
• 哪些只是建议，还没有确认？
• 谁需要做什么？
• 截止时间是什么？
• 哪些问题仍然没有结论？

Agent 完成了“整理”，却未必完成了你真正需要的工作。

这正是 Goal、Context、Constraints 和 Done when 分别要解决的问题。

1. Goal：做完以后，什么应该变得不一样？

“整理会议录音”只是一个动作。

更清楚的 Goal 是：

把会议内容转成一份可追踪的决策与行动清单，避免会后对决定、负责人和下一步产生不同理解。

两者的区别在于：

• 动作告诉 Agent 要做什么；
• Goal 告诉 Agent 为什么做，以及最终希望产生什么变化。

“阅读文档”“分析数据”“修改页面”通常都只是手段。

检查 Goal 时，可以问：

任务完成以后，什么应该比现在更清楚、更顺畅或者更可靠？

2. Context：不是项目自传，而是判断所需的事实

Context 不是把所有相关历史都塞进 Prompt。

它应该只包含那些：

Agent 无法可靠猜到，又会影响当前判断的信息。

在会议纪要这个例子里，有用的 Context 可能是：

• 这是一次产品上线前的决策会议；
• 参会者分别负责什么；
• 自动转录可能会识别错说话人；
• 上线日期此前已经确认，不在本次讨论范围内；
• 上一次会议已经做出了哪些决定。

但没有必要从项目立项开始，把整个发展过程重新讲一遍。

一个很实用的判断方式是：

删掉这条信息，Agent 会不会因此做出一个看似合理、实际上错误的判断？

会，就保留。

不会，就让 Agent 自己从资料里查找，或者不必放进当前 Prompt。

Context 的价值不在于多，而在于它是否会改变 Agent 的判断。

3. Constraints：不能以什么代价完成目标？

Constraints 最容易被误解成操作步骤。

它不是：

先处理录音，再按照时间排序，然后生成表格，最后写总结。

这些是执行路径，Agent 可以自行安排。

真正的 Constraints 是：

• 不要把讨论中的建议写成已经确认的决定；
• 不要自行补全负责人和截止时间；
• 不要为了让纪要更简洁而抹掉仍然存在的分歧；
• 无法确认的信息应标注待确认，而不是猜测；
• 外发版本不得包含客户隐私信息。

Goal 说的是想得到什么。

Constraints 说的是：

即使目标实现了，哪些代价仍然不可接受？

一份纪要不能为了显得完整而虚构负责人，也不能为了读起来顺畅，把争议改写成共识。

常见的 Constraints 还包括：

• 本轮做什么、不做什么；
• 哪些产品或业务原则不能改变；
• 哪些旧数据和行为必须兼容；
• Agent 没有被授权执行哪些操作；
• 哪些安全、隐私和成本风险不能接受。

所以，Constraints 不是教 Agent 怎样走，而是在划定哪些路不能走。

Goal 定义你想得到什么，Constraints 定义你不愿意拿什么来交换。

4. Done when：怎样证明真的完成了？

Goal 和 Done when 看起来很像，但解决的是不同问题。

这个任务的 Goal 是：

让会议结果变得清楚、可追踪，并且能够继续执行。

但“清楚、可追踪”仍然比较抽象。

Done when 要把它变成可以检查的结果：

• 每一项已确认决定都能对应到原始录音位置；
• 每一项行动都有负责人和截止时间，无法确认的明确标为待定；
• 未解决的问题被单独列出；
• 建议、讨论和正式决定能够清楚区分；
• 外发版本已经移除敏感信息。

所以：

Goal 定义成功的方向，Done when 定义成功的证据。

Goal 是“把厨房变得更好用”。

Done when 是“两个人可以同时操作，冰箱和水槽不会互相挡路，所有柜门都能正常打开”。

没有 Done when，Agent 很容易把“已经生成了一份东西”，当成“问题已经解决”。

GitHub 对 Copilot coding agent 的官方建议也强调：任务不仅要清楚、范围明确，还应该包含完整的验收标准；与此同时，Agent 通常可以自己搜索代码库，不一定需要人提前指定每一个文件。

一份完整的 Prompt 可以这样写

Goal

把这场会议整理成一份可追踪的决策与行动清单，避免会后对决定、负责人和下一步产生不同理解。

Context

这是一次产品上线前的决策会议。

附件包含会议录音、自动转录文本、参会者名单，以及上一次会议的决定记录。

自动转录可能会识别错说话人。上线日期已经确认，不属于本次重新讨论的范围。

Constraints

• 不要把建议或个人意见写成已确认决定。
• 不要自行推测负责人和截止时间。
• 保留尚未解决的分歧。
• 无法确认的信息请标注“待确认”。
• 外发版本不得包含客户姓名和联系方式。

Done when

• 所有已确认决定均已列出，并附原始录音时间点。
• 所有行动项均有负责人和截止时间，或明确标为待确认。
• 未解决问题被单独列出。
• 建议、讨论和正式决定可以被清楚区分。
• 同时提供内部完整版和已脱敏的外发版。

这份 Prompt 并不算特别短。

但它没有规定 Agent 必须先读哪份文件、按照什么顺序处理，也没有替它设计每一步工作流程。

它只把必须由人决定的部分讲清楚了：

• 最终想得到什么；
• 做判断需要知道什么；
• 哪些处理方式不可接受；
• 凭什么判断任务已经完成。

剩下的路径，可以留给 Agent。

哪些细节应该写，哪些可以不写？

应该认真写的，是那些 Agent 无法从环境中可靠获得、又会影响取舍的信息：

• 真正的目标；
• 必要的业务背景；
• 优先级；
• 产品或工作原则；
• 范围与权限；
• 不可接受的风险；
• 兼容性要求；
• 验收标准。

通常可以少写的，是 Agent 能够通过调查和验证自行找到的信息：

• 先查看哪个文件；
• 按照什么顺序搜索；
• 先修改哪个内部函数；
• 采用哪一种具体实现；
• 常规检查先运行哪一项。

当然，这不是绝对的。

如果某个实现方式已经是明确决定，或者涉及安全、兼容性、成本和不可逆风险，它就不再只是实现细节，而应该写进 Constraints。

Prompt 不是越短越好，而是越难删越好

复杂任务本来就可能需要较长的 Prompt。

真正值得检查的不是字数，而是：

每一句话是否都在改变 Agent 的判断？

如果删掉一段以后：

• 目标没有变模糊；
• Agent 不会误解现状；
• 可接受的方案没有变化；
• 风险没有增加；
• 验收标准仍然清楚；

那么这段话大概不需要出现在当前 Prompt 里。

所以，Prompt 不是越长越好，也不是越短越高级。

更合适的标准是：

好的 Prompt，留下的都是不能轻易删掉的信息。

写完以后，可以只检查四个问题：

• Agent 知道做完以后，什么应该发生变化吗？
• 它拥有做出正确判断所需的事实吗？
• 它知道哪些代价、风险和变化不可接受吗？
• 它知道凭什么证据判断任务已经完成吗？

Agent 可以负责探索路径。

方向、取舍、边界和验收，仍然需要人来决定。

参考资料

OpenAI，Codex Best Practices。

Anthropic，Effective Context Engineering for AI Agents。

GitHub，Best Practices for Using GitHub Copilot to Work on Tasks。