AI Agent 深度探寻[2]:顶尖团队的 7 条工程共识

00 · 引言：从问题到答案

在上一篇「为什么你的 Agent 总是翻车？」中，我们系统性地拆解了 Agent 从概念走向生产必须跨越的五道工程障碍：确定性与概率性的根本冲突、多步推理的延迟代价、不可预测系统的评估噩梦、工具质量对系统上限的决定性影响，以及全自动幻想破灭后的人机协同必要性。

那篇文章的任务是”提出问题”。但提出问题只是第一步。真正的问题是：面对这些挑战，业界顶尖的研究团队和一线工程实践者是如何回应的？他们的方法论中，是否存在某种跨视角的共识？

当我们把 Anthropic 的《Building Effective Agents》指南、吴恩达的四种 Agentic Design Patterns、Lilian Weng 对 Agent 架构的系统性分析、Simon Willison 对 LLM 系统可靠性的持续追问，以及 Chip Huyen 对工程陷阱的批判性审视放在一起比对时，一个值得注意的现象出现了：尽管他们的出发点、表达方式和关注维度各不相同，但在核心的工程原则上，他们指向了高度一致的方向。就像从五个不同的角度观察同一座山脉，每张地图的画法不同，但山脊的走向是一致的。

本文的任务就是绘制这张”共识地图”——从这些跨视角的分析中提取出 7 条工程共识。每一条都不是某一个人的观点，而是多个独立声音的交汇点。我们相信，这些交汇点构成了当前 Agent 工程领域最可靠的知识基底。

01 · 共识一：从工作流开始，而非 Agent

构建 Agent 系统时，最普遍的一个认知偏差是：团队在面对一个新问题时，第一反应是”我们需要一个 Agent”。于是大量时间被投入到架构讨论、多 Agent 协作拓扑设计、记忆系统选型上——却很少有人先问一个更基本的问题：这个任务的每一步，到底需要什么？

Agent 工程的第一条共识，恰恰是对这种直觉的纠正：从工作流开始，而不是从 Agent 开始。

具体而言，这意味着在引入任何自主性之前，先把完整的工作流画出来。将任务分解为最小粒度的步骤，然后对每一步进行分类——哪些步骤的输入输出关系是确定的，可以用传统代码解决；哪些步骤需要语义理解，可以直接调用 LLM；哪些步骤需要 LLM 配合外部工具，构成 Augmented LLM 模式；最后，哪些步骤确实需要多步自主推理和动态决策，才值得引入 Agent 的自主循环。

这一步看似简单，却触及了 Agent 工程中最容易被忽视的经济学：如果一个任务可以用十行确定性代码解决，引入概率模型只会带来不必要的失败模式、调试难度和运维成本。工程的首要原则是”用最简单的方案解决当前的问题”，而 Agent 的自主性，恰恰是最昂贵的方案之一。

完成这张工作流地图后，一个经常出现的结论是：真正需要 Agent 自主性的步骤，可能只占整个工作流的 20%。其余 80% 都可以用更简单、更可靠的方式解决。Agent 应该是工作流中的一个组件，而不是整个系统的默认架构。

02 · 共识二：复杂度递增的阶梯模式

接受了”从工作流开始”的原则之后，接下来的问题自然浮现：在那些确实需要 Agent 自主性的场景中，应该选择什么复杂度的模式？

这里存在第二条共识：Agent 模式的升级应该像爬楼梯，而不是坐电梯。复杂度的每一次增加，都会带来调试难度、延迟成本和失败模式的指数级增长。一个 Multi-agent 系统的调试难度不是 Augmented LLM 的几倍，而是呈组合爆炸式增长——因为你需要理解的不再是单个 Agent 的行为，而是多个 Agent 之间的交互协议、状态同步和错误传播路径。

基于这一工程现实，业界逐渐形成了一个清晰的复杂度阶梯：

每一级模式都只应在上一级无法满足需求时才被引入。不要从 Augmented LLM 直接跳到 Multi-agent。每一级的升级都应该有明确的理由：上一级在哪些场景下失败了？下一级如何解决这些失败？

