约束工程实战：为生产级智能体打造可扩展的Harness

在AI Engineer大会上，来自AWS的高级AI专家开发者布道师Mike Chambers带来了一场关于「约束工程」（Harness Engineering）的分享。他没有停留在概念层面，而是通过现场编码演示，展示了如何将一个跑在笔记本上的原型智能体，一步步升级为可在云端大规模部署的生产级系统。

两种截然不同的智能体

Mike开场就抛出了一个值得深思的区分：市面上讨论的「智能体」其实分为两类，而且它们的设计逻辑完全不同。

第一类是我们使用的智能体（agents we use），比如Claude Code、Cursor、Kiro这类编程助手，以及各种提升生产力的工具。对于这类智能体，用户怎么「压榨」token、怎么激进使用都无所谓，因为使用者就是自己。

第二类是我们构建的智能体（agents we build）。这才是这场分享的核心。当你要把一个智能体部署给成千上万的用户使用时，思路必须完全转变——你需要为最终受众精心设计，确保它能稳定、安全、可扩展地运行。

有意思的是，这两类智能体会相互串联：你构建的智能体，可能正是别人在使用的智能体。

什么是Harness（约束）

Mike用了一个略显直白的类比来定义harness。字典里，harness指「用于控制动物的一套绳索和扣具」——如果把「动物」换成「模型」，这个定义竟然出奇地贴切。

用更工程化的语言来说：**把一个智能体中的模型部分拿掉，剩下的所有东西就是harness。**LangChain、martinfowler.com（由Brigitta撰写的《Harness engineering for coding agents》）等都发表过相关文章，说明这一概念正在业界形成共识。

工程团队的标准与harness规范

对于「我们使用的智能体」而言，harness相对简单：编程助手运行在本地机器上，能访问文件，配置了记忆管理、技能、工具和MCP服务器。成熟的工程团队几十年来都有编码规范，如今则演变为「harness规范」——统一部署到所有人的编程助手上。

Mike还顺带推荐了AWS的Agent Toolkit（GitHub开源免费），核心目的是杜绝他所说的「slop ops」。就像专业云开发一直反对「click ops」（在控制台点来点去部署）一样，你不该让智能体直接去建个S3桶、开个EC2实例，而应该让它生成基础设施即代码（IaC），这样你才能真正掌控云端部署。

MCP（Model Context Protocol）是Anthropic于2024年底发布的开放标准协议，旨在统一AI模型与外部工具、数据源之间的交互方式。可以将其理解为AI领域的「USB接口」——开发者只需按照MCP规范封装工具，任何支持该协议的智能体都能即插即用地调用这些工具，无需为每个智能体单独编写集成代码。MCP服务器可以暴露文件系统访问、数据库查询、API调用等各类能力，大幅降低了harness层的工具接入成本。这也解释了为什么「系统提示词加几个MCP工具」就能覆盖大量智能体用例——MCP生态的繁荣使得现成工具触手可及。

从本地原型到云端规模

Mike的现场演示分为几个递进的阶段。

最简单的Strands智能体

第一个示例是一个基于Strands Agent SDK的极简智能体：引入agent和tool装饰器，传入系统提示词，再挂上两个工具——计算器和获取时间。循环由框架自动管理。

传入系统提示词构建智能体

这算是harness吗？勉强算，但内容非常单薄。它跑在笔记本上，没有规模，也缺少生产级智能体所需的关键属性。

加入会话与记忆管理

第二个示例由Kiro生成，重点是引入了session manager（会话管理器）。它能在多次调用之间维持会话状态，属于一种中短期记忆，同时也能把长期记忆存储到本地文件中。

智能体里定义了一个remember工具，可以主动决定记住关于用户的信息。演示中，当Mike问「谁会赢得世界杯」时，智能体基于之前的对话记忆，知道他住在澳大利亚、希望澳大利亚获胜——这正是会话记忆在起作用。当然，它也诚实地承认对结果毫无预知能力，因为答案本质来自大语言模型。

用Agent Core实现云端规模化

真正的挑战在于：如何把这样的智能体部署到云端规模，并让记忆、循环等组件各自独立扩展？把所有代码塞进一个容器再横向扩展，显然无法支撑成千上万的用户。

