Agentic 工程模式：While 循环只是最简单的部分

问问任何一个交付过真实智能体（agentic）系统的团队，最难的部分是什么。几乎没有人会说是 “LLM 调用”。无论是 Claude Code、Cursor，还是自研的财务自动化工具，每个生产环境中的智能体运行的核心循环几乎都是一模一样的。有趣的工程挑战 —— 即区分一个好用的智能体与一个失控的成本中心的部分 —— 完全存在于那个循环之外。

一个团队最初运行智能体循环的费用是每周 127 美元。四周后，账单达到了 47,000 美元。一个没有 token 上限的失控循环将每一次迭代复合成了财务灾难。模型一直在运行，没人告诉它停止。

理解智能体工程模式意味着要明白两件事：典型的模式究竟是什么，以及在生产环境中未能正确实施这些模式的组织性失败是什么样的。模式是已知的，而持续应用这些模式的纪律性则不然。

循环并不是模式本身

从 LangGraph 到 Vercel AI SDK，每个主要的智能体运行时都趋向于相同的结构：调用 LLM、检查工具使用、执行工具、附加结果、重复直到完成。工程性并不存在于那个循环中。

智能体的成败取决于围绕循环构建的一切：

• 循环运行时如何管理上下文
• 如何根据任务类型限定工具的可用范围
• 如何强制执行终止
• 如何限制成本
• 如何捕获、分类和恢复错误

工程师需要内化的模式是处理特定类别智能体工作的组合构建块。经过数百个团队生产部署验证的最持久的分类法确定了六种：

提示词链 (Prompt chaining) 将目标分解为 LLM 调用的顺序管道，每一步的输出决定下一步。当子任务定义明确且依赖顺序时 —— 生成草稿、然后翻译、然后格式化 —— 这是正确的模式。每一步都有清晰的范围，使得调试失败和更换单个组件变得更加容易。

路由 (Routing) 对传入的请求进行分类并分发给专门的处理程序。路由让你能够为每个任务类别维护精简、专用的提示词，而不是将所有可能的指令塞进一个庞大的系统提示词中。路由器本身可以是 LLM、分类器或规则引擎 —— 核心特性是下游处理程序不需要处理它们并非为此设计的案例。

并行化 (Parallelization) 拆分独立的子任务并同时运行它们。在 “分段 (sectioning)” 形式中，问题的不同部分被并发处理以降低延迟。在 “投票 (voting)” 形式中，同一个提示词运行多次并汇总结果 —— 当你想要比单次调用更高的置信度，又不想支付更大模型的费用时，这非常有用。

编排器-工作者 (Orchestrator-workers) 由中央 LLM 负责规划并将子任务动态委托给专门的工作智能体。这适用于开放式任务 —— 多文件代码修改、复杂的研究流程 —— 在这些任务中，完整的子任务集合无法预先确定。工作者在隔离的上下文窗口中运行，这防止了串扰，但给编排器带来了协调负担。

评估器-优化器 (Evaluator-optimizer) 运行生成-批评-改进循环，一个模型产生输出，另一个模型对其进行评估。有效时，它通过将每一次改进建立在可观察到的差距上，明显地提高质量。失败模式也有据可查：如果没有明确的迭代上限或质量阈值，循环会降级或无限运行。终止不是可选的。

增强型 LLM (The augmented LLM) 是基础构建块 —— 一个通过检索、工具和记忆扩展的单一模型。所有其他模式都构建在此之上。

为什么反思（Reflection）比看起来更难

评估器-优化器模式催生了一系列基于反思的智能体，这些智能体在 2025-2026 年变得非常流行。生成、批评、改进。一些实现维护跨迭代的错误 “言语记忆 (verbal memory)”，而不仅仅是在单次会话中（Reflexion 智能体）。其他实现则对中间推理步骤进行打分，而不仅仅是最终输出（过程奖励模型 Process Reward Models）。

当评估标准清晰且客观时，反思确实能提高输出质量。Andrew Ng 的评估是成立的：它是从业者可用的最可靠的质量杠杆之一。但有两个失败模式被低估了。

首先，过度编辑。没有终止条件的反思循环不会在输出 “足够好” 时停止 —— 它们会在循环触及上限或耗尽预算时停止。在多次迭代中，模型通常会因为对本身就不确定的批评进行过度编辑，从而偏离正确的输出。

其次，相关性失败。如果生成器和评估器都是同一基础模型的微调变体，它们会共享相关的盲点。评估器会恰好漏掉生成器漏掉的东西。共识看起来像可靠性，但其实不然。

反思对于需要来源追溯、合规性或一致政策执行的输出也是不够的。“模型与自身达成一致” 并不是一个有意义的审计追踪。

扼杀生产部署的反模式

2025 年 3 月对 150 多个多智能体执行追踪的分析确定了 14 种不同的故障模式，分为三类：规范与系统设计故障、智能体间失调故障以及任务验证故障。核心发现：多智能体系统中的大多数故障源于智能体间的交互问题，而非单个模型的能力问题。提示词工程的修复仅带来了约 14% 的改进 —— 研究人员据此得出结论，系统性修复需要架构层面的重新设计。

