-
Agent 的正确定义：不是“更聪明的聊天机器人”，而是“在工具回路中自主推进任务的系统”：给定目标→选择/调用工具→观察→决定下一步→直到达成停止条件。 -
什么时候该用 Agent：适合复杂、不确定路径、且高价值的任务；能被固定流程吃掉的，优先 Workflow。这个判断框架与 Anthropic 的工程文《Building effective agents》完全一致。 -
如何写好提示词：要写清目标与成功标准、工具选择原则、思考—行动—反思节奏、启发式（预算/不可逆动作/停机条件）、输出契约等；否则只是在给模型加戏。 -
测评从简单、小批量开始：先把最小可用工具集跑通，再逐步加复杂度。
-
目标与停止条件。 -
工具回路（Action–Observation）：每一步都基于工具返回更新计划。 -
环境三件套：运行环境 / 工具 / 系统提示（明确“Agent要完成什么”）。 -
“越简单越好”：提示与工具说明要清晰克制，别给花里胡哨的语言描述。
-
清晰、无歧义、精确的写作； -
以科学思维制作评测，不断测试； -
产品化思维：对你的产品来说，理想的模型行为是什么； -
理解大模型的倾向与局限； -
汇总并分析失败模式，并思考修复方法； -
思考边界场景，让提示在广泛输入下都稳健。
-
角色与高层目标（1–2 句话说清你是谁、为啥而来） -
动态上下文（检索到的资料、用户偏好、会话历史） -
详细任务指令（做什么、不做什么、成败标准） -
示例 n-shot（可选，用于边界提醒，不是“写死流程”） -
重复关键指令（长提示里尤其重要，防遗忘）
-
调研目的地及其热门景点，并结合用户偏好。 -
为每一天规划活动，确保观光—放松—本地体验之间的良好平衡。 -
给出用餐建议，考虑当地美食；如用户提到饮食偏好，请一并考虑。 -
推荐住宿选项，需与用户偏好与预算相匹配。 -
提供实用信息，如交通方式与预估花费。 -
注意可用天数，制定现实可行的时间安排。
-
以目的地的简要介绍开头。 -
提供按天拆分的活动、用餐与住宿安排。 -
以额外提示/出行建议结尾。
-
让它先规划：这个查询复杂度如何？预期用几次工具？优先查哪些来源？如何判定成功？ -
在工具调用之间穿插反思：网页结果不必然正确，需要质量评估/二次求证/必要的免责声明。 -
提前写上副作用与停止条件：比如“若找不到完美来源，最多 N 次搜索后停止”。
-
压缩：临近窗口上限时自动把上下文浓缩为高密度摘要，交给新的会话继续跑。 -
外部记忆：把关键过程/状态写入外部文件，需要时再读取。 -
子Agent：把搜索等“吃上下文”的工作分给子代理，压缩后再交给主代理整合、撰写报告。
-
答案正确性：用 LLM-judge 判定回答是否正确、是否覆盖关键点。 -
最终状态达成：看 Agent 是否到达正确的最终状态（例如：外部系统里确实发生了期望变更）。
-
工具使用正确性：评估是否选对工具与参数，以及遇错能否恢复（图示中“从参数错误恢复”的示例）。 -
其他常见过程量化：步骤数/时延、无效调用、异常与回退等——这些直接从对话与调用日志即可统计。
-
是否满足硬性约束（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 的启发式或某个工具文档），再跑同一小集合对比效果。