为什么不能只用Claude做所有事

最近，我和一个朋友聊天，她和大多数人一样，虽然不是软件开发人员，也没有技术背景，却已经开始在工作中广泛使用 AI 来创建 agent。

她一直在用 Claude 做大量实验，为自己和团队构建有用的工作流，对这些系统的能力越来越兴奋。

聊着聊着，话题转到了我在 agent 系统方面的工作：agent 架构、context engineering、memory、orchestration、sub-agent，以及 Strands Agents 这样的框架。

她的反应是：

为什么你需要那些？我已经在创建 agent 了。

"好问题"，我心想。

更有趣的是，我从另一个方向也听到过几乎一样的问题。

在一场关于 agent 架构和用 Strands Agents SDK 构建 harness 的演讲之后，一位初级开发者走过来问我：

这些东西的意义是什么？为什么我们不能什么都用 Claude？

两个从完全不同方向切入这个话题的人，问出了同一个问题。

我认为这个问题暴露了当前 agent 领域的一个重要事实：我们在用同一个词 "agent" 来描述两种截然不同的活动，有着截然不同的用例。

我的看法是，创建 agent 和工程化 agent 之间有很大的区别。

Agent Creation vs. Agent Engineering

Claude、ChatGPT、Amazon Quick 等应用让人们无需自行构建底层基础设施，就能创建出令人惊讶的复杂 agent 工作流。

但仍然存在学习曲线。你需要提供指令，以一种能产生符合预期结果的方式向系统注入知识和上下文（而且最好不会产生幻觉！）。你可能还需要了解工具、设置集成、调度任务，甚至创建 sub-agent，让多个功能模块协同工作。

从用户的角度看，他们创建了一个 agent。确实如此！但当软件工程师看同一个系统时……他们看到的是不同的东西。

他们看到一个应用程序提供了一个高度抽象的、 opinionated 的 agent 运行时，作为一个黑盒运行。你对执行如何发生、上下文如何组装和维护、系统如何扩展、甚至 memory 存在于何处等架构问题几乎无法控制。

作为应用用户，你在别人构建的 agent 架构中创建了一个 agent。

这不是问题。事实上，这可能就是你所需要的！

开发者和软件架构师一直在抽象和控制之间做权衡。我们不因为低级技术能提供最多的控制就选择它；我们使用抽象是因为它们替我们省去了不想要做的决策和不需要拥有的复杂性。

同样的原则在这里也适用。如果 Claude 能让你创建一个所需的 agent，为什么不直接用它呢？

和系统设计一样，重要的是理解权衡。抽象之所以有效，是因为别人已经为你做出了一系列架构决策。如果这些决策符合你的需求，那就太棒了。如果不符合，你可能需要自己承担其中一些。

这就是我发现区分 Agent Creation 和 Agent Engineering 有用的地方。

对我来说，有三个因素特别清晰地划定了这个区别。

Is the agent a feature or a component?

这也许是我最喜欢的思考这个区别的方式。

假设我在 Claude 中创建了一个 agent 来帮我研究度假方案。它知道我的偏好、研究目的地、比较选项，也许还使用工具来制定行程。它可以非常复杂……但 Claude 仍然是那个应用。我去到 Claude，通过 Claude 的界面交互，依靠 Claude 的基础设施让一切运行。

我的 agent 是我正在使用的应用的一个功能特性。

现在想象我想通过我自己的旅游网站提供同样的体验。客户来到我的应用，请求一个度假行程；在幕后，一个 agent 研究航班和酒店、应用他们的偏好、与预订系统交互并返回结果。

功能听起来几乎一样，但架构上发生了根本性的变化。agent 现在是我正在构建的系统的一个组件。

突然之间我需要决定它在哪里运行、如何与它通信、如何扩展、如何对它进行身份验证以对接其他系统、失败时会发生什么、它如何融入传统应用流程，以及如何观察它的行为。AI 不再是目的地；它现在是我负责的系统的一部分。

这就是非常明确的 Agent Engineering。

关键在于所有权。如果一个 agent 是 Claude 或其他应用的功能特性，你就被限制在这些应用允许你做的事情之内——这是刻意设计的。如果你的需求在这个边界内，太好了。当不在边界内时……你需要另一种抽象。

Do you need control over the economics?

你选择工程化 agent 的另一个原因可能是成本。

目前有很多讨论关于 agent 系统会消耗多少 tokens，尤其是在我们构建长时间运行的工作流、使用大 context window、tool calls 和多 agent 时。

顺便说一句，从 Agent Creation 到 Agent Engineering 并不会自动让任何东西更便宜。工程化本身也有成本，花 10 万英镑的开发成本去节省 500 英镑的 tokens 那就太讽刺了。

工程化给你的是控制权。

如果你拥有 agent 周围的 harness，一些在别人应用内操作时根本不会暴露的架构决策就变得可用了。

你可以决定某个任务不需要完整的对话历史、缓存一个昂贵的结果、只在相关时检索 memory、在步骤之间总结上下文，或者将简单的任务路由到更便宜的模型。

你可以开始将 context 和 tokens 视为你主动工程的资源。

这里有一个更大的话题关于 context engineering，但那是另一篇文章的故事了。目前重要的是，抽象决定了哪些杠杆对你可用。

如果你不需要那些杠杆，承担它们的责任几乎没有什么价值。如果你的系统经济学表明你确实需要，Agent Engineering 就能给你那种控制。

Do you need to own where your data goes?

还有一个问题，在企业环境中往往很快就会变得重要：一切到底住在哪里？

当我在一个应用内创建 agent 时，我接受那个应用的架构及其处理 context、state、memory、集成和数据的机制。同样，这可能完全可以接受。

但如果某些数据不能离开特定环境呢？如果我需要确切知道长期 memory 被持久化在哪里、控制哪个模型接收哪些信息、维护我自己的审计日志，或者保证某些数据永远不会跨越某个边界呢？

现在这个黑盒就真的重要了。

这部分是一个合规问题，部分是数据所有权问题，而且，是的，部分是 vendor lock-in 问题。我在某个应用的抽象之上构建的行为、知识和 state 越多，我就越依赖那个平台的能力和约束。

但 vendor lock-in 本身并不是把一切都从头工程化的理由。我们在现代软件架构中接受了不同程度的 lock-in，因为托管的抽象可以提供巨大的价值。

问题只是：这个权衡对你面前的需求是否可接受。

So… Can't We Just Use Claude For Everything?

一个有用的电子表格最终可以变成一个应用，但这并不意味着那个电子表格是个错误。它可能恰好是当时问题的正确抽象，甚至可能帮助我们充分理解问题，知道后来什么值得工程化。

我认为 Agent Creation 和 Agent Engineering 应该用同样的方式来看待：不是成熟度阶梯上的不同级别，更不是每个 agent 最终都应该变成工程化 agent 的一段旅程，而是关于我们需要拥有多少底层系统的不同架构选择。我们可以开心地在 Claude 中为一个任务创建一个 agent，同时从零开始工程化另一个，甚至可能在同一个系统中。

有时候，在 Claude、ChatGPT、Amazon Quick 或其他应用中创建的 agent 会一直留在那里，因为它做我们需要的一切。有时候我们的需求意味着要自己承担架构的责任，我们会开始使用 Strands Agents SDK 或其他 agent harness。

也许下次有人问我"为什么我们不能什么都用 Claude？"的时候，我的回答将 simply be…

你可以！只要它的决策与你的兼容。**