历经多个业务系统的构建，我深感 Anthropic 的《Build effective agents》一文与自身实战经历高度契合。本文在详解工作流与 Agent 的技术选型标准、设计模式应用及实施要点的同时，也融入了我的实战心得与实践经验总结。无论您正考虑构建工作流系统还是 Agent 系统，都能在此找到适合场景的最佳实践方案。特别值得关注的是文末的工具提示工程部分，这是 Agent 成功实施的关键因素。
本文从 Anthropic 的文章《Build effective agents》出发，为构建高效的工作流、Agent 提出实战指南。我在保留原文精华的基础上增强了三个核心方面：
核心内容
1.技术选型指南：明确工作流/Agent 选用标准。
2.设计模式解析：通过实际业务场景展示复杂工作流模式的应用。
3.实践要点扩展：增添详细的实施建议和操作要点，将理论转化为可执行方案。
本文适合 AI Agent 技术管理者、开发者、产品经理及爱好者阅读，通过实践层面的指导，帮您实现更合理的方案与更高效的实施。
文章概览
1. Agent 概述
1.1 什么是 Agent？
"Agent"有多种定义方式。部分客户将其视为完全自主系统，能在较长时间内独立运行，使用各种工具完成复杂任务。也有人用此术语描述更固定的、预定义的工作流。Anthropic 将这些变体归类为类 Agent 系统，但在工作流和智能体间做了重要区分：
2.2 Workflow V.S Agent
在附录 1("Agent 实战")中，Anthropic 描述了客户在使用这类系统时发现特别有价值的两个应用领域。
2. 何时使用 Agent
2.1 简单性原则：适用场景评估
Anthropic 强烈建议：在构建 LLM 应用时，寻找尽可能简单的解决方案，只在必要时增加应用复杂性。
关键权衡：类 Agent 系统通常以延迟和成本为代价换取更高性能，应谨慎评估这种取舍。
复杂性增加的指导原则：
- 选择工作流：当任务明确定义，需要可预测性和一致性
- 选择 Agent：当任务需要灵活性和模型驱动的动态决策
重要提示：对许多应用而言，优化单个 LLM 调用（通过检索增强和上下文示例）通常已足够有效。
3. 何时、如何使用“Agent 框架”
3.1 框架使用的权衡考量
开发框架虽然便捷，但常存在过度抽象问题，使底层提示词和 LLM 调用被隐藏。这导致两个主要风险：
- 使用框架开发的 Agent 系统难以有效调试
- 简化的搭建流程使开发者容易过度增加系统复杂性
3.2 实用开发建议
Anthropic 建议采取渐进式开发方法：
- 优先直接使用 LLM API：大多数模式可通过几行代码实现
- 深入理解框架底层：如选择框架，确保理解其内部工作机制
- 避免错误假设：对框架底层工作原理的误解是项目失败的常见原因
“我们建议开发者直接使用 LLM API：许多模式可以用几行代码实现。如果你使用框架，请确保理解底层代码。对底层工作的错误假设是客户错误的常见来源。”
参考 Anthropic 的 cookbook[1]获取示例实现。
4. 类 Agent 系统设计模式
本节探讨生产环境中常见的类 Agent 系统模式。Anthropic 从基础构建模块——增强型大语言模型(LLM)开始，逐步增加复杂性，从简单组合工作流到自主 Agent。
4.1 增强型 LLM 模式
定义：类 Agent 系统最基础的模块是"增强的 LLM"，即具备检索、工具使用和记忆等功能的语言模型。Anthropic 当前的模型能够主动使用这些功能——生成搜索查询、选择合适工具以及确定需要记忆的信息。
增强型 LLM
工程实现的关键要点：
- 为特定应用场景定制增强能力
- 确保为 LLM 提供简单、文档完善的接口
虽然实现这些增强功能的方法很多，一种推荐方式是通过 Anthropic 最近发布的 模型上下文协议2，该协议允许开发者通过简单的客户端实现与不断扩展的第三方工具生态系统集成。
4.2 工作流模式
4.2.1 提示链
定义：提示链将任务分解为一系列有序步骤，每个 LLM 调用处理前一个调用的输出。可在任何中间步骤添加程序检查（"门控"）以确保流程保持在正确轨道上。
提示链工作流
适用场景：
- 任务可以轻松且清晰地分解为固定子任务时
- 主要目标是通过牺牲延迟来提高准确性，使每个 LLM 调用处理更简单的子任务
应用示例：
- 生成营销文案，然后将其翻译成不同的语言。
- 编写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档。
4.2.2 路由
定义：路由工作流对输入进行分类并将其引导到专门的后续任务。这种工作流实现关注点分离，并构建更专门化的提示。不使用路由时，为某一类输入优化可能会降低其他类型输入的处理效果。
路由工作流
适用场景：
- 复杂任务包含明显不同类别需要单独处理
- 分类可由 LLM 或传统分类模型/算法准确完成
应用示例：
- 引导不同类型客户服务查询（一般问题、退款请求、技术支持）进入不同的下游流程、提示和工具。
- 将简单/常见问题路由到较小模型（如 Claude 3.5 Haiku），将困难/不常见问题路由到更强大模型（如 Claude 3.5 Sonnet），优化成本和响应速度。
4.2.3 并行化
定义：并行化工作流让 LLM 同时处理多个任务，并通过程序化方式聚合输出。分为两种关键形式：
- 任务拆分（Sectioning）：将任务拆分为独立的子任务并行运行
- 投票（Voting）：多次运行相同任务以获得不同的结果
并行化工作流
适用场景：
- 当拆分的子任务可以并行处理以提高速度
- 需要多种视角或不同尝试来获得更高置信度的结果时
- 复杂任务涉及多种考虑因素时，由独立 LLM 调用分别处理各因素效果更佳。
应用示例：
- 任务拆分（Sectioning）
- 安全防护机制：一个模型处理用户查询，另一个筛选不合规内容，比单模型同时处理两项功能效果更好。
- 自动化评估 LLM 性能：设置多个并行分支，评估模型在不同方面的表现。
- 投票（Voting）
- 代码漏洞审查：多个并行 LLM 分支审查代码并标记问题。
- 内容审核：并行评估内容合规性，不同提示专注于不同评估维度，通过差异化投票阈值平衡误报率与漏报率。
应用案例：内容审核系统
假设我们正在构建一个社交媒体平台的内容审核系统，需要评估用户发布的以下内容是否适当：
用户发布内容示例
"这些政客都是垃圾，应该被扔进海里喂鲨鱼。大家都应该去抗议这个荒谬的新政策，让他们知道我们的愤怒！"
实现方案：
1、并行 LLM 提示（专注不同维度）
- 提示 1：评估暴力内容
- 提示 2：评估仇恨言论
- 提示 3：评估不文明用语
- 提示 4：评估合法政治表达
- 提示 5：评估煽动抗议
2、差异化投票阈值设置
1). 暴力威胁：低阈值（高敏感度）
- 提示 1 为"是"→ 内容立即标记
- 理由：潜在危害大，宁可误报也不能漏报
2). 仇恨言论：中等阈值
- 提示 2 和提示 3 都为"是"→ 内容标记
- 理由：需更多证据确认真正仇恨言论
3). 政治表达：高阈值（宽容度高）
- 提示 4 为"是"且提示 1、2 不为"是"→ 允许内容
- 理由：保护合法政治表达，避免过度审查
3、决策流程示例
1). 并行评估结果：
- 提示 1（暴力）："是"（提到"扔进海里喂鲨鱼"）
- 提示 2（仇恨）："否"（针对政客非受保护群体）
- 提示 3（不文明）："是"（使用"垃圾"等贬义词）
- 提示 4（政治表达）："是"（政策批评）
- 提示 5（煽动抗议）："是"（鼓励和平抗议）
2).规则应用：
- 暴力威胁阈值触发（提示 1 为"是"）
- 政治表达规则也满足
- 系统标记为"边缘案例"，转人工审核
系统优势：平衡误报和漏报
这种多方面并行评估系统能够：
- 减少漏报：低阈值捕获严重违规（如明确暴力威胁）
- 减少误报：多角度评估避免过度审查合法内容
- 细粒度分析：识别具体问题方面，非简单二分法
- 差异化风险应对：对不同类型违规设置不同敏感度
这种并行投票系统能同时考虑内容多个维度，根据不同维度的严重性设置差异化决策标准，实现更平衡、更细致的内容适当性评估，特别适合处理复杂边界案例。
4.2.4 编排者-工作者
定义：在编排者-工作者工作流中，编排者（LLM）动态分解任务，将其委派给工作者 LLM，并综合其结果。
编排者-工作者工作流
适用场景：
- 适合无法预测所需子任务的复杂任务
- 与并行化的关键区别在于灵活性——子任务不是预定义的，而是由编排者根据任务输入动态确定
应用示例：
- 需要对多个代码文件进行编辑的编码项目
- 涉及从多个来源收集和分析信息的搜索任务
应用案例：医疗研究助手
假设我们正在构建一个医疗研究助手，研究人员输入了以下查询：
用户查询
"我需要了解最近三年内关于长新冠与认知障碍关联的研究结果，特别是那些包含临床试验数据的研究。"
编排者-工作者工作流实现
- 编排者规划阶段
编排者 LLM 接收查询并制定搜索计划：
搜索计划：
a. 识别关键搜索术语和相关概念
b. 确定需要搜索的最佳来源
c. 为每个来源设计特定搜索策略
d. 分配多名工作者执行不同来源的搜索
e. 汇总和综合所有发现的信息
f. 确定是否需要进一步搜索
g. 准备最终报告
- 工作者执行阶段
编排者将任务分配给多个专门的工作者 LLM：
工作者 1：医学文献搜索
- 任务：在 PubMed 和医学期刊数据库中搜索长新冠与认知障碍相关论文
- 搜索条件：发表于 2022-2025 年间，包含临床试验数据
- 工具：使用 API 接口查询医学数据库
- 产出：找到 15 篇相关论文，包含初步结果摘要
工作者 2：研究机构报告搜索
- 任务：搜索 CDC、WHO、NIH 等机构发布的长新冠研究报告
- 搜索条件：关注认知障碍相关发现
- 工具：机构网站 API 和网页抓取
- 产出：找到 3 份官方报告和 2 个正在进行的研究项目
工作者 3：临床试验数据库搜索
- 任务：在 ClinicalTrials.gov 等数据库中搜索相关临床试验
- 搜索条件：长新冠与认知功能相关，已完成或有初步数据
- 工具：临床试验注册数据库 API
- 产出：识别 7 个相关临床试验，包括 3 个有初步结果的试验
工作者 4：医学会议与预印本资料搜索
- 任务：在研究预印本服务器和近期会议记录中搜索
- 搜索条件：最新未正式发表的研究
- 工具：预印本服务器 API 和会议数据库
- 产出：找到 5 篇预印本论文和 2 个会议演讲
- 信息分析与综合
编排者接收所有工作者的搜索结果，然后：
- 识别重复信息：消除不同来源的重复研究
- 评估证据质量：按照研究设计、样本量、期刊影响因子等标准评估每篇研究
- 识别共同主题：分析跨多个研究的一致性发现
- 发现研究差距：识别缺乏研究的领域
- 权衡相互矛盾的结果：评估不同研究之间的差异原因
- 动态迭代（可选）
编排者可能发现需要进一步信息：
- "注意到大多数研究未考虑年龄分层效应，需要专门搜索老年群体中的长新冠认知影响"
- 分配工作者 5进行补充搜索，聚焦老年人群研究
- 最终报告生成
编排者综合所有信息生成最终报告：
- 总结主要发现
- 按证据强度和一致性水平组织信息
- 提供研究限制和未来研究方向
- 附上所有来源的完整引用
工作流优势
- 全面性：多渠道信息收集确保研究覆盖面广
- 专业化：各工作者专注于特定来源和搜索策略
- 适应性：能根据初步发现调整搜索策略
- 深度分析：综合多源信息进行对比分析
- 效率提升：并行搜索不同来源大幅节省时间
4.2.5 评估-优化
定义：一个 LLM 调用生成响应，而另一个在循环中提供评估和反馈。
评估-优化工作流
适用场景：
- 当我们有明确的评估标准，且迭代优化能提供可量化价值的情境
- 适合场景的两个标志：
- 人类反馈能明显改进 LLM 响应质量
- LLM 本身能提供类似人类的有效反馈
应用示例：
- 文学翻译：初译(生成) → 评估细微差别 → 根据反馈优化 → 循环至达标
- 复杂信息搜索：初步搜索(生成) → 评估完整性 → 指出信息缺口 → 补充搜索 → 循环至完整（例如，DeepRearch）
应用案例：文学翻译优化系统
背景与设置
- 目标：将《了不起的盖茨比》翻译成保留原著文学风格和情感的中文版
角色分工：
- 优化者 LLM：负责生成翻译
- 评估者 LLM：评估质量并提供改进建议
- 评估维度：准确性、风格一致性、文化适应性
- 最大迭代：3 次（防止循环）
流程示例
原文：
"In my younger and more vulnerable years my father gave me some advice that I've been turning over in my mind ever since. 'Whenever you feel like criticizing anyone,' he told me, 'just remember that all the people in this world haven't had the advantages that you've had.'"
迭代 1
初次翻译：
"在我年轻、更加脆弱的岁月里，父亲给了我一些建议，我自那以后一直在脑海中回味。'每当你想批评任何人的时候，'他对我说，'请记住，这个世界上的所有人都没有得到过你所拥有的那些优势。'"
评估（7/10）：
- ✓ 整体准确，主要含义传达
- ✗ "turning over in my mind"→"回味"不准确
- ✗ "advantages"→"优势"过于直白
- ✗ 语气平淡，缺少情感色彩
- ✗ 需要更流畅的过渡词
迭代 2
修改版：
"在我年少轻狂、尚且脆弱的岁月里，父亲给了我一条忠告，此后我一直在心中反复思量。'每当你想要批评任何人的时候，'他对我说道，'请记住，这世上并非所有人都拥有过你所享有的那些机遇和条件。'"
评估（9/10）：
- ✓ 关键词翻译更准确
- ✓ 文学色彩增强
- ✓ 过渡更自然
- ✗ "年少轻狂"略带贬义
- ✗ 最后一句可更精炼
迭代 3（最终版）：
最终翻译：
"在我年少青涩、心思易伤的岁月里，父亲给了我一条忠告，此后我便一直在心中反复思量。'每当你想要批评任何人，'他告诫我道，'请记住，这世上并非所有人都有幸获得你所享有的那些机遇。'"
最终评估（10/10）：
- ✓ 完美捕捉原文情感和风格
- ✓ 用词准确且富有文学性
- ✓ 结构精炼，符合中文阅读习惯
- ✓ 平衡了忠于原文与文化适应性
工作流优势
- 质量提升：通过专门评估角色和多轮迭代提高输出质量
- 自我改进：系统识别不足并主动优化
- 透明度：评估标准和反馈可被清晰记录
- 减少人工干预：在保持高质量的同时减少人类参与
- 适应性：可根据特定领域定制评估标准
实施建议
- 明确定义评估标准和质量指南
- 设置合理迭代次数上限
- 保持优化者和评估者角色分离
- 跟踪记录每次迭代的变化
- 在关键应用中保留人类最终审核
这种工作流特别适合需要高质量、精心斟酌输出的场景，模拟了人类专业人士的迭代改进过程。
6.3 完整 Agent 模式
4.3.1 Agent 设计要点
随着大模型核心能力的成熟（理解复杂输入、推理规划、工具使用、错误恢复），智能体正在生产环境中崭露头角。智能体的典型工作流程为：
- 启动阶段：接收用户命令或通过交互确定任务
- 规划执行：任务明确后独立规划操作，必要时向人类请求更多信息
- 环境感知：每步骤从环境获取"基础事实"（工具调用结果或代码执行）评估进展
- 反馈循环：在检查点或遇障碍时可暂停等待人类反馈
- 任务终止：通常在完成时终止，包含停止条件（如最大迭代次数）以保持控制
Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully.
智能体可以处理复杂任务，但其实现通常很直接 - 本质上是在循环中基于环境反馈使用工具的 LLMs。
因此，清晰且合理的工具集及其说明文档至关重要。
我们在附录 2 中详述了工具开发的最佳实践。
工具集及其文档质量直接决定智能体的成功率和速度，体现在：
- Agent 选择合适工具及调用顺序的能力
- Agent 正确填写工具参数的能力
- Agent 有效利用工具结果的能力
自主 Agent
何时使用 Agent：
Agent 适用于开放性问题，这些问题特点是：
- 难以或不可能预测所需步骤数量
- 无法硬编码固定解决路径
在这类场景中，LLM 可能需要多轮操作，您必须对其决策过程有一定信任度。
需要注意的是，Agent 的自主性意味着：
- 可能产生更高成本
- 存在错误累积的潜在风险
建议在实际部署前在沙盒环境中进行广泛测试，并设置适当的保护措施。
Agent 应用举例：
以下是来自 Anthropic 实际实现的示例：
- 编程 Agent：解决 SWE-bench[3]任务，根据任务描述对多个文件进行编辑
- 计算机使用 Agent： computer use[4]，Claude 使用计算机完成复杂任务
编码 Agent 的流程
4.4 模式组合与定制
正如文章开头所强调，"最成功的实现采用简单、可组合的模式，而非复杂的框架"。这些设计模式是灵活的构建模块，可以根据具体应用需求进行组合和定制。
4.4.1 关键原则
- 这些模式是可自由组合的构建块，非固定框架
- 通过量化性能评估和迭代确定最佳组合
- 重要提示：仅在能显著提升效果时才增加复杂性
4.4.2 五种高效组合模式
- 提示链 + 路由：
- 机制：路由分类任务，然后应用专用提示链
- 示例：客服系统先分类问题(账单/技术/退款)，再应用对应专业处理链。
- 路由 + 并行化：
- 机制：先分类任务，对特定类别应用并行处理
- 示例：内容审核系统分类内容后，对复杂案例启用多评估者并行投票。
- 编排者-工作者 + 评估者-优化者：
- 机制：编排者分解分配任务，工作者执行，评估者提供反馈优化
- 示例：代码系统中编排者确定修改文件，工作者生成代码，评估者检查提供改进建议
- 提示链 + 评估者-优化者：
- 机制：在提示链关键节点使用评估-优化循环提升质量
- 示例：内容创作流程生成大纲 → 细化大纲 → 基于大纲创作 → 评估优化
- 混合 Agent 系统：
- 机制：整合多种模式，不同任务阶段使用最适合的模式
- 示例：全功能客服 Agent 先路由分类查询，简单问题用提示链，复杂问题用编排者-工作者，全程通过评估者-优化者保证质量
4.4.3 实施建议
- 从简单开始，基于性能数据增加复杂性
- 关注每个组合的接口设计，确保信息顺畅传递
- 设置明确的评估指标，量化每种组合的效果提升
- 注意模式组合可能增加成本和延迟，权衡利弊
- 建立有效的监控和失败恢复机制
4.4.4 组合设计的优势
- 灵活应对不同复杂度的任务需求
- 结合各个模式的优势创造协同效应
- 随着需求变化可渐进式扩展系统能力
- 各组件可独立优化，提高整体系统可维护性
5. 实践指南
5.1 核心建议
「在 LLM 领域，最成功的实现不是构建最复杂的系统，而是为特定需求构建最合适的系统。」首先从简单的提示词开始，通过全面评估进行优化，仅在简单解决方案不足时才添加更多步骤的类 Agent 系统。
5.2 Agents 开发原则
在实现 Agent 时，我们尽量遵循三个核心原则：
- 保持简单性：只在能够明显改善结果时增加复杂性
- 透明性：明确展示 Agent 的规划步骤来保证透明度
- 精心设计工具接口：通过详细的工具文档和充分的测试创建良好的 Agent-计算机接口（ACI）
虽然开发框架可帮助快速入门，但转向生产环境时，应减少抽象层级，直接使用基本组件构建。遵循上述原则，你可以创建强大、可靠、可维护且受用户信赖的智能体系统。
6. 附录 1: Agent 实战
6.1 智能体的实践价值与应用条件
基于客户合作经验，AI 智能体在同时满足以下条件的任务中能创造最大价值：
- 需要对话与行动相结合
- 具有明确的成功衡量标准
- 能够形成有效反馈循环
- 整合有意义的人类监督机制
6.2 成功案例分析
案例一：智能客服
优势契合点
- 自然对话流程：客服交互天然符合会话模式，同时需要信息检索和行动执行
- 工具集成能力：可接入客户数据、订单历史和知识库资源
- 行动自动化：退款处理、工单更新等可程序化执行
- 清晰成功指标：通过用户问题解决率直接衡量成效
商业验证
多家企业采用基于成功解决的定价模型（仅对成功解决的案例收费），证明了 Agent 在客户支持领域的实际价值和可靠性。
案例二：编程 Agent
应用优势
- 解决方案可验证：代码输出可通过自动化测试客观验证
- 反馈驱动优化：测试结果提供明确反馈，支持 Agent 迭代改进
- 问题域结构化：软件开发问题通常有明确边界和结构
- 输出质量可量化：代码性能和质量可通过既定指标评估
实际成果
在实际实现中，AI 智能体能够仅基于拉取请求描述解决 SWE-bench Verified[5]基准测试中的真实 GitHub 问题，展示了在结构化问题解决中的实际能力。
人类监督价值
尽管自动化测试能验证功能正确性，人类审查仍在确保解决方案符合更广泛系统要求方面发挥关键作用。
6.3 实施要点
- 明确定义任务范围：设置清晰的 Agent 职责边界和权限
- 精心设计工具集：提供 Agent 所需的全部工具并优化其文档
- 建立反馈机制：确保 Agent 能接收并利用执行结果改进行动
- 设置监督检查点：在关键决策节点引入人类监督
- 量化成功指标：建立客观评估 Agent 表现的指标体系
7. 附录 2：工具提示工程
7.1 定义
工具提示工程指的是：像编写提示词一样设计工具定义，使大模型能清晰理解工具的用途、使用方法和结果含义。
7.2 基本原则
清晰表达
- 使用精确的术语描述工具功能
- 明确说明输入参数的要求和格式
- 详细解释输出结果的结构和意义
- 包含使用限制和边界条件
推荐参考我的另一篇文章从模糊到具体：高效使用 DeepSeek-R1 等推理型模型的前置步骤，使用问题定义优化器提示词，辅助完成清晰表达。
压缩表达
- 避免冗余信息，保持描述简洁
- 使用结构化格式提高可读性
- 关注必要信息，减少不相关细节
- 确保核心用途和用法一目了然
7.3 工具系统设计详解
工具在 Agent 系统中的核心地位
在任何 Agent 系统中，工具都是关键组成部分，它们使 Claude 能够通过 API 中定义的确切结构与外部服务交互。当 Claude 决定调用工具时，会在 API 响应中包含工具使用代码块。工具定义的提示工程与主提示同等重要。
「工具形式」设计指南
对于同一个目的，有不同的实现方式，考虑选择何种方式的决定因素是：
- LLM 实现的准确性、难易度
- LLM 是否擅长这种方式，格式是否为 LLM 友好的
多种实现方式对比
同一操作通常有多种实现方式，例如：
虽然这些差异在技术上可以无损转换，但对LLM而言难度差异显著：
- 编写diff需要预先计算变更行数
- JSON中的代码需要处理“引号”和“换行符转义”
格式选择三原则
- 思考空间充足：为模型在输出前思考提供足够 token（即，压缩工具的 token 消耗）
- 贴近自然语料：选择接近互联网文本中常见的格式（Markdown、Txt）
- 最小化格式负担：避免需要精确计数或复杂转义的格式（例如，需要准确统计数千行代码的数量、json 中的换行符转义字符）
7.4 Agent-计算机接口优化
正如人机接口(HCI)设计重要，Agent 计算机接口（ACI）需同样重视：
设计策略
- 模型视角思考：从模型角度评估工具使用的直观性。对于人来说，根据工具描述和参数，使用这个工具是否很容易、清晰，还是需要仔细思考？如果是这样，那么模型可能也是如此。
- 完整文档设计：好的工具定义通常包括使用示例、边界情况、输入格式要求以及与其他工具的清晰界限
- 命名优化：像为初级开发者写文档一样精心设计参数名称
- 实证测试迭代：通过多样化输入观察模型使用模式
- 防错设计实施：重构参数结构减少错误可能性
实战案例
在 SWE-bench[6]Agent 开发中，工具优化占用了大量精力：
- 问题：当智能体离开根目录后，相对路径引用导致错误
- 解决方案：强制要求使用绝对路径
- 效果：模型能够完美执行文件操作
在为 SWE-bench 构建我们的 Agent 时，Anthropic 实际上花了更多的时间优化我们的工具，而不是整体提示词。
7.5 实践建议
设计原则将工具文档视为 API 设计的关键环节精简必要参数，提供合理默认值为复杂工具添加使用示例使用场景界定
- 定义与其他工具的区分方法：清晰界定工具的适用场景和不适用场景
- 使用模型能理解的语言和格式
持续优化策略
- 定期检查工具使用日志，识别改进机会
- 平衡灵活性和防错性，适应智能体能力水平
优良的工具定义能显著提升 Agent 的工具利用效率，减少错误调用，并提高整体系统性能。
技术的力量在于分享，希望这篇总结能成为他人开发之路上的指南针。如果您希望持续获取工作流、Agent 技术及大模型应用的最新动态和深度解析，欢迎关注我的公众号硅基世界指北。智能体的未来已来，这不仅是去发现，更是去创造。期待与更多志同道合的朋友们共同探索 AI 的无限可能。
参考资料
[1] cookbook
[2] 模型上下文协议
[3] SWE-bench
[4] computer use
[5] Building effective agents
END
作者：fred
文章来源：腾讯技术工程
推荐阅读
更多腾讯 AI 相关技术干货，请关注专栏腾讯技术工程 欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