这正是harness engineering的严肃之处。Mike列举了构建生产级智能体需要单独考虑的组件：循环管理、扩展、支付、记忆、身份、技能、运行时、上下文管理，以及他强调「本该第一个提但放到最后」的——可观测性与评估（observability and evaluations）。

已完成部署的智能体

Mike使用AWS的Bedrock Agent Core来解决这些问题。通过命令行工具agent core，开发者可以一步步配置并部署智能体：

语言选择：Python或TypeScript
接入方式：HTTP、MCP服务、或AG-UI（用于构建交互式聊天智能体）
框架：任意框架，Mike用的是Strands Agents SDK
模型：支持任意模型，不限于Amazon Bedrock，演示中默认使用Sonnet 4.5
记忆：可勾选部署长期和短期记忆，系统会创建独立的云基础设施，异步管理这些记忆并与智能体保持连接

生成的生产级智能体代码相比本地版本只多了对Bedrock Agent Core App的接入，但就凭这一点，就能实现多租户隔离和运行时扩展。也就是说，你只需编写面向单一用户的智能体，无需手写多租户代码即可横向扩展，这在安全和身份管理上大大简化了工作。

本地调试与一键部署

通过agent core dev命令，会启动一个连接到本地运行智能体的Web界面，代码改动可实时看到效果，也能切换到线上部署版本。agent core deploy则用IaC把智能体连同记忆、运行时等组件一起部署到云端，之后可通过界面查看追踪日志、记忆存储等信息进行调试。

Agent Core带来的便利

多租户隔离（Multi-tenant isolation）是SaaS系统的核心安全要求之一，指在同一套基础设施上服务多个用户时，确保每个用户的数据、会话和计算资源彼此完全隔离，互不可见、互不干扰。对智能体而言，这意味着用户A的对话记忆不能被用户B读取，某用户触发的工具调用也不能影响其他用户的状态。传统做法需要开发者手动在代码层面维护租户ID、设计隔离的数据存储方案，工程量可观且容易出现安全漏洞。Bedrock Agent Core将这一机制内置于平台层，开发者只需编写针对单一用户的智能体逻辑，平台自动处理租户隔离，这是其相比自建方案的重要工程价值。

IaC（Infrastructure as Code，基础设施即代码）是现代云工程的核心实践，指用代码（如Terraform、AWS CDK、CloudFormation等）声明式地描述云资源配置，而非通过控制台手动点击创建。其核心优势在于可重复性、可审计性和版本控制——任何基础设施变更都以代码形式留存，可通过代码评审、CI/CD流水线管控，并在出现问题时快速回滚。Mike在演讲中反复强调的「反对slop ops」正是这一理念的体现：让智能体直接调用API创建云资源，会绕过所有治理流程，产生难以追踪的「幽灵资源」。Agent Core的deploy命令将智能体及其依赖组件的部署全程以IaC表达，使云端智能体的生命周期管理与传统软件工程实践保持一致。

80%的智能体或许无需写代码

Mike提出了一个颇具冲击力的观点：既然部署一个能用的智能体只需要系统提示词加几个MCP工具，那么或许80%的智能体用例、80%的开发工作已经被解决了。

为此，Agent Core内置了harness能力。开发者只需提供一份简单的JSON配置——指定使用哪个模型、什么系统提示词——就能直接部署，甚至不需要写任何智能体代码。

更妙的是Agent Core的可组合性：所有能力（记忆、运行时、身份等）都是独立模块，可以任意搭配或单独使用。如果你已有一个在生产环境稳定运行的智能体，只是想要serverless的长期记忆管理，完全可以只集成那一部分。

结语

这场分享的价值在于把「智能体工程化」这件事讲得具体而落地。从区分「使用的智能体」与「构建的智能体」，到用harness概念统一理解智能体的非模型部分，再到通过Agent Core实现组件级的独立扩展，Mike展示了一条从原型到生产的清晰路径。对于正在思考如何把AI智能体真正部署到规模化生产环境的开发者来说，这些理念和工具值得深入研究。

感兴趣的读者可以关注开源的Strands Agents框架（模型优先、快速强大）以及Amazon Bedrock Agent Core。