给能干活的 Agent 造一个生产环境的笼子

AI Engineer World’s Fair 2026 的 Harness Engineering 专场排了一整个上午,从九点排到中午,一共五场。几乎都在回答同一个问题:怎么让 agent 在没人盯着的时候还靠谱。压轴的这场来自 AWS,讲者是高级 AI 专家 Mike Chambers。他没有再重新定义一遍 harness,而是直接打开命令行,演示这套工程现在已经能打包成几个单选题。

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 03:15:20 开始）

两种 agent，两种活法

Chambers 上来先做了一个区分:世界上其实有两种 agent。一种是我们用的 agent——Claude Code、Cursor、Kiro 这类编码助手,还有各种效率工具。这类 agent 你自己说了算,想怎么用怎么用,token 想怎么花怎么花。买单和承担后果的都是你自己。

另一种是我们造的 agent,要交给别人用、跑在生产环境里。这种 agent 出了问题,承担后果的不是开发者本人,是终端用户。Chambers 说,这才是这场演讲真正要谈的,也是”harness engineering”这个词真正要解决的问题。

他给 harness 下的定义很直接。词典里说 harness 是”用来控制动物的一套挽具”,把”动物”换成”模型”,这句话原封不动就能用。再往下拆一句更干脆——拿一个 agent,把模型部分拿掉,剩下的东西就是 harness。这句话和 LangChain 的 Vivek Trivedy 那句”你不是模型,你就是 harness”几乎是同一个意思的两种讲法。这次是从 AWS 一线工程师嘴里独立说出来的,算是一次交叉印证。

造 agent 时，harness 里到底装什么

对”我们用的 agent”,harness 相对简单。公司帮你配好记忆怎么用、有哪些 skill 和工具、MCP 服务器怎么接文档。团队原来有编码规范,现在多了一条”harness 规范”——统一往所有人的编码助手里推送的配置。Chambers 顺带安利了 AWS 的 agent toolkit,开源挂在 GitHub 上,目的是让 agent 别再干”slop ops”。他的原话是不想让 agent 直接在控制台里点点点开资源,基础设施还是要走 infrastructure as code,部署这件事的所有权始终留在人手里。

对”我们造的 agent”,harness 要装的东西明显更多。记忆、skill 和工具只是基础,再往上还要管循环本身怎么跑、怎么扩容、支付、身份、运行时、上下文管理。最后一项他特意强调”应该放在最前面说”——可观测性和评估。理由很朴素:要把 agent 部署给成千上万个用户,不能把这堆逻辑全塞进一个容器里一起扩容。每个组件都要能自己扩容、自己缩容,这才是”工程”两个字真正要担的活,不是喊个概念就完。

现场跑一遍：从裸 Strands agent 到 AgentCore 托管

讲完定义,Chambers 直接打开 Kiro 写代码,连续过了三个版本的 agent,一步步把 harness 的重量码给你看。

第一个版本极简:用 Strands Agents SDK 包一个 agent,挂两个工具,一个计算器、一个查时间,系统提示写几行。他自己问”这算 harness 吗”,答案是”勉强算”。循环本身是框架管的,除此之外几乎什么都没有,这个版本只能跑在自己笔记本上,没有扩容能力。

第二个版本加了记忆。接入 session manager,让对话状态能在多次调用之间延续,还给 agent 一个”remember”工具,由它自己判断要不要把某句话记下来。现场演示时他问”谁会赢世界杯”,agent 因为记得之前聊过他住在澳大利亚,直接回答”澳大利亚”。这个小细节挺能说明问题:同一句”谁会赢世界杯”,换个时间问,答案会因为 agent 记得你住哪而变。记忆一旦持久化,agent 就不再是一张白纸。这一版依然只在本地跑,离云端规模还差一步。

第三步是 Bedrock AgentCore 的命令行工具。跑一遍交互式配置:选 Python 还是 TypeScript,他选了 Python;选接口协议,HTTP、MCP、AGUI 三选一,他选了 HTTP;选模型,默认给的是 Sonnet 4.5;要不要开长期和短期记忆,他选了开。记忆一开,云端会单独起一套基础设施来管这些记忆,不占用正在跑的 agent 的资源,两边异步跑、互不卡着。配置生成的代码里,多租户隔离已经写好。你写一个只服务单个用户的 agent,AgentCore 负责把它扩展成能服务很多用户,不用自己再写一遍多租户逻辑。agentcore dev 能在本地起一个网页,连着正在跑的 agent 实时调试。agentcore deploy 用 infrastructure as code 把这套东西真正部署上云,连带 trace 和记忆调试界面一起给你。

这里最值得记住的一步,是他专门跳过又折回来讲的”harness”预设选项。如果在交互式配置里直接选 harness,不需要写任何 agentic 代码,配置文件就是一个 JSON,里面只有”用哪个模型”和”系统提示是什么”两行。agentcore deploy 照样能把它部署出去。Chambers 的判断是:如果这样就够用,那可能 80% 的 agent 开发需求已经被解决了,不需要自己手写循环、自己管工具调用,系统提示配好 MCP 工具连上就行。这个 80% 和 Vercel 在 d0 项目里砍掉八成工具定义、成功率反而从 80% 拉到 100% 的经历,说的是同一件事:大多数 agent 需求,复杂度都用不上一整套自定义 harness。

延伸：harness 正在被打包成产品

这场演讲在当天的位置很清楚。它是 Harness Engineering 这条 track 从早上九点排到中午的收尾场,前一场 Michael Grinich 刚讲完”给 agent 做身份认证”(auth.md)。这一场紧接着把身份、支付也列进了”造 agent”必须装的 harness 组件,两场连起来看,是同一条 track 在往”生产级 agent 到底需要哪些硬约束”这个问题上收口。

我在整理 harness engineering 相关笔记时留意到一个更大的趋势:harness 会随着模型变强而变薄,这不是纸面判断。之前记录过 Manus 半年内重写五次,每次都在删脚手架而不是加;Anthropic 也在定期从 Claude Code 里删掉规划步骤。Chambers 这场演讲给这个趋势补了一个来自云厂商产品线的实锤——AgentCore 的 harness 模板,本质上是把”搭 harness”这件事从工程师手搓的活,压缩成了几个下拉菜单。我自己会把这条经验直接搬过来用:接一个新 agent 项目前,先问一句”现成的 harness 模板够不够”,卡在模板解决不了的地方,再谈自建的成本值不值。