调 Agent 的 Prompt 太痛苦了? 这套“写法 + 测评”救了我

开发导购Agent过程中“翻车”不断？Anthropic发布的视频详细讲解如何写好Agent的Prompt与测评。Agent并非更聪明的聊天机器人，而是在工具回路中自主推进任务的系统。何时该用Agent？复杂、高价值任务更适配。怎么写好Prompt？要像Agent思考，赋予合理启发式等。测评又该怎么做？从“小而真”开始，评测结果与过程。本文将深入分享视频中的关键观点，为Agent开发排忧解难。

最近在做导购Agent，工程侧已经开发完毕，但调Prompt、做测评，每一个都令我痛苦万分，因为到处都是“翻车现场”：要么“思维太发散”，绕着用户的问题走；要么“工具乱点”，命中一个tool就一条道走到黑；要么“跑不完”，说着说着卡住了，再没了下文……

因此搜了一些Agent相关的论文、文章、视频，企图从技术底层抱抱佛脚…

正巧看到了Anthropic8月1日在YouTube上发布了一个视频《PromptingforAgents|Codew/Claude》，详细讲了如何写好Agent的Prompt、如何测评。

正好是我现在非常需要的内容，因此今天的文章主要分享下该视频的观点。

这支视频讲了啥？（速览版）

Agent的正确定义：不是“更聪明的聊天机器人”，而是“在工具回路中自主推进任务的系统”：给定目标→选择/调用工具→观察→决定下一步→直到达成停止条件。

什么时候该用Agent：适合复杂、不确定路径、且高价值的任务；能被固定流程吃掉的，优先Workflow。这个判断框架与Anthropic的工程文《Buildingeffectiveagents》完全一致。

如何写好提示词：要写清目标与成功标准、工具选择原则、思考—行动—反思节奏、启发式（预算/不可逆动作/停机条件）、输出契约等；否则只是在给模型加戏。

测评从简单、小批量开始：先把最小可用工具集跑通，再逐步加复杂度。

什么是Agent？

Agent=在一个循环回路中使用工具的模型。给定目标后，它会自主地：选择/调用合适工具→观察反馈→更新决策→继续推进，直到满足停止条件。它所依赖的“环境”包括：运行环境、可用工具清单、提示词（任务与边界）。

Agent的组成

目标与停止条件。

工具回路（Action–Observation）：每一步都基于工具返回更新计划。

环境三件套：运行环境/工具/系统提示（明确“Agent要完成什么”）。

“越简单越好”：提示与工具说明要清晰克制，别给花里胡哨的语言描述。

什么是“提示词工程（promptengineering）”？

AnthropicAI团队成员Hannah认为“提示词工程是一种系统性改进用于大模型应用的提示词的方法——通过测试、评估、分析与对提示词及工具的优化，用自然语言进行编程！

一个好的提示词工程是所需能力包含：

清晰、无歧义、精确的写作；

以科学思维制作评测，不断测试；

产品化思维：对你的产品来说，理想的模型行为是什么；

理解大模型的倾向与局限；

汇总并分析失败模式，并思考修复方法；

思考边界场景，让提示在广泛输入下都稳健。

写提示词=写操作流程

Anthropic的核心观点：Prompt不是文案，是规则和流程。它要解决的不是“说得漂亮”，而是如何让Agent在真实环境里把事办完。这份规程至少包含五部分：

角色与高层目标（1–2句话说清你是谁、为啥而来）

动态上下文（检索到的资料、用户偏好、会话历史）

详细任务指令（做什么、不做什么、成败标准）

示例n-shot（可选，用于边界提醒，不是“写死流程”）

重复关键指令（长提示里尤其重要，防遗忘）

一个示例：

你是一名AI旅行顾问（AItravelagent），任务是根据用户输入创建一份个性化旅行行程。你的目标是：产出一份有吸引力、结构清晰、切实可行的行程，既符合用户偏好，也匹配指定的目的地与出行天数。

你将获得以下信息：目的地、天数、用户偏好。

在制定行程时，请遵循以下指南：

调研目的地及其热门景点，并结合用户偏好。

为每一天规划活动，确保观光—放松—本地体验之间的良好平衡。

给出用餐建议，考虑当地美食；如用户提到饮食偏好，请一并考虑。

推荐住宿选项，需与用户偏好与预算相匹配。

提供实用信息，如交通方式与预估花费。

注意可用天数，制定现实可行的时间安排。

请按以下格式呈现你的行程：

以目的地的简要介绍开头。

提供按天拆分的活动、用餐与住宿安排。

以额外提示/出行建议结尾。

现在，请基于提供的目的地、天数和用户偏好，创建一份个性化旅行行程。你的建议应当既有创意又充分详尽，确保行程既体现用户兴趣，也凸显目的地的独特之处。

什么时候该用Agent？

不是所有场景都需要Agent（很多时候反而不该用Agent），它最适合复杂且高价值的任务。人可以按“固定步骤”一步步做完的工作，用工作流（workflow）可能更合适、更省资源。