吴恩达提出的四种 Agentic Design Patterns——Reflection（反思）、Tool Use（工具使用）、Planning（规划）和 Multi-Agent（多 Agent 协作）——恰好与这一阶梯形成了互补。这四种模式本身就构成了一条能力递增的路径：从模型自我审查和改进输出开始，叠加外部工具调用能力，再引入子目标分解和逐步执行，最后才进入多 Agent 协作的领域。大多数团队在大多数场景下，用 Augmented LLM 加上反思循环，就能获得 80% 的价值。只有当你反复验证了这一层模式的局限性之后，才值得向更复杂的模式迁移。

03 · 共识三：Agent 的三大支柱

选择了合适的模式之后，接下来的问题是：Agent 的内部架构应该如何设计？

一个被广泛接受的框架将 LLM 驱动的自主 Agent 拆解为三个核心支柱：Planning（规划）、Memory（记忆）和 Tool Use（工具使用）。这个框架的价值在于，它把 Agent 从一个模糊的”智能体”概念，变成了三个可以分别设计和优化的工程组件。

在实际的 Agent 设计中，团队往往会过度关注 Planning 而忽视 Memory 和 Tool Use。这是可以理解的——Planning 是最引人注目的部分，它直接关系到 Agent 看起来有多”智能”。但一个只关注 Planning 的 Agent 系统是跛脚的。

Memory 支柱补上了 Agent 从”一次性聊天机器人”进化为”持续性工作伙伴”的关键缺口。短期记忆和长期记忆需要协同设计：短期记忆通过上下文窗口维持当前任务的连贯性，长期记忆则通过 RAG 等机制实现跨会话、跨任务的信息持久化。但 RAG 不仅仅是”给 LLM 加一个向量数据库”——它需要精心设计的检索策略、信息过滤机制和上下文注入方式。一个糟糕的 RAG 实现引入的噪声，反而会降低 Agent 的推理质量。

Tool Use 则决定了 Agent 的边界。无论规划多么精妙、记忆多么丰富，如果 Agent 无法正确地调用工具来执行操作，它的”智能”就永远停留在纸面上。工具定义的质量、参数约束的严格程度、错误处理的完备性，共同构成了 Agent 与世界交互的接口层。

04 · 共识四：工具定义优先于 Prompt 优化

顺着三大支柱的分析，Tool Use 的重要性已经不言自明。但这里需要进一步深化一个反直觉的判断：在 Agent 项目中，大约 80% 的工程时间应该投入到工具定义的质量提升上，而不是 Prompt 调优。

这个比例可能会让很多团队感到不适。在直觉上，Prompt 才是 Agent 的”灵魂”——它是你与模型对话的方式，是告诉模型”你是谁、你要做什么”的核心载体。工具定义相比之下似乎只是”技术细节”。

但直觉在这里会误导你。工具定义是 Agent 与外部世界交互的接口。无论 Prompt 写得多么精妙，如果工具定义模糊、参数类型错误、说明文字与系统指令不一致，模型就无法正确地使用这些工具。就像一个口才再好的销售人员，如果产品说明书是错的，他也卖不出正确的东西。

更深一层看，工具定义本质上是一种 API 契约——只不过这份契约的”消费者”不是人类程序员，而是一个需要从自然语言描述中推断语义的概率模型。这意味着工具定义需要同时满足两重标准：对机器而言，需要严格的类型约束和参数验证，使用 Pydantic 或 Zod 这样的 schema 验证工具确保运行时检查；对模型而言，需要清晰的自然语言描述，与系统指令中的术语保持一致。如果系统指令中说”搜索知识库”，但工具的 description 写的是”query database”，模型可能无法正确关联这两个概念。

因此，工具定义应该被视为一等公民来对待：每次变更都纳入版本管理，可以回滚、可以 diff、可以 code review；为每个工具编写测试用例，验证模型在不同 Prompt 下能否正确调用——这不是测试工具的代码逻辑，而是测试工具定义对模型的”可理解性”；维护一份工具目录，记录每个工具的用途、参数说明、使用场景和已知限制，这份文档既是开发者的参考，也是 LLM 描述素材的来源。

