企业官网建设流程全解析

1. 从零开始：为什么要认真对待Agent的提示策略

做AI应用开发这几年，我越来越觉得，提示工程（Prompt Engineering）是被低估的"脏活累活"。大家热衷于讨论模型参数、微调技巧、RAG架构，但真正决定一个Agent（自主代理）是"聪明助手"还是"人工智障"的，往往就是那几段看起来不起眼的提示词。尤其是当你做的是"自主代理"而不是"单轮问答"时，提示策略直接决定了系统能不能在没有人工干预的情况下，一条路走到黑还不翻车。

先说清楚我理解的"自主代理AI"是什么。它不是那种你问一句、它答一句的聊天机器人，而是一个被赋予了目标、工具和决策权限的系统。比如让它"自动分析公司上个月的所有销售数据，找出异常波动并生成一份归因报告"，它需要自己决定先查哪些表、用哪个工具、结果不符预期时怎么办、出现幻觉时怎么纠正。

在这种场景下，提示词不再是一个"问题"，而是一套"操作手册 + 决策框架 + 边界约束"的复合体。你可以把它理解成给一个能力很强但缺乏常识的新员工写工作指南：不写清楚，他就自由发挥；写得太多，他就束手束脚。这个平衡，就是提示策略设计的核心。

这篇内容适合谁？适合正在做Agent开发、AI工作流设计、或者想把自己的大模型应用从"Demo级"提升到"生产级"的工程师和产品经理。我会把自己在实际项目中踩过的坑、反复修正过的策略、验证有效的结构模板，一套一套拆开来讲。这篇不是教你背几个"魔法提示词"就完事，而是希望能帮你建立一套自己的提示策略设计方法论。

2. 自主代理提示策略的底层逻辑

2.1 从"对话提示"到"代理提示"的思维转变

很多人写提示词的习惯，是停留在"对话式"的思维里：用户问什么，模型答什么。这种思路放到自主代理的场景里，立刻就会出问题。

对话式提示的假设是"大模型只需要在当前这一步表现得聪明就行"，但自主代理的假设是"大模型需要在未来几十步的决策链条中持续保持正确"。差之毫厘，谬以千里。举个我在实际项目中遇到的例子：我让Agent去抓取十个网页并总结规律，它在第一步"抓取网页"时成功了，但在归纳总结时，因为原始提示词里只说了"总结规律"，它把所有网页内容的共同点全部罗列了出来，却完全没提差异点。单独看每一步，它做得都不算错，但放到整个任务目标里看，这个结果就是废的。

对话式提示关注"单轮输出的质量"，而代理式提示必须关注"多轮决策的收敛性"。你需要告诉Agent的不只是"做什么"，还要包括"做到什么程度算完成""哪些信号出现时需要停下来重新规划""哪些信息是噪音可以忽略"。这就像是一份完整的自动驾驶策略，而不是一个个孤立的导航指令。

核心转变点有三个：

• 从"描述问题"转向"定义目标和验收标准"
• 从"期待一次回答正确"转向"设计反馈与自我纠正循环"
• 从"告诉模型你的想法"转向"规划模型在不同情况下的行动路径"

2.2 为什么"结构化提示"比"长文本提示"更可靠？

在我早期的Agent项目里，我犯过一个很典型的错误：为了让Agent更聪明，我在提示词里塞进了大量细节和背景说明，结果提示词多达两千多字。实测的效果反而变差了，模型经常被冗长的上下文带偏，甚至开始执行一些我在举例时随口提到的、根本没打算让它做的操作。

后来我把所有提示词全部重构成结构化格式，问题立刻减少了一大半。这背后的原理其实不复杂：大模型的注意力机制在处理紧凑、分层的指令时，比处理散文式的长文本要稳定得多。就像你给下属安排任务，列清楚"目标-步骤-约束-产出格式"会比长篇大论讲故事更不容易让下属跑偏。

我目前最常用的基础结构是"五段式"：

• 角色与背景：明确Agent的身份、所拥有的工具能力、以及当前所处任务的上下文环境
• 目标定义：用2到3句话描述最终要达成的目标，必须包含可量化的验收标准
• 步骤规划：给出从起点到终点的关键里程碑节点，但不规定每个节点的具体操作细节
• 约束与边界：明确禁止做的事、遇到异常时的后备方案、风险触发条件
• 输出规范：定义每一步产出的格式、存储位置、汇报形式

