摘要：开发导购 Agent 过程中 “翻车” 不断？Anthropic 发布的视频详细讲解如何写好 Agent 的 Prompt 与测评。Agent 并非更聪明的聊天机器人，而是在工具回路中自主推进任务的系统。何时该用 Agent？复杂、高价值任务更适配。怎么写好
开发导购 Agent 过程中 “翻车” 不断？Anthropic 发布的视频详细讲解如何写好 Agent 的 Prompt 与测评。Agent 并非更聪明的聊天机器人，而是在工具回路中自主推进任务的系统。何时该用 Agent？复杂、高价值任务更适配。怎么写好 Prompt？要像 Agent 思考，赋予合理启发式等。测评又该怎么做？从 “小而真” 开始，评测结果与过程。本文将深入分享视频中的关键观点，为 Agent 开发排忧解难。
最近在做导购Agent，工程侧已经开发完毕，但调Prompt、做测评，每一个都令我痛苦万分，因为到处都是“翻车现场”：要么“思维太发散”，绕着用户的问题走；要么“工具乱点”，命中一个tool就一条道走到黑；要么“跑不完”，说着说着卡住了，再没了下文……
因此搜了一些Agent相关的论文、文章、视频，企图从技术底层抱抱佛脚…
正巧看到了Anthropic 8月1日在YouTube上发布了一个视频《Prompting for Agents | Code w/ Claude》，详细讲了如何写好Agent 的 Prompt、如何测评。
正好是我现在非常需要的内容，因此今天的文章主要分享下该视频的观点。
这支视频讲了啥？（速览版）
Agent的正确定义：不是“更聪明的聊天机器人”，而是“在工具回路中自主推进任务的系统”：给定目标→选择/调用工具→观察→决定下一步→直到达成停止条件。什么时候该用Agent：适合复杂、不确定路径、且高价值的任务；能被固定流程吃掉的，优先Workflow。这个判断框架与Anthropic的工程文《Buildingeffectiveagents》完全一致。如何写好提示词：要写清目标与成功标准、工具选择原则、思考—行动—反思节奏、启发式（预算/不可逆动作/停机条件）、输出契约等；否则只是在给模型加戏。测评从简单、小批量开始：先把最小可用工具集跑通，再逐步加复杂度。什么是Agent？Agent = 在一个循环回路中使用工具的模型。给定目标后，它会自主地：选择/调用合适工具 → 观察反馈 → 更新决策 → 继续推进，直到满足停止条件。它所依赖的“环境”包括：运行环境、可用工具清单、提示词（任务与边界）。
Agent的组成
目标与停止条件。工具回路（Action–Observation）：每一步都基于工具返回更新计划。环境三件套：运行环境/工具/系统提示（明确“Agent要完成什么”）。“越简单越好”：提示与工具说明要清晰克制，别给花里胡哨的语言描述。什么是“提示词工程（prompt engineering）”？Anthropic AI团队成员Hannah认为“提示词工程是一种系统性改进用于大模型应用的提示词的方法——通过测试、评估、分析与对提示词及工具的优化，用自然语言进行编程！
一个好的提示词工程是所需能力包含：
清晰、无歧义、精确的写作；以科学思维制作评测，不断测试；产品化思维：对你的产品来说，理想的模型行为是什么；理解大模型的倾向与局限；汇总并分析失败模式，并思考修复方法；思考边界场景，让提示在广泛输入下都稳健。写提示词 = 写操作流程
Anthropic 的核心观点：Prompt 不是文案，是规则和流程。它要解决的不是“说得漂亮”，而是如何让 Agent 在真实环境里把事办完。这份规程至少包含五部分：
角色与高层目标（1–2句话说清你是谁、为啥而来）动态上下文（检索到的资料、用户偏好、会话历史）详细任务指令（做什么、不做什么、成败标准）示例n-shot（可选，用于边界提醒，不是“写死流程”）重复关键指令（长提示里尤其重要，防遗忘）你是一名AI 旅行顾问（AI travel agent），任务是根据用户输入创建一份个性化旅行行程。你的目标是：产出一份有吸引力、结构清晰、切实可行的行程，既符合用户偏好，也匹配指定的目的地与出行天数。
你将获得以下信息：目的地、天数、用户偏好。
在制定行程时，请遵循以下指南：
调研目的地及其热门景点，并结合用户偏好。为每一天规划活动，确保观光—放松—本地体验之间的良好平衡。给出用餐建议，考虑当地美食；如用户提到饮食偏好，请一并考虑。推荐住宿选项，需与用户偏好与预算相匹配。提供实用信息，如交通方式与预估花费。注意可用天数，制定现实可行的时间安排。请按以下格式呈现你的行程：
以目的地的简要介绍开头。提供按天拆分的活动、用餐与住宿安排。以额外提示/出行建议结尾。现在，请基于提供的目的地、天数和用户偏好，创建一份个性化旅行行程。你的建议应当既有创意又充分详尽，确保行程既体现用户兴趣，也凸显目的地的独特之处。
什么时候该用 Agent？不是所有场景都需要 Agent（很多时候反而不该用 Agent），它最适合复杂且高价值的任务。人可以按“固定步骤”一步步做完的工作，用工作流（workflow）可能更合适、更省资源。
判断方法： 1）任务是否复杂到只知道终点，不清楚具体怎么走、需要哪些信息与工具； 2）完成后是否“高价值”？低价值流程别浪费 Agent 的资源； 3）工具与数据是否可用？若给不了足够工具/信息就让它办成事，那就先缩小范围； 4）容错与纠错成本：难以发现/纠正的错误，不适合让 Agent 全自动去跑。
2个适合Agent的例子：
写代码：你知道目标是“把设计文档落实成 PR”，但并不确定具体路径、要如何迭代修改——高价值、强杠杆，适合 Agent。
数据分析：你清楚希望得到哪些洞见/可视化，但数据形态、清洗过程并不确定——这类探索式任务非常适配 Agent。
如何写好Agent的Prompt？原则一：像 Agent 那样思考
模拟“Agent 身处的环境”——它能看到什么工具、工具会返回什么；甚至可以在脑内模拟一遍：如果你站在 Agent 的角度，拿到这份工具说明，你会不会困惑？人类都看不懂的工作流，模型更不可能做对。
原则二：赋予“合理的启发式（Heuristics）”
提示工程不是“写字”，而是决定模型该拥有哪些概念与行为准则。例如：我们给 Agent 一个重要概念——“不可逆性（irreversibility）”：避免做不可逆、可能伤害用户或环境的动作。再比如，给“检索”Agent 设停止条件与预算：找到答案就停；简单问题
原则三：明确“何时用哪种工具”
前沿模型一次能挂非常多的工具，但模型并不知道在你的组织里哪个工具对哪个任务更关键。必须在提示中写出选择原则：比如公司信息优先搜 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的启发式或某个工具文档），再跑同一小集合对比效果。本文由 @AI产品泡腾片 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
来源：人人都是产品经理