When Anthropic published Building Effective Agents in late 2024, it did something rare for the industry: it gave enginee

When Anthropic published Building Effective Agents in late 2024, it did something rare for the industry: it gave engineers a shared vocabulary. Instead of another manifesto about artificial general intelligence, the guide offered six clear patterns for structuring LLM systems. A year and a half later, in 2026, the landscape looks radically different. Model Context Protocol has become a universal standard. Claude has gained new capabilities. Most organizations now have at least one agent running in production. Against that backdrop, it is fair to ask whether those six patterns still matter, or if they belong in the archive next to last year’s model weights.

I tested all six patterns against a local model in a side repository to find out. The answer is yes. They still hold up. But not because they are immutable laws. They hold up because the last eighteen months of production experience have validated the framework’s core logic.

What the Framework Actually Gave Us

The six patterns are worth remembering precisely: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, and Autonomous Agents. That last one is essentially a loop in which the model plans, acts, observes, and repeats until some condition is met.

Plenty of engineers were already chaining prompts or delegating tasks to worker threads before the guide appeared. What Anthropic provided was taxonomy. One person’s “agent” was another person’s “workflow,” and a third person’s “multi-step tool call.” The guide sorted the mess into buckets with clear boundaries. That made it possible to argue about trade-offs without talking past each other. In a field drowning in hype, crisp language is a kind of infrastructure.

The Industry Built On Top, Not Around

By 2026, these categories are baked into how teams design systems. Anthropic still teaches them in their Academy courses. Research papers and engineering blogs still use the same six buckets to describe new architectures. That kind of longevity is unusual for a discipline that refreshes its stack every quarter.

The reason is straightforward. The industry did not replace the framework. It built on top of it. New tools like MCP and the newer Agent Skills standards function as plumbing. They make it easier to connect a model to a database, expose a tool, or manage state. But they do not change the logic of when to use a router instead of an orchestrator. A better pipe does not rewrite the floor plan.

Production data in 2026 confirms this. The most common deployment pattern is still a single tool-use call paired with human review. The second most common is a multi-step workflow with exactly one handoff to a person. Both are direct descendants of Prompt Chaining and Routing. Full autonomous loops remain the exception, not the rule, in live systems.

Restraint Won the Market

The original guide’s best advice was also the advice most often ignored in 2024: use the simplest pattern that works. Do not deploy a full autonomous agent if a hardcoded path will get the job done.

The market has finally internalized this. Most agent pilots still fail, and they fail for the same predictable reason. Teams stack abstraction on abstraction until no one can trace the decision boundary. When the system drifts, debugging becomes archaeology. The companies that have succeeded in production are the ones that showed restraint. They defaulted to single-turn tool use. They added a routing layer only after the single prompt proved inconsistent. They treated autonomy as a liability to be justified, not a feature to be celebrated.

This is not an argument against ambition. It is an argument for composition. The patterns work best when you combine them deliberately rather than reflexively reaching for the most complex option on the menu.

Where the Seams Start to Leak

The framework is not a cure-all. There are hard limits that show up the moment you leave the prototype stage.

---

当 Anthropic 在 2024 年底发布 Building Effective Agents 时，它为行业做了一件罕见的事：它为工程师们提供了一套共同的词汇。它不是另一篇关于通用人工智能的宣言，而是一份提供了六种构建 LLM 系统清晰模式的指南。一年半后的 2026 年，行业格局已发生了翻天覆地的变化。Model Context Protocol 已成为通用标准。Claude 获得了新的能力。大多数组织现在至少有一个智能体在生产环境中运行。在这种背景下，人们完全有理由质疑这六种模式是否仍然重要，或者它们是否已经成为了像去年的模型权重一样的陈旧档案。

为了找出答案，我在一个侧边仓库中针对本地模型测试了所有六种模式。答案是肯定的。它们依然站得住脚。但这并不是因为它们是不可逾越的定律，而是因为过去 18 个月的生产实践验证了该框架的核心逻辑。

该框架究竟带给了我们什么

这六种模式非常值得铭记：Prompt Chaining、Routing、Parallelization、Evaluator-Optimizer、Orchestrator-Workers 以及 Autonomous Agents。最后一种本质上是一个循环，模型在其中进行规划、行动、观察并重复，直到满足某种条件。