有人可能会问：规定得太细会不会限制大模型的灵活性？我的经验是，关键在于你约束的是什么。约束"边界"和"验收标准"不会降低灵活性，反而能让模型在边界内更有底气地自由发挥。真正需要避免的是约束它的"实现路径"——在步骤规划层面，我会刻意写得比较有弹性，给模型留出自主决策的空间。

2.3 任务心智模型：让Agent拥有"全局观"和"局部观"双视角

这是我在一次失败的自动化测试项目中领悟到的。当时我们的Agent需要处理一个多步骤的数据清洗任务，每步都写得清清楚楚，但跑完流程后我们发现：它在第三步把整个数据文件覆盖写入了，导致后续所有步骤全部失效。问题出在哪？出在我们给Agent的每一步都足够清晰，但Agent从来没有被要求"先理解整个任务的全局路径，再开始执行局部动作"。

后来我加入了"全局视图"和"局部视图"的双层结构。所谓全局视图，就是在Agent开始执行任何操作之前，先把任务全貌（从哪里来、经过哪里、到哪里去、谁在使用最终输出）展示给它看。所谓局部视图，则是在进入具体步骤时，只强调当前这一步的上下文、输入和预期产出。

打个比方：全局视图是给司机看完整路线图，局部视图是当前路口的清晰指示牌。大多数Agent翻车，都是因为司机只盯着指示牌猛开，却忘了自己要去的是哪个城市。

实践中我在提示词开篇固定一段"任务全貌",后面每进入一个新阶段时，再动态注入一段"当前阶段聚焦"。效果非常明显，Agent在执行中途出现"迷路"的概率至少降了一半。

3. 提示策略的六大核心设计模式

3.1 分步分解模式：把大任务拆成"可独立验证"的小步骤

自主代理最常见的失败方式，是试图一口气做完所有事。你让它"调研市场竞争格局并输出战略建议"，它很可能在调研还没做完时就开始写建议，然后用它那点不完整的调研结果硬圆场。

分步分解模式是解决这个问题的基础手段。但关键是"拆分"本身也有讲究：你必须保证拆分出来的每个子步骤的产出是可独立验证的。换句话说，每个子步骤都应该有一个明确的"完成定义"（Definition of Done），可以让Agent自己检查"这一步到底做完了没有"。

我常用的拆法分三层：

• 任务层：整体目标是什么，最终产出是什么
• 阶段层：分成几个逻辑阶段，每个阶段的入口和出口是什么
• 原子层：每个阶段内部的小操作步骤，以及如何验证这一步的正确性

实际模板长这样：

任务：调研三类目标客户对产品定价的敏感度，形成对比报告。 阶段1：数据收集 - 步骤1.1：提取内部CRM中客户A/B/C三个分组的成交数据（验证：得到3个CSV文件，字段完整） - 步骤1.2：抓取公开竞品定价信息（验证：至少覆盖5家竞品，记录抓取时间和来源） - 步骤1.3：清洗汇总所有数据（验证：空值率低于5%，格式统一） 阶段2：数据分析 - 阶段2.1：对每个分组分别进行描述性统计（验证：每个分组至少5个统计维度） - 阶段2.2：交叉分析价格敏感度与购买频次的关系（验证：得出相关系数和显著性说明） 阶段3：报告生成 - 步骤3.1：按预设模板填充分析结果 - 步骤3.2：校验报告中的每个关键结论是否都有对应数据支撑（验证：无来源的结论数为0）

每一层的验证条件都是Agent在执行中可以自查的。不需要人类中途介入，但需要把自查逻辑写清楚。

3.2 反思与纠错模式：让Agent学会"停下来想想"

自主代理比普通对话系统更值钱的地方，在于它可以自我纠错。但如果你不在提示策略里显式地设计"反思机制"，它根本不会主动停下来想。

所谓反思机制，就是要求Agent在每个关键节点或固定间隔，对比"当前状态"与"目标状态"之间的差距。如果发现偏离，就回到上一步重新执行，而不是硬着头皮继续往下走。