05 · 共识五：评估是基础设施，不是事后补救

有了合理的架构和精心定义的工具，下一个关键问题是：你怎么知道你的 Agent 工作得好不好？

这里的共识是：评估不应该是在 Agent 开发完成之后才考虑的事情，而应该从项目的第一天就被当作基础设施来建设。

评估必须是场景特定的，而不能依赖通用的基准测试。MMLU、GSM8K 这样的基准测量的是模型的通用知识能力，但它们与具体的业务场景几乎没有关系。一个在 MMLU 上得 90 分的模型，在你的客服场景中可能表现得还不如一个 70 分的模型。每个 Agent 项目都需要构建自己的评估体系——这不是一个可以复用的工具链，而是需要根据具体场景定制的基础设施。

与此同时，LLM 的固有不可靠性意味着评估不仅仅是”这个 Agent 好不好”的问题，更是”这个 Agent 在什么时候会失败，失败时有多糟糕”的问题。因此，评估体系需要覆盖多个维度：

• LLM-as-a-Judge：用更强大的 LLM 来评估 Agent 的输出，处理开放域、非结构化的输出，通过交叉验证和人工校准提高可信度。

• 轨迹评估（Trajectory Evaluation）：不仅评估最终输出，还评估 Agent 的整个执行轨迹——工具调用的顺序是否正确？参数是否合理？错误处理是否得当？这更接近代码审查的思路。

• 黄金数据集（Golden Datasets）：构建覆盖各种场景的测试用例，每个用例都有人工标注的期望输出和期望执行路径，作为回归测试的基础。

与评估紧密相关的是可观测性（Observability）。在传统软件工程中，可观测性意味着你能看到系统内部发生了什么——日志、指标、追踪。在 Agent 系统中，这意味着你能看到 Agent 的推理过程：它做了哪些决策？调用了哪些工具？每一步的输入输出是什么？置信度是多少？

没有可观测性的 Agent 系统就是一个黑箱。当它输出错误结果时，你无法知道问题出在哪里——是 Prompt 的问题、工具定义的问题、模型本身的局限，还是某个工具 API 返回了异常数据？你只能盲目地猜测和尝试。评估不只是”打分”，更是”理解”。一个好的评估体系不仅要告诉你 Agent 做得好不好，更要告诉你它为什么做得好或不好。

06 · 共识六：假设失败，设计容错

建立了评估体系之后，一个更深层次的问题浮现出来：当 Agent 不可避免地失败时，系统应该如何应对？

LLM 从根本上就是不可靠的——这不是一个可以通过更好的 Prompt 或更大的模型来彻底解决的问题，而是概率模型的固有属性。LLM 会在某些输入上产生幻觉，会误解模糊的指令，会在工具调用中生成格式错误的参数，会在长推理链中丢失上下文。这些不是 bug，而是 LLM 正常行为分布的一部分。

因此，Agent 工程需要一种思维方式的转变。在传统软件工程中，默认假设是”代码是正确的”——函数会按照规格说明执行，网络调用会返回预期的结果，数据库事务会正确提交。当这些假设被打破时，我们用异常处理机制来应对。但在 Agent 系统中，”异常”不是偶发事件，而是必然发生的常态。

于是产生了第六条共识：从一开始就假设失败会发生，然后围绕这个假设来设计系统。问题不是”它会不会失败”，而是”当它失败时，系统能多优雅地降级”。这体现在一系列工程实践中：

• 重试机制（Retry）：当工具调用失败或 LLM 输出格式错误时自动重试，但设置上限以避免无限循环。

• 回退路径（Fallback）：当 Agent 无法完成任务时，有明确的回退方案——转交人工处理，或返回一个明确的”无法完成”信号，而不是输出一个看似合理但完全错误的答案。

• 置信度阈值（Confidence Threshold）：Agent 为每个决策输出置信度评分，低于阈值的决策自动转交人工审查或触发回退路径。

