企业级 AI Agent 的真实成本：从演示到生产

演示不等于部署

Agent 演示很容易。你给它一个 prompt，它写一些代码或起草一份报告，所有人都鼓掌。

然后你尝试把它放到一个实时系统附近，问题就开始了。这个东西实际上能调用什么？当它有把握地犯错时会发生什么？谁会被通知？

这些都不会出现在预测中。所有的都会出现在生产环境。

真正的边界不是"没有权限"。它是一份签署的授权令。

直觉的防护措施是禁止这个可怕的东西。不让 agent 转移资金。只读、仅建议、由人工点击按钮。

这种直觉已经成为历史。Agent 将会转移资金，因为支付是完成任务的一半。一个能够研究供应商、比较选项并填充购物车，然后停止并等待人工点击"确认"的 agent，这不是 agent。这是一个拿着购物清单的实习生。

这是 40% 中真正重塑经济的部分。不是编写代码的 agent。是能够进行交易的 agent。一旦 agent 能够支付，它就不再是助手，而成为了经济行为者，而为此的支付通道正在被构建。

这就是我们在 Atoa 所构建的：一条为 AI agent 服务的受监管的银行通道。一个 agent 通过 FCA 授权的通道在银行间结算付款，每次行动都有签署的记录。为该领域正在标准化的协议构建的，AP2 用于授权，x402 用于按需付费，MCP 作为接口。所以"永远别让它接触资金"从来不是我们的答案。答案是权力的所在地。

Agent 的支出权限不能是一个系统 prompt 中的一行，聪明的输入可以绕过它。它必须是一份签署的、范围明确的授权令：明确说明金额是多少、转给谁、在什么限制范围内，并且可以独立验证。每笔付款都要经过实时的可支付性检查。每笔付款都会留下签署的、可证明的记录，记录谁授权了它、资金检查返回了什么、它在哪里结算。

这就是值得内化的转变。边界从"agent 能采取行动吗？"移动到"agent 的权力是明确、范围明确且可证明的吗？"。自主 agent 转移的资金需要更多的监督，而不是更少。所以你把权力变成一个实际的工件，把审计跟踪变成非可选的，然后你让它支付。

在上下文中，而不是在希望中

这是一个来自 Bodhiorchard 的真实例子。

一个 agent 被要求生成一份支付报告。由于对任务的独立理解，它开始构建一个全新的服务来生成该报告。该报告已经存在。它即将重建一些我们已经有的东西，只是形状稍有不同，作为新的维护负担。

修复不是一个更聪明的 prompt。它是上下文。我们通过 MCP 在 agent 写一行之前向他们提供结构化上下文，我们在 Bodhiorchard 中称之为 BUD。一旦 agent 能看到现有的报告和背后的决策，它就做了明智的选择。它扩展了那里已有的东西，而不是生成一个副本。

这就是帮助的 agent 和悄悄增加你的技术债务的 agent 之间的区别。不是智力。是上下文。

确定性检查在概率步骤之前

Agent 的输出是一个猜测。通常是一个好的猜测。但仍然是一个猜测。

所以这个猜测不能是最后的定论。在 agent 生成的任何东西接近真实代码路径之前，它运行人工必须通过的检查。类型。Schema 验证。测试套件。编码决策的设计模式 lint，这些决策不是现成 linter 所提供的。在支付流中，可支付性检查扮演相同的角色：一个确定性门，概率步骤必须在任何东西结算之前通过它。

如果那个确定性层不在首位，你还没有部署一个 agent。你部署了一个有提交访问权限和没有代码审查的非常快的实习生。

有人负责故障

这是没人想在幻灯片上看到的部分，因为这是一个人数问题，而不是技术问题。

当一个 agent 失败时，它通常不会崩溃。它失败得看起来合理。报告看起来对。代码编译了。数字只是错了。这种故障需要一个人类业主，他对该领域的了解足够深，能发觉到问题，以及一份足够清晰的记录来追踪它。

我的心智模型：一个 agent 是一支几乎零失误的初级工程师大军。这对一位高级工程师来说是一份礼物，对一个没有高级工程师的团队来说是一个陷阱。用 agent 赋能高级工程师是正确的举措。用 agent 替换高级工程师是如何找出隐性故障成本的方法。

是的，40% 的应用可能会在 12 月之前拥有一个 agent。幻灯片将是正确的。

但 agent 不是工作。范围明确的授权令、上下文提供、确定性门、负责故障的人。那才是工作。那才是水线下的 60%。

而这个冰山最大的一块是支付。Agent 经济不是在模型变得更聪明时开始的。它在 agent 能够安全地、通过为它们构建的通道进行支付时开始。这不是一个 2030 年的故事。它现在已经开始了，我们正在构建其中一条支付通道。

如果你今年发布一个 agent，这四个中哪些你已经有了，哪些你希望模型为你处理？