我常用的结构是在每完成一个原子步骤后，插入一个"CheckPoint"指令：

检查点指令： 在执行下一步之前，请先回答以下问题： 1. 当前步骤的输出是否符合步骤N的完成定义？ 2. 是否存在会导致最终目标无法达成的偏差？ 3. 如果有偏差，是返回上一步修正，还是可以带病继续？ 回答格式： - 状态：PASS / RETRY / SKIP - 理由：不超过50字 - 修正方案：如果RETRY，请给出下一步计划

刚开始这样做时，Agent的"反思开销"会比较大——每个步骤都多出一段思考时间。但换来的是整体成功率大幅提升，尤其是那些跨时间较长、中间步骤较多的任务。相比之下，这个代价完全值得。

还有一个细节：反思指令要在"步骤间"注入，而不是放在提示词开头的全局指令里。如果你把反思机制写在一开头，模型确实会在第一步好好反思，但到了第五步、第八步，它早就把这个指令忘光了。正确做法是在每步之间都动态注入检查点指令，或者把检查点绑定到某个工具的触发条件上。

3.3 工具调用模式：指令与工具描述的搭配艺术

自主代理几乎一定会用到工具，比如搜索网页、调数据库、读写文件、调用API。提示策略里最容易被忽视的部分，就是"如何描述工具"。

很多人的做法是把工具名称和参数列表丢给模型，但模型实际使用工具时经常出错。我遇到过的情况包括：参数顺序搞反、明明是只读操作却使用了写入工具、报错之后不知道换个参数重试。

我的经验是，工具描述要遵循三个原则：

• 说清楚工具的边界：这个工具能做什么、不能做什么，比它详细的参数更优先
• 说明何时使用：给出典型使用场景和触发条件，减少模型误调用
• 写明错误的常见原因：如果工具频繁失败，把常见报错原因写进工具描述里，让模型出错后可以自行排查

举个例子，同样是"调用搜索引擎"，一段反面示例是这么写的：

工具：search_web(query, max_results=10) 功能：执行网络搜索 参数：query（字符串），max_results（整数）

经过程式化描述后的正面示例：

工具：search_web 适用场景：需要获取最新信息、验证事实、查找背景资料时 功能：执行网络搜索并返回网页快照和摘要列表 参数： - query（字符串，必填）：搜索关键词，可包含引号以精确匹配 - max_results（整数，可选，默认10）：返回结果数量，最多50 使用限制：不支持布尔操作符（AND/OR），如需排除词，请在query中直接使用"-关键词"格式 常见错误： - 若query过长（超过100字符）返回空结果，请精简为2-3个核心关键词 - 若返回大量无关结果，请在query中增加指定领域或时间范围词

给工具描述增加这些"上下文"信息，会让Agent的工具调用成功率明显提升。因为大多数Agent的失误，不是因为模型笨，而是它掌握的信息不足以让它做出恰当的判断。你在工具描述里多给的每一分信息，都是在帮模型降低决策难度。

3.4 上下文管理模式：避免"记忆稀释"和"关键信息丢失"

自主代理的上下文本地很大，尤其在长任务运行过程中，每一步的中间输出都在累积。超过一定范围后，最直接的后果是"记忆稀释"——模型对最开始的目标和约束的注意力越来越弱，开始更多关注最近的上下文，也就是把全局目标给忘了。

这是个非常现实的工程难题。我目前用的策略是"三级上下文管理"：

• 核心上下文（永久保留）：任务全貌、最终目标、核心约束、交付格式
• 工作上下文（滑动窗口）：当前阶段和上一阶段的输入输出、工具记录
• 阶段上下文（临时读取）：当前步骤的详细说明、当前步骤的工具描述

核心上下文是每次调用模型时都会注入的，只不过如果内容太长，我会做压缩处理，只保留最关键的目标描述和约束清单。工作上下文则随运行推进不断滑动更新，丢到一定长度后就总结成摘要。这样做既可以减少token消耗，又能保证关键目标信息始终在模型的视野里。

这个思路来自我对"人类项目经理"的模仿：真正的项目经理不会每天都把二百页的项目计划书从头到尾读一遍，他总是只盯着里程碑节点、风险和当前任务安排。Agent的上下文管理也应该复刻这种"分轻重、分层级"的信息管理方式。