• 人工审核关卡（Human Review Gates）：在关键操作——数据写入、资金转账、对外发送信息——之前设置人工审核点，作为最后一道防线。

• 渐进式降级（Graceful Degradation）：当系统的某个组件不可用时，系统能够降级运行而非完全崩溃。比如搜索工具不可用时，Agent 告知用户”暂时无法获取最新信息”，而不是编造一个答案。

这种”假设失败”的思维方式在传统软件工程中被称为防御性编程。在 Agent 工程中，它变得更加关键，因为 LLM 的不可靠性不是偶发的边界情况，而是持续存在的背景噪声。一个可靠的 Agent 系统不是”不会失败”的系统，而是”失败时不会造成灾难”的系统。

07 · 共识七：小模型 + 好设计 > 大模型

在当前的 AI 叙事中，存在一个根深蒂固的假设：更大的模型 = 更好的结果。这个假设在某些场景下成立——开放域知识问答、创意写作、复杂推理。但在 Agent 工程的上下文中，它往往不成立。

第七条共识直指这一迷思：一个经过精心设计的小模型方案，在性价比上可以碾压一个粗糙的大模型方案。

原因有两层。第一层是”边际收益递减”。从 7B 到 70B 模型，通用推理能力确实有显著提升。但从 70B 到 700B，提升的幅度开始收窄。对于很多具体的、领域特定的 Agent 任务，中等规模的模型已经”足够好了”——额外的参数带来的改进微乎其微，但成本和延迟却成倍增加。

第二层是”设计杠杆”。一个好的设计模式——反思循环、工具调用策略、错误处理机制——对系统整体表现的影响，远超过模型规模的线性提升。一个带有良好反思循环的小模型，其表现可以超过单次推理的大模型，因为反思循环本质上创造了一种迭代改进的机制：模型第一次输出可能不完美，但通过自我审查和修正，最终输出的质量可以显著提升。这种迭代改进的收益，往往比模型规模的线性增长更大。

从成本角度看，这个共识更加引人注目。一个较小模型的推理成本可能是大模型的十分之一甚至更低。对于需要大规模部署的 Agent 系统，这个差异是决定性的。小模型还具有更低的延迟、更灵活的部署选项、更低的基础设施要求——这些都是生产环境中的关键因素。

因此，模型大小不应该是你的第一个变量，而应该是你的最后一个变量。先用最小规模的可行模型，配合最简单的设计模式开始。评估性能后，如果不满足需求，先改进设计模式——加入反思、优化工具定义、改善记忆系统。只有当设计模式已经优化到极限，但模型容量仍然是瓶颈时，才考虑升级模型。升级后重新评估，如果提升不明显，回退到小模型，继续优化设计。

08 · 结语：一张工程共识地图

回顾这 7 条共识，它们之间存在一条清晰的逻辑主线：

这 7 条共识有一个贯穿始终的共同主题：工程纪律优先于原始 AI 能力。

从工作流分析到复杂度控制，从三大支柱的均衡设计到工具定义的严格管理，从评估体系的前置建设到容错机制的系统部署，再到对模型规模的理性选择——所有这些共识都在指向同一个方向：Agent 的成功不在于你用了多强的模型，而在于你是否有足够的工程纪律来驾驭它。

这正是”AI Agent 深度探寻”系列想要构建的完整知识体系：

No.1 · 问题——Agent 落地面临哪些工程挑战？

No.2 · 方法论——顶尖团队如何回应这些挑战？（本文）

No.3 · 工具——主流框架如何在代码层面实现这些共识？

No.4 · 实践——评估体系与可观测性基础设施的搭建。

在下一篇文章中，我们将深入 LangGraph、CrewAI 等主流框架，看它们如何在代码层面实现这些工程共识。我们将分析不同框架的设计哲学、架构差异和适用场景，帮助你在实际项目中做出明智的技术选型。

09 · 参考文献

计算沉思录

分享关于计算的观察与思考

追踪科技前沿 · 探索底层逻辑 · 畅想未来趋势