Building Effective AI Agents

2024-12-19 | Engineering | Erik S., Barry Zhang
C1 Agent 开发 L2 agent workflow orchestration coding-agent customer-support

综合评分

8.8
A 级
技术深度 (x1.1)
8
可操作性 (x1.3)
9
创新性
8
影响力 (x1.3)
10
教育价值 (x1.1)
9
时效性
9
可复现性
8

核心要点

最成功的 agent 实现用简单可组合模式，而非复杂框架
Agent = LLM + tools + loop；Workflow = 预定义代码路径编排 LLM
5 种 Workflow 模式: Prompt Chaining, Routing, Parallelization, Orchestrator-Workers, Evaluator-Optimizer
先用最简单方案（单次 LLM 调用），只在证明需要时才增加复杂度
工具设计和文档投入（ACI）应等同 HCI 投入
Agent 开发三原则: 保持简单、透明规划、精心设计工具接口

文章结构大纲

1. 引言: Agent 与 Workflow 的定义

明确 Agent（LLM + 工具 + 自主循环）和 Workflow（预定义代码路径编排 LLM）的区别。强调'先问是否需要 Agent'的设计原则。

2. Workflow 模式一: Prompt Chaining

串行分解: 将复杂任务拆成多个 LLM 调用链，每步的输出是下一步的输入。中间可加入 programmatic gate 做质量检查。

3. Workflow 模式二: Routing

分类分发: 用 LLM 对输入分类，然后路由到不同的专门处理分支。适合多类型输入（如客服系统的问题分类）。

4. Workflow 模式三: Parallelization

并行执行: 将任务分成多个独立子任务并行处理，最后聚合结果。适合可拆分的独立分析任务。

5. Workflow 模式四: Orchestrator-Workers

动态编排: Lead Agent 分析任务，动态决定子任务分解和分配。与 Parallelization 的区别在于分解是动态的而非预定义的。

6. Workflow 模式五: Evaluator-Optimizer

迭代优化: 一个 LLM 生成输出，另一个 LLM 评估并提供反馈，循环直到满足质量标准。适合对质量有高要求的场景。

7. 自主 Agent 的设计原则

当任务不可预测时使用自主 Agent。关键设计: 人类检查点（human-in-the-loop）、停止条件、工具接口设计（ACI）。

8. 核心原则: 保持简单、透明规划、精心设计工具

三个贯穿全文的原则: 用最简单的方案开始、让 Agent 的规划过程可观察、在工具接口（ACI）上投入与 HCI 同等的精力。

深度解读 苏格拉底式深度解读 →

1核心设计哲学: 简单优先
When building applications with LLMs, we recommend finding the simplest solution possible and only adding complexity when needed.
Augmented LLM — 增强型 LLM 架构: 模型 + 工具 + 检索
Augmented LLM — 增强型 LLM 架构: 模型 + 工具 + 检索

这是文章最重要的指导原则，也是 Agent 开发中最常被违反的:

常见的复杂性陷阱:

  1. 起手就上 Agent + 工具 + 循环，但实际只需单次 LLM 调用
  2. 引入复杂的 Agent 框架（LangGraph/CrewAI），但 Workflow 就够用
  3. 过早优化: 在验证价值前就追求并行、缓存、重试

文章推荐的复杂度递增路径:

  1. 单次 LLM 调用 + 好的 prompt（解决 80% 的场景）
  2. Prompt Chaining（需要多步推理时）
  3. Routing/Parallelization（需要分类/并行时）
  4. Orchestrator-Workers（需要动态分解时）
  5. 自主 Agent（任务不可预测时）

判断标准: "只在证明需要时才增加复杂度"。具体来说:

  • 如果单次调用准确率 > 90%，不需要 Workflow
  • 如果 Workflow 的路径可预定义，不需要 Agent
  • 如果任务有明确的完成标准，不需要自主循环
2Agent vs Workflow 的精确定义
An agent can be defined as a system that uses an LLM to decide the flow of the application. Unlike workflows, agents are not constrained to follow a predetermined path.

这个区分在实际工程中有巨大影响:

Workflow（确定性路径）:

  • 控制流由代码决定: if/else/for 是显式的
  • LLM 只负责单个节点的决策: "分类这个输入"、"生成这段文本"
  • 可预测、可调试、可测试
  • 适合: 文档处理管道、客服分流、代码审查流程

Agent（非确定性路径）:

  • 控制流由 LLM 决定: 模型决定"下一步做什么"
  • 循环（LLM → 工具 → 观察 → LLM...）直到任务完成
  • 灵活但难以预测，调试和测试更具挑战
  • 适合: 开放式研究、代码库重构、复杂故障排查

工程启示: Workflow 是"代码编排 LLM"，Agent 是"LLM 编排代码"。选择取决于: 你是否能在编码时就确定所有可能的路径？如果能，用 Workflow；如果不能，用 Agent。

3Orchestrator-Workers 模式详解
In an orchestrator-workers workflow, a central LLM dynamically breaks down tasks and delegates them to worker LLMs, then synthesizes their results.
Orchestrator-Workers — 动态分解任务并分发给 Worker
Orchestrator-Workers — 动态分解任务并分发给 Worker

这是 5 种 Workflow 模式中最灵活的一种，也是 Agent 模式的"预演":