3.5 输出规范模式：从"自由文本"到"结构化交付"

我在早期调试Agent时，最头疼的问题之一就是输出格式不稳定。今天让Agent输出JSON，它有可能是规范的；明天换一个数据分布，它就偷偷在JSON外面加了"以下是结果"的说明。

解决输出不稳定最有效的方法是"输出规范前置+多重示例"。在提示词中把输出格式指示放在目标定义之后，并且必须提供1到2个完整的示例，而不是只靠文字描述。

示例的作用是给模型一个"锚点"。很多模型的格式遵循能力其实依赖于内部模板匹配，你给它一个具体的正例，它对齐格式的准确率会大幅提高。

我还会在输出规范中约定自校验规则：

输出前请检查： - 所有JSON字段名是否与模板完全一致（禁止新增或改名） - 数据是否按升序排列 - 所有金额字段是否保留两位小数 - 若任何检查不通过，请重新生成输出

这类"后置校验"指令能大幅减少格式层面的低级错误。但注意：不要设置太多校验项，模型记不住。最多列三到四条，超过这个数，它就会开始在无关紧要的格式细节上反复纠结，反而拖慢速度、浪费token。

3.6 安全与鲁棒性模式：给"失控"提前留好退路

这个可能是最不容易被初学者想到，但却是生产环境里最重要的一块。自主代理和普通聊天应用最大的区别在于：Agent是会实际执行操作的，一旦它跑偏，影响是真实的，不止是生成一段错误文本那么简单。

在设计提示策略时，必须显式地嵌入"失控兜底机制"。我的常用做法：

• 定义危险操作清单：哪些操作必须先申请确认才能执行（例如：删除文件、覆盖数据、发送对外邮件）
• 添加熔断条件：如果连续失败N次，或输出结果一直无法通过校验，Agent必须停下来并通知人工，不允许无限重试
• 设置幻觉防线：如果发现某个关键数据无法获取或验证，明确允许Agent在最终报告里写"数据不可得"，而不是编造一个合理的数值

不要默认模型有"常识"。它不会因为启动了"删除文件"工具就意识到这是个高风险操作，它只会觉得自己在执行任务中的一环。你必须在提示词中显式地定义什么情况下它是"越权"了。

4. 经典Agent场景的提示策略实战拆解

4.1 场景A：自动数据采集Agent的提示设计

一个典型的采集Agent任务，是"去某官方网站找到上季度的财报PDF并下载，提取其中三张报表的关键数据，汇总成Excel"。听起来简单，实际跑起来会遇到一堆"偷偷跑偏"的情况。

我早期版本的全局提示词是这样的：

你将帮助用户从指定网站下载财报并提取数据。

效果可想而知：Agent经常下载错误年份的文件，或者把摘要中的数据当成了报表正文数据。后来我将其重建为以下版本，关键改动是加上了"任务全貌"和"验收标准"：

任务全貌： 用户需要分析某公司上季度经营情况，需要获取官方发布的季度财报PDF，提取其中的利润表、资产负债表、现金流量表三类关键数据。 进度路径：搜索官方页面 -> 定位最新季度报告 -> 下载PDF -> 提取表格 -> 结构化输出 成功标准： - 下载的PDF确实是目标公司的最新季度报告 - 每个报表提取的字段不少于30项 - 数据的数值和单位与PDF原文一致 - 输出Excel包含3个Sheet，每个Sheet的列名与预设模板完全一致 当前阶段：搜索官方页面

这段提示词的关键在于成功标准部分。Agent在执行中遇到困惑时，会回到"成功标准"审视自己的行为，从而减少盲目的自由发挥。

4.2 场景B：多工具协作Agent的提示编排

当Agent需要同时使用数据库查询、API调用、文件读写等多个工具时，容易出现的典型问题是"错误地选择了工具"，或"在一个工具上毫无意义地反复重试"。

我在提示策略里引入了"工具选择决策树"来帮助模型做判断，效果很好：

