Building Effective Agents（构建有效的 Agent）

成功的 LLM Agent 实现靠的不是复杂框架或专门库，而是简单、可组合的模式。应该从简单提示词开始，用完善的评估优化，只有在简单方案不够用时才引入多步 Agent 系统。

工作流 vs Agent 的根本区分

• 工作流（Workflows）： 用预先确定的代码路径编排 LLM 和工具，可预测、一致，适合定义明确的任务
• Agent： LLM 动态主导自己的流程和工具使用，根据环境反馈自主决定路径

五种工作流模式

1. 提示词链（Prompt Chaining）

任务分解为顺序步骤，每次 LLM 调用处理上一步的输出；中间可插入程序化「闸门」检查。 - 适用：可干净拆分的固定子任务，用延迟换准确率 - 例子：先写营销文案再翻译；先写大纲再写正文

2. 路由（Routing）

分类器 LLM 把输入分发给专门的下游处理器。 - 适用：有明确类别、需要不同处理方式的任务 - 例子：客服请求分类（退款/技术支持/一般咨询）；简单问题给 Haiku、复杂问题给 Sonnet

3. 并行化（Parallelization）

多个 LLM 同时工作，程序化聚合输出。两个变体： - 分片（Sectioning）： 独立子任务并行执行（如一个模型处理请求、另一个做内容审查护栏） - 投票（Voting）： 同一任务跑多次取共识（如多个代码审查者标记漏洞）

4. 编排器-工作者（Orchestrator-Workers）

中心 LLM 动态分解任务、委派给工作者、综合结果。与并行化的区别在于子任务不可预先确定。 - 例子：跨多文件的复杂代码修改；多来源信息搜集

5. 评估器-优化器（Evaluator-Optimizer）

一个 LLM 生成、另一个评估反馈，迭代循环，类似人类编辑流程。 - 适用：有清晰评估标准、迭代能实证改善结果的任务 - 例子：文学翻译；多轮搜索分析的复杂研究

自主 Agent

• 循环运作：根据环境反馈（执行结果、API 响应）使用工具
• 自主规划行动序列；遇到阻塞或到达预设停止点时暂停等人类反馈
• 适用时机： 步骤不可预测、硬编码路径行不通的开放式问题，且你信任模型的自主决策
• 警告： 成本更高、错误会复利放大；需要沙箱大量测试和恰当护栏
• 例子：解决 GitHub issue（SWE-bench）；操作电脑完成桌面任务

三大实现原则

1. 简单： 避免不必要的复杂度
2. 透明： 显式展示 Agent 的规划步骤
3. 文档： 精心打磨 Agent-计算机接口（ACI），像做 HCI 一样投入

工具设计最佳实践（附录精华）

• 选择贴近自然文本的格式，避免要求精确行数或大量转义的「开销」
• docstring 写全：用法示例、边界情况、清晰边界
• 「防呆」（Poka-yoke）设计：让错误用法不可能发生（如强制绝对路径）
• SWE-bench 团队「花在优化工具上的时间比优化整体提示词还多」

应用场景洞察

• 客服： 对话界面 + 工具集成（订单历史、退款、知识库），可用解决率量化
• 编码： 输出可通过自动化测试验证，可迭代改进；但人类审查仍必要

框架建议

框架（Claude Agent SDK 等）能简化实现，但建议先用原始 LLM API 做原型，理解底层抽象后再采用框架，始终保持简单。

结语

成功来自「为需求构建正确的系统」而非最大化复杂度：从优化的单次 LLM 调用开始，只有当性能数据证明必要时才增加多步系统。