谷歌Agent Skill设计模式实战：从工具调用到规划型，5种模式提升生产稳定性

1. 从“能跑通”到“跑得稳”Agent Skill 设计模式到底在解决什么问题很多人第一次接触 Agent 开发时都会经历一个相似的阶段写一个能调用工具的循环接上大模型跑通一个“查天气”“搜资料”“发邮件”的 Demo然后觉得“Agent 不过如此”。但真正把它放到生产环境里问题就来了——同一个任务今天跑得通明天就卡在某个环节工具调用顺序稍微一变整个流程就崩模型偶尔“自作主张”跳过一个关键步骤结果输出完全不可用。这些问题的根源往往不在模型本身而在于Skill 的设计方式。所谓 Skill可以理解为 Agent 在完成某个具体任务时所依赖的能力单元——它可能是一次工具调用、一段提示词模板、一个多步推理流程或者几者组合。Skill 设计得好Agent 就像一个有经验的员工知道什么时候该做什么、做到什么程度算完成设计得不好Agent 就像一个只会背说明书的新人遇到一点变化就手足无措。谷歌官方在 Agent 开发实践中总结出的 5 种 Skill 设计模式本质上是在回答一个问题如何把“不确定的模型能力”封装成“相对确定的任务执行单元”。这 5 种模式不是互斥的而是可以组合使用的工具箱。理解它们的适用场景和边界比记住名字重要得多。这篇文章会从实际开发视角出发逐一拆解这 5 种模式的核心逻辑、适用场景、实现要点以及我在实际项目中踩过的坑。无论你是刚接触 Agent 开发的新手还是已经写过一些 Skill 但总觉得“不够稳”的开发者都能从中找到可以直接复用的思路。2. 模式一工具调用型 Skill——最基础也最容易被低估2.1 为什么“会调工具”不等于“会用工具”工具调用型 Skill 是绝大多数人接触 Agent 时最先实现的一类。它的逻辑很直接给模型一个工具列表模型根据用户输入决定调用哪个工具、传什么参数然后拿到结果继续处理。看起来很简单但实际开发中这一层最容易出问题。我见过不少项目工具定义写得非常随意比如一个“搜索”工具参数只有一个query描述写的是“搜索相关内容”。结果模型经常把整段用户输入原封不动塞进query甚至把不该搜索的内容也拿去搜。问题不在模型而在于工具描述没有给出足够的约束和示例。一个合格的工具调用型 Skill至少要把三件事说清楚什么时候用、怎么用、用完怎么判断结果是否有效。这三件事分别对应工具描述、参数定义和返回结果处理。2.2 工具描述怎么写才“不歧义”工具描述不是写给用户看的是写给模型看的。它的核心目标是让模型在正确的时间选择正确的工具。我通常会用这样的结构来写描述一句话定位这个工具是做什么的一句话说清楚。适用场景列出 2-3 个典型触发条件用自然语言描述。不适用场景明确写出什么情况下不应该用这个工具这一点很多人会忽略但非常关键。参数说明每个参数不仅要写类型还要写“什么情况下传什么值”。返回说明返回结果的结构、含义以及什么情况下算“没查到”。举个例子假设有一个“查询订单状态”的工具描述可以这样写用于查询用户订单的当前状态。当用户询问“我的订单到哪了”“订单为什么还没发货”“订单是否已签收”时使用。不适用于查询物流轨迹详情应使用物流查询工具或修改订单信息。参数 order_id 为用户订单编号格式为纯数字若用户未提供订单号应先询问用户。返回结果包含 status 字段可能值为 pending、shipped、delivered、cancelled若返回 not_found 表示订单号不存在。这样的描述看起来啰嗦但实测下来模型选错工具的概率会明显下降。原因很简单模型在做选择时依赖的是语义匹配你给的约束越具体它的决策空间就越小出错概率自然越低。2.3 参数校验和兜底逻辑不能省即使描述写得再好模型仍然可能传错参数。这时候不能指望模型自己纠正必须在 Skill 层面做校验和兜底。我的做法是在工具执行前加一层参数校验比如def validate_order_query(params): order_id params.get(order_id, ).strip() if not order_id: return {error: missing_order_id, message: 请提供订单编号} if not order_id.isdigit(): return {error: invalid_order_id, message: 订单编号应为纯数字} return None如果校验不通过不要直接抛异常而是返回一个结构化的错误信息让模型知道“哪里错了、应该怎么补救”。这样 Agent 就有机会重新向用户询问而不是直接崩溃。注意工具调用型 Skill 的稳定性80% 取决于描述和校验20% 才取决于模型本身。不要把所有问题都归咎于“模型不够聪明”。3. 模式二提示词链型 Skill——把复杂任务拆成可管理的步骤3.1 什么时候该用提示词链而不是一个大提示词有些任务用单个提示词就能完成比如“把这段话翻译成英文”。但更多任务其实是多步的比如“分析一份合同的风险点并给出修改建议”。如果你试图用一个提示词搞定结果往往是模型顾此失彼——要么分析不深入要么建议不具体。提示词链型 Skill 的思路是把一个大任务拆成若干个小步骤每一步用一个独立的提示词完成前一步的输出作为后一步的输入。这样做的好处是每一步的职责单一模型更容易聚焦输出质量更稳定也更容易调试——哪一步出了问题直接看那一步的输入输出就行。3.2 链式拆分的粒度怎么把握拆分粒度是提示词链设计中最关键也最难拿捏的地方。拆得太粗等于没拆拆得太细步骤之间来回传递信息反而容易丢失上下文。我的经验是每一步只做一件事且这件事可以用一句话描述清楚。比如“分析合同风险”可以拆成提取合同中的关键条款付款、违约、保密、终止等。对每个关键条款进行风险评级高/中/低。针对高风险条款生成修改建议。汇总输出结构化报告。每一步的输出都是下一步的明确输入步骤之间没有歧义。如果某一步的输出格式不稳定下一步就会受影响所以每一步最好都定义清楚输出结构比如用 JSON 或固定字段的 Markdown。3.3 链式 Skill 的中间结果要不要暴露给用户这是一个实际开发中经常纠结的问题。我的建议是中间结果默认不暴露但保留可追溯能力。用户只关心最终结果中间步骤暴露太多反而干扰体验。但如果最终结果有问题你需要能快速定位是哪一步出了偏差所以每一步的输入输出都要记录日志。另外链式 Skill 的每一步都可能失败所以要有重试和降级机制。比如第三步“生成修改建议”失败了可以降级为“只输出风险条款不生成建议”而不是整个任务失败。4. 模式三路由型 Skill——让 Agent 知道“该找谁”4.1 路由的本质是分类但比分类多一层路由型 Skill 的核心逻辑是根据用户输入判断应该交给哪个子 Skill 处理。听起来像是一个分类任务但它比普通分类多了一层——分类之后还要触发对应的执行流程。比如一个客服 Agent用户可能问订单问题、退款问题、产品咨询、投诉建议。路由 Skill 要做的不仅是判断“这是退款问题”还要把请求转给退款处理 Skill并确保上下文正确传递。4.2 路由判断的三种实现方式对比实际开发中路由判断有三种常见实现方式各有优劣方式实现逻辑优点缺点适用场景关键词匹配根据预设关键词判断速度快、可控性强覆盖不全、容易误判意图非常明确的简单场景模型分类用模型判断意图灵活、覆盖广有延迟、可能不稳定意图复杂、表达多样的场景混合方式先关键词兜底再模型判断兼顾速度和灵活实现复杂度较高生产环境推荐我在实际项目中更倾向于混合方式先用关键词做一层快速匹配命中明确意图的直接路由没命中的再交给模型判断。这样既保证了常见场景的响应速度又保留了处理长尾情况的能力。4.3 路由错误的代价比想象中大路由一旦出错后续所有步骤都是白费。用户问退款你路由到产品咨询模型再努力也答非所问。所以路由 Skill 要特别关注两点一是置信度阈值二是兜底策略。置信度低于阈值的不要强行路由而是触发澄清流程比如“我不太确定您是想咨询退款还是产品问题能再说明一下吗”兜底策略则是当所有路由都失败时转人工或给出通用引导而不是让 Agent 胡乱回答。5. 模式四反思型 Skill——让 Agent 学会“检查自己的作业”5.1 反思不是自我怀疑而是结构化校验反思型 Skill 的核心是在生成结果之后增加一个校验步骤检查结果是否满足要求如果不满足则触发修正。这就像学生做完作业后检查一遍而不是交上去等老师批改。但反思不是让模型“再想想”而是要有明确的校验标准。比如生成一段代码后反思 Skill 要检查语法是否正确、是否覆盖了所有需求点、是否有明显的边界问题。这些检查项要提前定义好而不是让模型自由发挥。5.2 反思 Skill 的两种触发时机反思可以在两个时机触发生成后立即反思和执行后根据结果反思。生成后立即反思适用于纯文本生成类任务比如写文案、生成报告。模型生成完马上用另一个提示词检查质量不合格就重新生成。执行后反思适用于有实际动作的任务比如调用 API、修改数据。动作执行完检查返回结果是否符合预期不符合则回滚或重试。两种时机的选择取决于任务是否“可逆”。可逆的任务可以大胆执行后反思不可逆的任务最好在生成阶段就反思到位。5.3 反思的循环次数要设上限反思型 Skill 最容易踩的坑是“无限反思”——模型每次都觉得还能更好反复修改既浪费时间又可能越改越差。我的做法是设置最大反思次数通常 2-3 次就够了。超过次数还没通过校验就输出当前最优结果并标记“未完全通过校验”而不是继续循环。提示反思 Skill 的校验标准要具体、可量化。比如“检查是否包含所有 5 个要点”比“检查内容是否完整”有效得多。6. 模式五规划型 Skill——把“怎么做”交给 Agent 自己决定6.1 规划型 Skill 和提示词链的区别提示词链是开发者提前把步骤定好Agent 按部就班执行。规划型 Skill 则是把“定步骤”这件事也交给 Agent——给它一个目标让它自己拆解任务、决定先做什么后做什么、需要调用哪些工具。这两者的区别很像“按菜谱做菜”和“给你一堆食材自己发挥”。前者稳定但不够灵活后者灵活但容易失控。规划型 Skill 适合那些步骤不固定、需要根据中间结果动态调整的任务比如“帮我调研一下某个技术方案的可行性”。6.2 规划型 Skill 的三个关键控制点规划型 Skill 最大的风险是“跑偏”——Agent 规划了一堆步骤但方向完全错了。要控制这个风险需要抓住三个关键点第一目标描述要足够具体。“调研技术方案”太模糊“调研某个技术方案在中小规模团队中的落地成本、主要风险和替代方案”就具体得多。目标越具体Agent 的规划越不容易跑偏。第二中间产物要可检查。不要让 Agent 一口气跑完所有步骤才输出结果而是每完成一个子任务就输出中间产物方便你或另一个校验 Skill 检查方向是否正确。第三设置最大步骤数。规划型 Skill 容易陷入“过度规划”设置一个合理的步骤上限比如 10 步超过就强制输出当前结果。6.3 规划型 Skill 的适用边界不是所有任务都适合用规划型 Skill。我的判断标准是如果任务的步骤可以被提前定义就用提示词链如果步骤高度依赖中间结果才用规划型。滥用规划型 Skill 会让简单任务变复杂增加不确定性和调试难度。7. 五种模式怎么组合一个实际项目的设计思路7.1 从任务特征反推模式选择单独理解五种模式不难难的是在实际项目中判断该用哪种、怎么组合。我的做法是先分析任务特征再反推模式。假设要做一个“技术文档问答 Agent”用户提问Agent 从文档库中找答案并生成回复。这个任务的特征是需要检索、需要判断检索结果是否相关、需要生成结构化回答、可能涉及多轮追问。对应到模式选择检索环节用工具调用型 Skill判断相关性用反思型 Skill生成回答用提示词链型 Skill多轮追问的路由用路由型 Skill。如果问题复杂到需要多步检索和推理再引入规划型 Skill。7.2 组合时的层级关系要清晰多种模式组合时最容易出问题的是层级混乱——哪个 Skill 调用哪个 Skill上下文怎么传递错误怎么冒泡。我的经验是把路由型 Skill 放在最外层做分发工具调用和提示词链放在中间层做执行反思型 Skill 放在内层做校验规划型 Skill 根据任务复杂度决定是否启用。这样分层的好处是每一层的职责清晰调试时也能快速定位问题出在哪一层。7.3 一个常见的组合误区很多人喜欢把所有模式都堆到一个 Agent 里觉得“功能越全越好”。结果就是 Agent 变得极其复杂一个简单问题也要走完所有流程响应慢、成本高、还容易出错。正确的做法是按需组合。大部分任务用工具调用加提示词链就能解决反思和规划只在必要时启用。路由 Skill 也不是必须的如果 Agent 只处理单一类型任务直接执行就行。8. 实测中总结的几条经验8.1 先跑通单模式再考虑组合我见过不少项目一上来就设计复杂的多模式组合结果每个模式都没调好整体效果很差。更稳妥的路径是先把单个模式跑通、调稳确认它在你的场景下有效再考虑和其他模式组合。单模式都跑不稳组合只会放大问题。8.2 日志和可观测性比想象中重要Agent 的调试难度远高于普通程序因为它的行为有不确定性。没有详细的日志你根本不知道模型为什么选了那个工具、为什么跳过了那个步骤。我的做法是每一步的输入、输出、耗时、模型决策理由都记录下来出问题时能快速回溯。8.3 不要追求“全自动”该让人介入就介入有些任务模型确实做不好或者做错的代价很高。这时候不要硬撑设计一个人工介入的节点让用户确认或修正。比如涉及金额、删除操作、对外发送的内容加一道确认流程比事后补救成本低得多。8.4 模式是参考不是教条这五种模式是谷歌从实践中总结出来的参考框架不是必须严格遵守的规范。实际项目中你可能会发现某种模式需要调整或者需要创造新的组合方式。关键是理解每种模式背后的设计意图——控制不确定性、提高可调试性、保证任务完成质量——然后根据你的具体场景灵活运用。我在最近一个项目中就把工具调用和反思做了深度结合每次工具调用后都加一个轻量级的反思步骤检查返回结果是否合理不合理就换一种调用方式重试。这个改动让整体成功率提升了将近三成而增加的延迟不到 200 毫秒。这种基于实际数据的微调比生搬硬套模式有效得多。最后分享一个小技巧如果你不确定该用哪种模式先问自己一个问题——这个任务最容易出错的地方在哪里是选错工具、步骤太多、方向跑偏还是结果质量不稳定找到最薄弱的环节再选择对应的模式去加固比盲目套用要高效得多。