工具决策规则： - 当需要获取结构化历史数据时，优先使用SQL查询，而不是网络搜索 - 当需要查找最新公开信息时，优先使用搜索工具 - 当某工具连续失败2次，禁止继续重试，自动切换到备选工具或修改输入方式 - 当所有数据获取方案失败时，进入人工确认状态，不允许编造或推测数据

这套规则写在全局提示的最显眼位置，必要时我会把它做成一张"工具路由表"，即以表格形式列出来源和对应工具，再明确标注优先级。模型是能理解"优先级"这个概念的。前提是你给它的分级标准足够清晰，不能是"尽量""通常"这种模糊表述。没有明确数值或条件的优先规则，模型在决策时依然会犹豫并出错。

4.3 场景C：面向长周期任务的记忆与状态管理提示

长周期任务是指那些需要跑几小时甚至几天的Agent任务，比如"持续监测一个话题的舆论变化并每日输出简报"。这类任务面临的独特挑战是：Agent的上下文会随着每天的执行快速膨胀，而且隔了一天之后，它容易忘记昨天已经做过什么。

我的做法是在运行时构建一个"状态摘要机制"，每次任务推进到新一天时，把之前的关键结果存储状态和未完成事项压缩成结构化摘要，注入到下一轮会话的提示词里。摘要有固定模板：

项目名：【舆论监测日报】 当前日期：2025-06-10 已完成步骤： - 06-09：抓取主要平台相关讨论数据，共500条 - 06-09：完成情感分析，正面/负面/中性比例为2:1:3 - 06-10 上午：生成初步趋势对比，发现与上周同期变化+20% 未完成事项： - 需要跟踪3个高热度事件下的评论变化 - 06-10 的汇总报告尚未生成 当前状态评估：整体进展正常，无严重偏离

这不仅是给模型看的信息，它同时也是给人类用户看的进度报告。把状态记录结构和提示词结构统一起来，可以省掉一层转换步骤，也是提高系统可维护性的一个好习惯。

你可以把这种思路扩展到任意长期项目里。唯一要提醒的是，摘要内容要避免太冗余，状态摘要建议控制在200个token以内。如果摘要本身太长，模型阅读它的注意力会下降，而且每次会话都要带上大量与当前任务无关的旧状态，也很浪费。

5. 提示策略架构师的核心工作流

5.1 从业务目标到提示需求的分析方法

很多开发者其实是"倒着干"的：先写提示词，再往上糊工具、接业务流程。结果就是Agent跑起来到处是漏洞，补丁越打越多，系统变成一团乱麻。

我这里分享一个标准的正向流程，也是我每次做Agent时都会走的路径：

• 第一步：定义最终交付物。把Agent做完一件事后，人类用户拿到的结果是什么，用一张A4纸写清楚
• 第二步：回溯执行路径。要做出这个交付物，需要经过哪些阶段、哪些工具、哪些数据来源，全部列出来
• 第三步：定义关键决策点。在哪些地方，Agent需要自己判断走哪条路？判断的依据是什么？（这一项经常被跳过，但这恰恰是最容易产生价值的地方）
• 第四步：设计反馈循环。Agent如何知道自己做得好不好？从哪里拿到反馈信号？（如果只有到结束时才有人类反馈，那就等于没有反馈）
• 第五步：编写提示词结构。把以上分析结果对应映射到提示词的各个段落中

在每个步骤里，务必标注哪些信息是"必须准确"的，哪些信息是"允许推测"的。这能帮后人在迭代时更有针对性，避免改提示词时波及到不该动的部分。

5.2 编写提示词时的常见陷阱

我总结了六条常见陷阱，这些都是我在项目中真实遇到过的坑：

• 目标模糊：写"分析数据"，却不说明从什么角度分析、为何分析、希望得到什么形态的结论
• 约束泛滥：列出二十条禁止事项，重要信息完全淹没在不重要的信息里，模型根本分不清轻重
• 假设过多：默认模型知道某些背景信息，实际上模型对这个项目的了解几乎为零
• 步骤过少或过多：要么只给一个大目标让模型自由发挥，要么把每一步都锁定得死死的毫无弹性
• 缺乏容错设计：如果Agent做错了，没有任何恢复路径，只能整条任务失败重来
• 忽视功耗与成本：没有在提示策略里考虑token消耗和延迟，等到账单出来傻眼了