判断方法：1）任务是否复杂到只知道终点，不清楚具体怎么走、需要哪些信息与工具；2）完成后是否“高价值”？低价值流程别浪费Agent的资源；3）工具与数据是否可用？若给不了足够工具/信息就让它办成事，那就先缩小范围；4）容错与纠错成本：难以发现/纠正的错误，不适合让Agent全自动去跑。

2个适合Agent的例子：

写代码：你知道目标是“把设计文档落实成PR”，但并不确定具体路径、要如何迭代修改——高价值、强杠杆，适合Agent。

数据分析：你清楚希望得到哪些洞见/可视化，但数据形态、清洗过程并不确定——这类探索式任务非常适配Agent。

如何写好Agent的Prompt？

原则一：像Agent那样思考

模拟“Agent身处的环境”——它能看到什么工具、工具会返回什么；甚至可以在脑内模拟一遍：如果你站在Agent的角度，拿到这份工具说明，你会不会困惑？人类都看不懂的工作流，模型更不可能做对。

原则二：赋予“合理的启发式（Heuristics）”

提示工程不是“写字”，而是决定模型该拥有哪些概念与行为准则。例如：我们给Agent一个重要概念——“不可逆性（irreversibility）”：避免做不可逆、可能伤害用户或环境的动作。再比如，给“检索”Agent设停止条件与预算：找到答案就停；简单问题<5次工具调用，复杂问题可到10或50；不要为“完美来源”无限搜索。这类“合理启发式”都要在提示里清晰明确地写出来。

原则三：明确“何时用哪种工具”

前沿模型一次能挂非常多的工具，但模型并不知道在你的组织里哪个工具对哪个任务更关键。必须在提示中写出选择原则：比如公司信息优先搜Slack、代码问题查GitHub/Sentry、业务报表走DataDog……别只给一串简短描述就指望它自己悟透。

原则四：引导“思考—行动”的过程

不要只“打开思考”，而要具体引导：

让它先规划：这个查询复杂度如何？预期用几次工具？优先查哪些来源？如何判定成功？

在工具调用之间穿插反思：网页结果不必然正确，需要质量评估/二次求证/必要的免责声明。

提前写上副作用与停止条件：比如“若找不到完美来源，最多N次搜索后停止”。

原则五：管理上下文窗口

Agent容易撞到上下文上限。做法包括：

压缩：临近窗口上限时自动把上下文浓缩为高密度摘要，交给新的会话继续跑。

外部记忆：把关键过程/状态写入外部文件，需要时再读取。

子Agent：把搜索等“吃上下文”的工作分给子代理，压缩后再交给主代理整合、撰写报告。

原则六：让Claude发挥所长+工具要“少而精”

先用一套最小可用的提示和工具跑起来，再逐步加复杂度。避免给一堆名字相似/职责重叠的工具（例如6个“搜索”工具查不同库），会让模型混淆——能合并就合并，并把用途说清清楚楚。

测评怎么做：从“小而真”开始

效果量越大，样本越可小：起步不需要上百条，只要几条真实用例，每次改Prompt/工具文档都能看到显著变化。

用真实任务评测：尽量让评测题就像用户会问的那种，且能用现有工具找到标准答案。

LLM评审+量表（rubric）很有用：只要规则清楚，模型能胜任“打分官”。

人评无法被完全替代：每周都要有人“猛怼+手感校验+真实用户试用”，人类最能摸到“硌手的边角”。

评测都评什么：结果&过程

1）结果向（Outcome）

答案正确性：用LLM-judge判定回答是否正确、是否覆盖关键点。

最终状态达成：看Agent是否到达正确的最终状态（例如：外部系统里确实发生了期望变更）。

2）过程向（Process）

工具使用正确性：评估是否选对工具与参数，以及遇错能否恢复（图示中“从参数错误恢复”的示例）。

其他常见过程量化：步骤数/时延、无效调用、异常与回退等——这些直接从对话与调用日志即可统计。

LLM-as-judge的最小做法：给评审模型一份量表和结构化输出格式，它就能稳定工作。

示例量表要点：

是否满足硬性约束（0/1/2）

证据质量与可追溯性（0/1/2）

取舍与理由是否清晰（0/1/2）

是否给出风险/不确定性（0/1/2）

输出契约是否遵守（0/1/2）

合计0–10分，并给一句话短评

测评起步流程：

选10–20条真实任务样例（最好能用现有工具找到明确答案/标准）。

为每条样例写明期望结果/最终状态（方便做τ-bench）。

准备一份rubric，用LLM-as-judge打分；必要处穿插人评抽检。

观察结果+过程两套指标的变化；对失败样例做回放，定位是选择错工具、参数错误、步骤冗长还是停止条件/启发式不当。

小改就复测：每次只调整一个维度（如Prompt的启发式或某个工具文档），再跑同一小集合对比效果。