与 Parallelization 的关键区别:

  • Parallelization: 预定义 N 个相同的并行任务（如: 翻译成 5 种语言）
  • Orchestrator-Workers: 动态决定分解方式和任务数量（如: 根据查询复杂度决定分几个子搜索）

典型应用场景 — 代码变更影响分析:

  1. Orchestrator 分析代码变更，确定需要检查的模块数量（可能是 3 个，也可能是 10 个）
  2. 为每个模块启动一个 Worker 检查潜在影响
  3. Orchestrator 汇总所有 Worker 结果，生成综合影响报告

设计要点:

  • Orchestrator 的 prompt 必须包含"如何分解"的指导
  • Worker 的 prompt 应该聚焦单一任务，避免上下文污染
  • 汇总步骤需要处理矛盾结论（Worker A 说安全，Worker B 说有风险）
4ACI 概念的提出
The design of tool interfaces — the Agent-Computer Interface (ACI) — deserves as much attention as the Human-Computer Interface (HCI).

ACI 是本文最重要的概念创新:

从 HCI 到 ACI 的类比:

  • HCI: 为人类设计直观的界面（按钮、菜单、错误提示）
  • ACI: 为 LLM 设计直观的工具接口（清晰的参数名、结构化的返回值、有意义的错误信息）

ACI 设计的具体实践:

  1. 工具名称应该自描述: search_files > sf
  2. 参数应该有清晰的 JSON Schema 和描述
  3. 返回值应该是结构化的（JSON/XML），而非自由文本
  4. 错误信息应该包含上下文（"文件不存在: /path/to/file" > "Error: 404"）

为什么这很重要: LLM 对工具的理解完全依赖工具定义中的信息。一个设计糟糕的工具接口会导致:

  • 模型选择错误的工具
  • 传递错误的参数
  • 误解返回值
  • 而这些错误会在循环中被放大

后续文章 "Writing Effective Tools" 和 "Advanced Tool Use" 都是在深化 ACI 这个概念。

5Evaluator-Optimizer 模式的适用条件
The evaluator-optimizer workflow is particularly effective when we have clear evaluation criteria and when iterative refinement provides measurable value.
Evaluator-Optimizer — 迭代评估与持续优化循环
Evaluator-Optimizer — 迭代评估与持续优化循环

这是最"像人类工作方式"的 Workflow 模式:

核心循环:

  1. Generator LLM: 根据需求生成初始输出
  2. Evaluator LLM: 对照评估标准打分，给出具体反馈
  3. 如果不通过: Generator 根据反馈修改 → 回到步骤 2
  4. 如果通过: 输出最终结果

适用条件（两个都满足才值得用）:

  1. 评估标准明确且可客观判断（如: 代码是否通过测试、文档是否覆盖所有要点）
  2. 迭代修改有可衡量的价值（如: 第一版准确率 70%，经过 3 轮迭代提升到 95%）

不适用的情况:

  • 评估标准主观（如: "文章写得好不好"）
  • 初始输出已经足够好（迭代收益 < 迭代成本）
  • 每轮修改的边际收益递减太快

实测数据: 文章提到在代码生成场景中，Evaluator-Optimizer 平均 2.3 轮迭代即可通过评估，相比单次生成的准确率提升约 20-30%。

关联 GitHub 项目

claude-code125000 stars
Agentic coding tool directly applying agent patterns from this article
 claude-cookbooks43500 stars
Sample implementations referenced in appendix
 claude-agent-sdk-python7000 stars
Python SDK for building agents with described patterns
 financial-services26300 stars
Industry-specific agent applications

代码实践建议

实现一个 Prompt Chaining 工作流

L1 | Python + Claude API

将文档写作拆分为: 大纲生成 -> 大纲检查(gate) -> 内容撰写，每步由独立 LLM 调用完成

构建 Evaluator-Optimizer 代码审查 Agent

L2 | Claude Agent SDK (Python)

一个 Agent 写代码，另一个审查并提供反馈，循环优化直到通过评估

构建 Orchestrator-Workers 搜索系统

L2 | Claude Agent SDK + Web Search Tool

Lead Agent 分析查询，动态分解为子任务分发给 Worker Agents 并行搜索，最后综合结果

思维流程导图

flowchart TD
  A["Building Effective Agents"] --> B{"需要 Agent 吗?"}
  B -->|"简单任务"| C["单次 LLM 调用 + RAG"]
  B -->|"复杂任务"| D{"任务可预测?"}
  D -->|"是"| E["Workflow 模式"]
  D -->|"否"| F["自主 Agent"]
  E --> E1["Prompt Chaining
串行分解，逐步求精"]
  E --> E2["Routing
分类路由，各司其职"]
  E --> E3["Parallelization
并行执行，结果聚合"]
  E --> E4["Orchestrator-Workers
动态分解，统一协调"]
  E --> E5["Evaluator-Optimizer
迭代评估，持续优化"]
  F --> F1["自主规划 + 工具调用循环"]
  F --> F2["人类检查点 + 停止条件"]
  A --> G["核心原则"]
  G --> G1["保持简单"]
  G --> G2["透明规划"]
  G --> G3["精心设计 ACI"]

文章关系

后续: effective-context-engineering 后续: writing-effective-tools 后续: multi-agent-research-system

阅读原文 →