5.3 如何建立可复用的提示模板体系

同一家公司或同一个项目里，Agent的数量可能不止一个。如果每次开发都是从头开始设计提示词，你会累死，而且质量还不稳定。

我建议建一套公司的"提示模板库"，基础模板包括：

• 任务分解型模板（适合多步骤分析项目）
• 工具编排型模板（适合涉及多系统调用的自动化流程）
• 生成创作型模板（适合内容产出类Agent）
• 审核校验型模板（适合作为质量门禁的角色）

每个模板都留出明确的可配置插槽，比如"目标描述""成功标准""受限制操作"等。执行团队在接新项目时，不是从空白开始写提示词，而是从模板库里选一个最接近的，再做二次适配。这样做的好处是：当A项目的提示词出现问题并修复后，修复经验可以沉淀回模板中，B项目再使用时能自动避坑。

6. 从单Agent到多Agent协作：提示策略如何升级

6.1 多Agent架构下的提示职责分离

单Agent的提示策略再优化，它的上下文长度和记忆容量依然有限。当我开始做需要多角色协作的项目（比如"市场调研+方案策划+文案输出"）时，发现把全部能力塞进一个Agent里，效果越来越差。

原因是"角色混淆"：一个有能力做调研的Agent，并不意味着它也有能力做好文案。当它身兼数职时，模型会开始"串味"，调研环节带着文案腔调，写文案时又突然开始列数据表格。

我在实践中换成多Agent架构后，提示策略也跟着改变了。每个Agent只承担一部份职责，它的提示词也因此可以写得极度聚焦：

• 调研Agent：只负责收集、清洗、结构化信息。它的成功标准是"数据完整率""引用来源数"而非"文笔好坏"
• 分析Agent：只负责从结构化数据里提取洞察，它的成功标准是"逻辑是否自洽""结论是否有数据支撑"
• 写作Agent：只负责基于分析结果生成文稿，它的成功标准是"是否准确传达了分析结论""是否贴合目标读者"

这种模式下，每个Agent的提示词可以相对简化，系统整体的协同效果反而大幅提升。多Agent协同的关键点在于：每个Agent"交接"给下一个Agent时的输出，必须足够规范和结构化，否则会累积噪声，越到下游越混乱。所以我在提示策略里会特别强调"交接格式"的严格性。

6.2 消息传递与上下文交接的设计原则

多Agent之间的消息传递，其实也是一种变相的提示设计。你给下一个Agent传递的"上下文消息"，就是它开始工作的提示词的一部分。

我最常犯的错误，是让上一个Agent输出"整篇分析报告"后就完事，下一个Agent自己去报告里找重点。结果就是重要观点被埋没在长文本里，下一个Agent抓错了核心。后来我约定了标准的交接摘要格式：

信息摘要： - 核心发现：1-3条，每条尽量不超过50字 - 支撑数据：每条发现对应的数据或案例来源 - 关键限制：有哪些信息无法获取，对分析是否有方向性影响 - 推荐下一步：建议下一个Agent优先关注的内容

这份交接摘要被我用JSON格式固化下来，使每个Agent在处理时都能快速聚焦到关键信息点上。别小看这一步实践，在真正跑通一些复杂流程之前，我总以为"多重上下文传递"没那么重要，但现在我认为这就是多Agent稳定性最关键的环节之一。又一个多次踩过的坑。

6.3 协调Agent与执行Agent的提示差异

在多Agent架构中，还需要区分"协调者"和"执行者"两类角色。

协调Agent的提示词更关注"全局进度管理"：它需要知道整个系统有多少个子任务、每个子任务的进度和依赖关系，以及某个子任务卡住时应该如何处理。它的成功标准不是得出某个具体的业务结论，而是整个系统正常运行完毕。

执行Agent的提示词则更关注"局部执行质量"：怎么正确使用工具、怎么保证输出格式、怎么自查结果。它不需要也不应该关心全局有多少个Agent在并行工作。

这两类提示的差异如果分不清，就会导致一个常见现象：协调Agent开始插手执行细节，把执行Agent的工作抢了；或者执行Agent开始思考"全局目标是什么"，而忽略了眼前的具体操作。把各自的职责边界用提示词明确区隔开，是稳定协作的基础。

