从 Demo 到生产：AI Agent 缺的到底是什么？

搭一个 AI Agent Demo，可能一个下午就够了。但要把它真正做到可以投入生产，完全是另一回事。 一个生产级 Agent 必须稳定在线、足够安全、控制好成本，而且当它不可避免地出问题时，你还得有足够的可观测性去弄清楚到底哪里出了错。这些能力几乎都不是模型本身提供的，而是来自你围绕模型搭出来的所有东西：记忆、工具访问、模型路由、护栏、成本控制，以及当 Agent 开始乱来时，你不得不翻进去排查的各种 trace。 这一层，就是我们所说的 Agent Harness。 接下来这篇文章会带你了解什么是 Agent Harness，以及它的两大组成部分：开发和运维。然后，我们会看看团队该如何决定哪些东西自己管理，从完全托管的 Harness-as-a-Service 到自主管理的技术栈。最后，我会用两种方式分别构建同一个 Agent——FinBot，并逐项对比它们如何实现同样的能力。读完之后，你应该会更清楚，如何利用本文介绍的 Harness 能力来构建真正可投入生产的 Agent。 Agent = Model + Harness “Agent Harness”这个说法是今年才真正流行起来的，但背后的工作早就存在了。如果你去年就在做 Agent，其实已经在干这些事：把各种工具接起来、反复调 Prompt、补上重试和日志，再在系统半夜把人叫醒之后，第二天继续修复故障。现在真正发生的变化，只是大家终于给这些工作起了一个统一的名字。这个名字很有用，因为它让你可以把这些零散能力当成一个整体来设计，而不是每出一次问题，就往系统里再塞一个临时修复。 我最常用的一种理解方式，来自 Vivek Trivedy 的文章 The Anatomy of an Agent Harness "：Agent = 模型 + Harness。换句话说，如果你负责的不是模型本身，那你做的基本都属于 Harness。用汽车来类比，这件事就很好理解了。 模型就像发动机，动力来自这里。但没有人会把一台裸发动机固定在托盘上，然后直接交付给客户。底盘、刹车、仪表盘和安全带，才让它成为一辆你愿意让家人坐进去的车。模型只是发动机；真正让产品变得安全、可靠、好用的，是你围绕它搭出来的 Harness。 Harness 分成哪两部分？ 在我看来，Harness 大致可以分成两部分。开发侧负责扩展模型能做什么，包括跨会话记忆、工具和 MCP、检索、Prompt，以及编排。运维侧负责在真实用户进来之后，让整个系统稳定运行，包括可观测性、评估、护栏、路由、漂移和成本监控、部署，以及扩缩容。 这里需要说明一下：看到这样一张两边明显不对称的图，很容易误以为模型没那么重要。当然不是。真正困难的认知工作依然由模型完成，模型越强，上层能力也会一起受益。这里想强调的是：一个 AI Agent 并不只是模型，它最终是一个产品。做出一个好产品，远不只是给模型包一层 API，而那些让它真正能被用户使用的额外工作，大多都落在 Harness 上。如果你过去做过线上服务，这里面很多东西其实并不陌生：尤其运维这一半，本质上就是换了个名字的 DevOps。 两条路线：托管还是自己管？ 有一点最好先想清楚：HaaS 和自主管理方案，本质上解决的是同一类问题——它们都是构建和运行 Agent 的基础设施。底层也都是那几块能力：模型访问、检索、工具和 MCP、路由、护栏等等。 真正不同的，是这些能力如何交到你手里，以及你如何使用它们。HaaS 把它们做成托管 API，你负责配置；自主管理方案则把这些组件交给你，由你自己组装、部署和维护。这个差异最终会落到几个很实际的问题上：你能多快上线、能保留多少控制权，以及 Harness 最后要花多少钱——一边是供应商账单，另一边是基础设施和工程人力的成本。零件其实没变，变的是谁来装，以及坏了以后谁会在半夜被叫醒。 该选托管，还是自己搭？ Harness-as-a-Service 在一端，自主管理在另一端，很多团队最后都会落在中间，这很正常。两者之间有多种选择，具体选哪一种，主要看下面几个问题： 团队能力——你们能不能长期维护 Kubernetes、Gateway，并安排值班？或者说，你们其实真的不想管这些？ 现有云投入——你们已经完全押注 AWS，还是有意保持多云？ 成本——你更想要一张可预测的供应商账单，还是基础设施成本再加自己运行它所需的工程时间？HaaS 更容易做预算；而在规模扩大之后，如果无论如何你都已经要投入人力运营系统，自主管理有可能更便宜。 治理——护栏、审计记录和数据路径是否必须留在你自己的边界之内？有些企业要求所有这些东西都必须运行在自己的 VPC 中。 可移植性——只用一家供应商没有问题，还是你必须保持云无关？ 预期规模——为了支撑这个规模，你愿意承担多复杂的一套运维体系。 对运维复杂度的容忍度——你真的愿意长期处理集群维护、升级，以及偶尔凌晨 3 点响起的告警吗？ 用 FinBot 看看生产级 Agent 真正缺什么 FinBot 是一个很小的 Agent，两种方案都会使用同一个场景。用户提出一个财务问题：“总结第三季度营收”。FinBot 会从文档存储中取出该季度的财报，把数字交给代码解释器，再调用模型写出总结，最后返回答案。 要让这套流程真正进入生产环境，关键并不在于选一个更聪明的模型，而在于围绕模型搭建什么。再强的模型，自己也不会记住上一轮对话，不会访问财报，不会在失控循环产生巨额账单之前停下来，也不会在出错之后告诉你问题到底发生在哪。这些都是 Harness 要解决的事情，它们围绕着同一条请求路径展开。接下来，我会让同一个请求分别走过两套方案，完成同样的任务，只是按照各自技术栈最自然的方式来实现。 一套真正的 Harness 包含很多相互配合的组件（可以回头看看前面那两大部分），一篇文章不可能全部讲完。我会从两边各挑几项：先看 FinBot 本身如何构建，再看三个运维能力。在我的经验里，它们往往最能决定一个 Agent 是否达到了生产要求。护栏、评估、Prompt 编排、部署和扩缩容，以及多 Agent 工作流，这里都不会展开。这些确实是本文没有覆盖的部分，并不意味着可以将它们排除在外，因为要把 Demo 真正做到生产可用，这些问题也都必须处理。下面先说明所选的几项能力为什么重要，这样后面的方案 1 和方案 2 就可以专注于各自如何实现它们。 构建 Agent 开发侧只保留 FinBot 真正需要的东西：System Prompt、它能访问的工具（一个用于财报的 MCP Server，以及一个运行 MCP 代码执行服务器的容器）、针对这些财报的检索，以及跨轮次记忆。这也是两套技术栈差异感最明显的地方。一边是一个配置对象，另一边则是一组需要你自己部署和维护版本的进程。 统一模型访问 每一家模型供应商都有自己的 SDK、认证方式和响应格式，自托管模型还会再多一套。你真正需要的是一个统一入口，这样无论是新增模型、给新模型做金丝雀测试，还是故障时切到另一家供应商，都只需要改配置，而不是改应用。供应商密钥也只需要放在一个地方，而不是散落在每个服务中。 成本控制 一个有 Bug 的循环，或者一个没考虑周全的功能，都可能让