AI Agent 工作流模式与高级工具调用
工作流模式
三种核心模式
生产环境中，三种模式覆盖了绝大多数用例：
| 模式 | 解决的问题 | 何时使用 | 权衡 |
|---|---|---|---|
| 顺序执行 | 任务有依赖：B 步骤需要 A 步骤的输出 | 多阶段流程、数据管道、起草-审查-润色循环 | 增加延迟（每步等待上一步） |
| 并行执行 | 任务独立，逐个执行太慢 | 多维度评估、代码审查、文档分析 | 成本更高（多个并发 API 调用） |
| 评估优化 | 初稿质量不够好 | 技术文档、客户沟通、按特定标准生成代码 | 迭代带来 token 消耗和延迟 |
起点原则：从解决问題的最简模式开始。默认选顺序执行。仅当延迟成为瓶颈且任务独立时，才迁移到并行模式。仅当你能够量化质量改进时，才添加评估-优化循环。
顺序工作流
顺序工作流按预定义顺序执行任务。每个阶段的智能体处理输入、做出决策、按需调用工具，然后将结果传递给下一阶段。
适用场景：
- 多阶段流程，每个步骤依赖前一步的输出
- 数据转换管道，每个阶段增加特定价值
- 无法并行化的任务（固有依赖关系）
- 起草-审查-润色循环
示例：
- 生成营销文案 → 翻译成多语言
- 从文档提取数据 → 验证 schema → 加载到数据库
- 内容审核管道：提取内容 → 分类 → 应用审核规则 → 路由
反模式：单智能体能有效处理整个任务时，不要强行拆分。
并行工作流
并行工作流将独立任务分配给多个智能体，同时执行。不等待一个智能体完成再启动下一个，而是同时运行多个智能体，然后合并结果。
适用场景：
- 分区处理（不同智能体处理不同方面）
- 评估场景（每个智能体评估不同质量维度）
- 投票模式（多个智能体分析相同内容，汇总评估）
权衡：
- 需要聚合策略（如何处理矛盾结果？）
- 成本更高（多个并发 API 调用）
- 不适合需要累积上下文的任务
评估-优化工作流
评估-优化工作流通过迭代反馈循环不断提高输出质量。
适用场景：
- 技术文档生成（需要多轮打磨）
- 客户沟通（需要精确措辞）
- 按特定标准生成代码
权衡：
- token 消耗成倍增加
- 迭代带来延迟
高级工具调用
Tool Search Tool
问题：MCP 工具定义会消耗大量 token。一个五服务器配置可能消耗 55K+ token：
- GitHub: 35 工具 (~26K tokens)
- Slack: 11 工具 (~21K tokens)
- Sentry/Grafana/Splunk: ~8K tokens
解决方案：按需发现工具，而非预先全部加载。
传统方式：所有工具定义预先加载 (~72K tokens for 50+ MCP 工具)
Tool Search Tool：仅加载搜索工具 (~500 tokens)，按需发现 3-5 个相关工具 (~3K tokens)效果：85% token 减少，MCP 评估准确率显著提升。
实现：
json
{
"tools": [
{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
{
"name": "github.createPullRequest",
"input_schema": {...},
"defer_loading": true // 标记为按需发现
}
]
}Programmatic Tool Calling
问题：自然语言工具调用每次调用需要完整推理，中间结果堆积在上下文中。
解决方案：在代码执行环境中以编程方式调用工具，减少对模型上下文的影响。
示例：Claude for Excel 使用 Programmatic Tool Calling 读写数千行电子表格，而不压垮模型上下文。
Tool Use Examples
问题：JSON Schema 定义结构有效性，但无法表达使用模式：何时包含可选参数、哪些组合有意义、API 期望什么约定。
解决方案：提供工具使用示例的标准格式，让智能体从示例中学习正确用法，而非仅从 Schema 定义。
模式选择决策树
任务可以由单智能体处理吗？
├── 是 → 先尝试单智能体，只有在单智能体无法可靠处理时才拆分
└── 否 → 任务有依赖？
├── 是 → 顺序工作流
└── 否 → 需要同时处理多个独立方面？
├── 是 → 并行工作流
└── 否 → 输出质量不够好？
├── 是 → 评估-优化工作流
└── 否 → 考虑顺序或单智能体