7. 评测、调优与落地经验总结

7.1 如何度量提示策略的好坏

做提示工程最怕的就是"凭感觉"。很多人调了几版提示词后说"感觉好多了"，但其实你问他"好在哪里""准确率提升了多少"，他根本回答不上来。

在自主代理项目里，我建议建立一个多维度的评测体系：

• 任务成功率：整套流程能完整跑完的比例
• 步骤通过率：单个步骤一次通过的比例，这个指标能帮你定位瓶颈在哪里
• 偏离率：Agent在执行中偏离预设目标路线的频率
• 资源消耗率：平均每个任务消耗多少token、多少次工具调用、花了多长时间

这些指标应该在做提示优化前先做一轮baseline收集，每次改动提示词后重新测量，用数据说话。如果你发现"任务成功率没变，但token消耗下降了30%"——那这个改动也是很有价值的，因为它让系统更省钱了。

7.2 从v1到v2的迭代路径：一个实际的调优案例

为了讲明白迭代过程，我用一个虚构但非常典型的案例来复盘。

项目背景：做一个"自动生成竞品分析报告"的Agent。v1版本用的是大而全的提示词，所有流程一个Agent从头跑到尾。实测结果是：简单场景下效果尚可，一遇到数据缺失、网页访问失败等异常情况，整个流程就崩了，成功率大概只有40%。

v1到v2的改进，我做的最重要一件事是"调整目标定义方式"。原来v1的目标是"生成一份全面的竞品分析报告"，v2改成"找到目标竞品至少5个可验证的核心差异点，并整理成决策摘要"。目标一改，"全面"这个模糊词变成了"5个差异点"这个可验证的、具体的标准。Agent在执行过程中对什么信息值得关注、什么信息可以跳过，判断起来都比之前清楚得多。

下一步则是把"单Agent"改成"调研+分析+写作"三个Agent的流水线。改造后报告质量更稳定，因为写作Agent不需要同时干调研的活，上下文更聚焦。最终在同等测试集上，成功率从40%提升到75%左右，token消耗反而下降了20%，算是比较典型又成功的一次迭代。

7.3 投产后仍需持续监控的提示策略风险

上线后并不代表工作结束，反而是一些只在生产环境才会暴露出的问题开始冒头。比如:用户实际输入的数据分布和测试时差别很大，Agent开始产生意料之外的决策路径；或者某个上游系统的返回值格式变化了，Agent的解析逻辑没有跟着变化，导致大面积失败。

我现在的做法是在Agent的每个关键出口都加上日志和结构化监控。每一次工具调用的输入输出、每个阶段的决策记录，全部落日志。只有日志足够详细，你才能在Agent出现问题之后复盘出它到底在哪里做的错误决定。

我见过太多团队把精力集中在写提示词时的"聪明技巧"上，反而忽视了运行时观测这一块。其实对于长周期自主运行的Agent来说，日志和监控不是辅助功能，它就是提示策略的一部分。没有好的观测手段，你根本无从知道你的提示策略在现实世界中的真实表现。

8. 一点私人感想

做提示工程这么久，我的最大感受是：它缺的不是"灵感"和"技巧"，而是方法和体系。那些看起来很华丽的提示技巧，都没法支撑起一个长期稳定运行的生产级Agent。真正让Agent从"能用"走到"好用"的力量，来自对目标的执拗拆解、对边界的清晰划定、对反馈闭环的精密设计，以及对运行时数据的认真围观。

如果你正在做自己的第一个自主代理，给出一条实际经验：不要一上来就想做出完美的全流程，先让它走通一个只有两步、三步的最小闭环，加上日志和验证，然后再逐步扩展。踩了坑、复盘、修改提示，又踩新的坑——整个螺旋上升的过程，才叫真正的"从0到1"。

最后再分享一个小细节：你在提示词的任何段落里遇到的模糊词，比如"更好""合理""全面"——把它们当成红色警报。每出现一个模糊词，就意味着模型获得了自由裁量权，也就意味着它在你的系统里埋下了一个你不知道它如何执行的"自由变量"。逐个消灭模糊词，你的提示策略的可靠性就会向上跨一个台阶。