AWS推AgentCore Harness：基础设施有了，治理层谁来管？

周三下午，一个工程师终于删掉了自己写了三个月的Agent编排代码。不是因为它跑不通，而是因为AWS刚刚放出了Amazon Bedrock AgentCore Harness的公开预览版——那套他从头搭建的计算、内存、工具连接、可观测性栈，现在变成了一行配置。

AgentCore Harness解决的是"脚手架"问题。每个AI Agent背后都有一个循环：调用模型、选择工具、回传结果、管理上下文、处理失败。这个循环需要底层支撑：计算资源、沙箱环境、安全工具连接、持久化存储、身份认证、可观测性。这套东西就是Harness。在此之前，每个团队都在重复造轮子。

现在你只需要声明配置：用什么模型、接哪些工具、给什么指令。AWS负责剩下的。US West (Oregon)、US East (N. Virginia)、Asia Pacific (Sydney)、Europe (Frankfurt)四个区域已可用。没有单独的Harness费用，按实际使用的AgentCore能力付费。底层用的是Strands Agents，AWS开源的Agent框架。

这意味着换模型、加工具不再是重构工程，而是改配置。你的Agent有了安全环境、持久记忆、十几个工具可用。基础设施问题算是解决了。

但另一组问题敞开着：Agent能调用lookup_customer，但能不能在探索阶段就调用send_email？发送邮件前要不要人工确认？如果update_record成功但send_email失败，怎么回滚？预算超了90%时，哪些操作该被拦截？

AgentCore Harness能追踪发生了什么，但不能控制什么被允许发生。这是两个层级的边界，基础设施和治理需要解耦。而上面这些问题，不是靠加更多可观测性就能回答的——得在工具即将运行的那一刻强制执行规则。

ShapeV2（简称Shape）就是填这个空白的。一个单文件Python库，约400行代码，零依赖。它在Agent逻辑和工具执行之间插入了一层治理：权限、阶段、事务。

具体怎么用？先定义Agent和预算，然后给每个工具标注"效果"：READ（只读）、REVERSIBLE（可撤销）、IRREVERSIBLE（不可逆）。接着写规则：什么阶段允许什么操作，预算用到什么程度该阻断。最后分两个阶段运行：explore（只读探索，安全）和commit（事务提交，全有或全无）。如果commit阶段某个操作失败，前面的可撤销操作自动补偿回滚。

这套机制把"能不能做"和"做没做"分开了。Harness管后者，Shape管前者。两者叠加，才是一个完整的Agent运行环境。

但这里有个张力。AWS作为云厂商，天然倾向于把功能做厚、做集成。AgentCore Harness已经内置了可观测性，为什么 governance 不一起打包？可能的答案是：治理规则太场景化了。金融行业的合规要求、医疗行业的审计路径、电商平台的退款策略——这些很难抽象成通用配置。

Shape的选择是反过来的：极轻量、可嵌入、让开发者自己写规则。400行代码意味着你能读完全部源码，知道它在干什么。零依赖意味着不会因为某个库的版本冲突导致生产事故。

两种路线没有绝对优劣。团队如果追求开箱即用、AWS生态内闭环，Harness本身已经能跑。但如果Agent要处理资金流转、用户数据修改、不可逆的外部调用， governance 层不是可选项，是必选项。

一个值得关注的细节：Shape的commit模式实现了"补偿事务"。这不是新概念，分布式系统里叫Saga模式。但在Agent场景里，LLM的不可预测性让事务边界变得模糊——模型可能突然决定多调一个工具，或者参数填错。Shape的做法是把补偿逻辑显式化，让开发者必须考虑"如果这一步失败，上一步怎么回退"。

另一个细节是预算控制。Shape在Agent级别设了预算上限，规则里可以写"预算超90%时阻断所有操作"。这比事后看账单更接近实时风控。对于按token计费的模型调用，或者按次计费的外部API，这种前置拦截能避免凌晨三点的账单惊吓。

回到AgentCore Harness本身。它的发布意味着AWS正式把Agent基础设施"云化"了——不是卖组件，而是卖运行环境。这对中小团队是利好，不用再为编排层招专门的人。但对做Agent平台的公司，可能是个挤压。如果你的核心价值只是"帮你搭Harness"，现在AWS免费做了。

不过治理层的故事还没结束。Shape目前是个开源库，没有商业托管版本。企业如果要上生产，得自己集成、自己运维。这里面有创业公司的机会：把Shape的规则引擎做成托管服务，对接Harness的运行时，提供审计日志、合规报告、多租户隔离。

也可以反过来看：AWS会不会在Harness里加原生 governance ？历史经验是，云厂商通常先做基础设施，等生态成熟后再向上整合。但如果 governance 真的高度场景化，AWS可能选择让合作伙伴来做，自己保持Harness的"中立性"。

对开发者来说，现在的最优路径可能是：用Harness快速把Agent跑起来，用Shape补上 governance 缺口，同时关注AWS的路线图。如果半年后Harness内置了规则引擎，再评估迁移成本。如果AWS始终不做，围绕Shape的托管服务可能会成为一个细分赛道。

Agent技术栈正在分层固化。基础设施层（Harness）、治理层（Shape这类）、模型层、工具层——每一层都在寻找自己的边界。对应用开发者，这是好事：可以按需组装，不用all in某一家的黑盒。对基础设施创业者，挑战在于找到AWS不会做、或者做不好的缝隙。

AgentCore Harness和Shape的组合，展示了一种可能的终局形态：云厂商管"跑起来"，开源社区/第三方管"管得住"，应用开发者管"做得对"。三层分工，各尽其职。至于这个终局会不会到来，取决于 governance 的需求到底有多普遍、多差异化。

目前能确定的是：只解决基础设施的Agent，和同时解决 governance 的Agent，在生产环境里的容错率不在一个数量级。Harness让前者变得容易，Shape让后者变得可行。两者之间的距离，就是当前Agent落地的真实鸿沟。