在该指南出现之前，许多工程师已经在进行提示词链式调用或将任务委派给工作线程了。Anthropic 提供的是一套分类体系。一个人的“智能体”可能是另一个人的“工作流”，而第三个人眼中的则是“多步工具调用”。该指南将这些混乱的概念归纳到了边界清晰的类别中。这使得人们可以针对权衡取舍进行讨论，而不会各说各话。在一个充斥着炒作的领域，精准的语言本身就是一种基础设施。

行业是在其之上构建，而非绕其而行

到 2026 年，这些类别已经融入了团队设计系统的方式中。Anthropic 仍在其实践课程（Academy courses）中教授它们。研究论文和工程博客仍在使用这六个类别来描述新的架构。对于一个每季度都要更新技术栈的学科来说，这种生命力是非常罕见的。

原因很简单。行业并没有取代这个框架，而是在其基础上进行构建。像 MCP 和更新的 Agent Skills 标准这样的新工具充当了“管道”的角色。它们让模型连接数据库、暴露工具或管理状态变得更加容易。但它们并没有改变“何时使用路由而非编排器”的逻辑。更好的水管并不会重写房屋的平面图。

2026 年的生产数据证实了这一点。最常见的部署模式仍然是单个工具调用配合人工审核。第二常见的模式是具有一次精确人工交接的多步工作流。两者都是 Prompt Chaining 和 Routing 的直接后裔。在实时系统中，完全自主的循环仍然是例外，而非常态。

克制赢得了市场

原指南中最好的建议也是 2024 年最常被忽视的建议：使用能解决问题的最简单模式。如果硬编码的路径就能完成工作，就不要部署完整的自主智能体。

市场终于内化了这一点。大多数智能体试点项目仍然失败，而且失败的原因如出一辙且可预见：团队不断在抽象之上叠加抽象，直到没有人能追踪决策边界。当系统发生漂移时，调试工作就变成了“考古学”。那些在生产环境中取得成功的公司，是那些懂得克制的公司。他们默认使用单轮工具调用；只有在单次提示词被证明不一致时，才会添加路由层；他们将自主性视为一种需要证明其合理性的负债，而不是一个值得庆祝的功能。

这并不是在反对雄心壮志，而是在主张组合。当你刻意地组合这些模式，而不是反射性地选择菜单上最复杂的选项时，这些模式的效果才是最好的。

缝隙开始渗漏之处

该框架并非万灵药。一旦你离开原型阶段，就会遇到一些硬性的限制。

对于高频、低成本的任务，确定性代码仍然是首选。当 pandas 可以在几毫秒内完成规范化且不会产生幻觉时，不应该让 LLM 去处理 CSV 列的规范化。如果你无法定义一个明确的评估目标，请避免使用自主循环。如果没有清晰的停止条件，模型会不断迭代，直到它自己编造出一个停止的理由。对于需要外部事实依据的高风险决策，不要仅仅依赖模型的内部知识。此外，还要注意数据检索中的瓶颈。任何依赖向量搜索或外部 API 的模式，如果数据库响应缓慢或上下文窗口被无关的分块填满，都可能导致性能停滞。

这些并非假设性的边缘案例。它们是区分“一个可运行的 Demo”与“一个能经受住周末考验的系统”的关键约束。

僵化的检查与错误的失败

在构建我的测试仓库时，我体会到了这个框架的实际价值。当时我正在实现“评估者-优化者”（Evaluator-Optimizer）模式。我的评估器最初是一个硬编码的正则表达式，用于扫描模型输出中的特定关键词。模型返回了一个正确且逻辑严密的答案，但恰好使用了同义词，而不是我正在寻找的精确词汇。评估器因此将其标记为失败。

模型是对的。我的检查过于僵化。

修复这个问题不仅仅是扩大词表那么简单。我将评估器本身切换到了基于 LLM 的判断。这虽然增加了额外的 Token 消耗和几毫秒的延迟，但它将评估恢复到了正确的抽象层级。模式本身是合理的，我只是为该任务选择了错误的实现方式。这恰恰是该框架旨在防止的那类错误。有些评估需要代码，而有些则需要模型。辨别两者的区别正是核心所在。

现在该如何使用它们

将这六种模式视为起点，而非绝对法则。从单个提示词（prompt）开始。如果不同输入类型的质量不稳定，请添加一个路由层，将不同的请求发送给专门的提示词。如果你在做出决策前需要多个独立的视角，请使用并行化（Parallelization）。如果任务庞大且可拆分，请尝试编排者-执行者（Orchestrator-Workers）模式。只有当问题空间过于宽广而无法进行预先映射，且你拥有可靠的