错误放大是最被低估的动态。与单智能体基准相比，非结构化多智能体网络会将错误放大高达 17.2 倍。错误不会相互抵消，而是会产生级联反应。通过增加更多智能体来解决可靠性问题通常只会适得其反。

在失败的部署中，有几种反模式不断重复出现：

上下文堆砌 (Context stuffing) —— 将所有可用信息全部塞入上下文窗口 —— 会降低准确性并推高成本。Shopify 的工程团队发现，工具输出消耗的 Token 数量是用户消息的 100 倍。上下文并非中性资源；它是昂贵且有限的。研究表明，LLM 对长提示词开头和结尾信息的记忆效果远好于中间内容。在长期运行的智能体中，上下文腐烂通常始于 50,000 到 150,000 个 Token 之间。

起步即采用复杂的多智能体架构 也许是最常见的昂贵错误。大多数问题并不需要多个智能体，在验证单智能体解决方案之前就直接跳转到编排框架，会增加协调开销、错误放大风险和调试不透明性，且没有任何经过验证的收益。

让 LLM 担任编排者 将另一个概率性系统置于路由和验证决策的关键路径上。对于大多数生产负载而言，带有类型化计划（且在执行前经过验证）的确定性路由比 LLM 介导的编排更可靠、更廉价。

忽视工具经济学 是导致每周产生 47,000 美元账单的原因。每一次工具调用都是一次成本事件。工具需要强模式 (Hard Schemas)、幂等保护、超时设置和断路器。模型建议运行什么；平台决定是否运行。

上下文工程并非可选

上下文管理是一门在规模化应用中区分“正常工作的智能体”与“故障智能体”的学科。它需要在每一步都对进入上下文的内容、修剪的内容以及保留的内容做出有意识的决策。

“更精简的上下文让模型更聪明” —— 百万级 Token 的上下文窗口是应尽量远离的上限，而非值得利用的特性。上下文越大，模型就越难关注真正相关的内容。Cursor 的 Tab 功能每天处理超过 4 亿次请求，它会根据任务类型严格限制工具的可用性。并非所有工具在每次请求中都可用 —— 只有与当前任务相关的工具才会被提供。

在长期运行的流水线中，带有 TTL (生存时间) 和有意识遗忘机制的分级存储至关重要。携带过时、无关或敏感上下文的智能体，轻则导致注意力污染，重则导致隐私泄露。记忆不应是一个无限增长的图书馆。

上下文压缩 —— 当长期运行的智能体通过总结先前的上下文以保持在窗口内时 —— 会引入一种特定的故障模式：智能体丢失了最初获得的指令。这不是理论上的风险。已有系统在面对“行动前确认”的提示词时，依然自信地执行了批量操作，正是因为这些指令在压缩过程中丢失了。

生产系统究竟在做什么

大规模运行智能体的团队已经达成了一些不可妥协的共识。

DoorDash 实行“循环预算 (Budgeting the loop)”机制 —— 对所有智能体计划设置严格的步数和时间限制，以防止系统抖动。其语音智能体每天处理数十万次支持电话，对话延迟控制在 2.5 秒或更低，但这需要对终止条件进行大量工作，而不仅仅是提升模型质量。

Ramp 在正式部署前，会让智能体在影子模式下针对真实交易运行，将预测结果与人类操作员的实际操作进行对比。只有在影子模式的准确率达到特定阈值后，才会激活实时智能体执行。这就是“自主权爬坡 (Autonomy ramp)”模式：在准确性得到验证之前，不要授予实时处理权。

一个临床试验监测系统记录了一个最具启发性的单一故障模式：智能体交接过程中的上下文丢失。一个智能体正确标记了缺失的第 14 天实验测试，但当任务转移到下一个智能体时，“协议允许有两天窗口期（即第 13 天的测试也有效）”这一知识并未随之转移。这种偏差在智能体的记忆中是真实的，但在协议中是有效的。没有持久化记忆的自主权并不等同于理解。

真正决定生产成功的工程学科是分布式系统和状态管理专业知识，而非 AI 专业知识。对 1,200 个生产部署的分析发现，前沿模型的重要性远不及深思熟虑的上下文管理、清晰的终止条件和稳健的错误处理。

模式即纪律

模式本身并非秘密。提示词链式调用 (Prompt chaining)、路由 (routing)、并行化 (parallelization)、编排者-执行者 (orchestrator-workers)、评估者-优化者 (evaluator-optimizer) —— 这些在概念层面已有详尽的文档记录并被广泛理解。Gartner 在 2025 年预测，由于不断上升的成本、不明确的价值或不足的风险控制，到 2027 年底，超过 40% 的代理式 AI (agentic AI) 项目将被取消。这种失败率并不是模型质量问题，而是实践中的模式应用问题。

写一个 while 循环是简单的部分。难点在于终止条件、上下文预算、错误分类、工具安全护栏，以及在你让智能体 (agent) 接触任何真实业务之前的影子模式验证。那些将这些视为事后补救的工程师会收到每周 4.7 万美元的账单。而那些将这些视为产品核心的工程师，则能交付每天处理数十万次请求的系统。

模式不在于代码，而在于纪律。