CNCF 社区为什么开始讨论云原生 Agent Harness

云原生社区开始讨论 Agent Harness，不是因为“把智能体放进 Kubernetes”听起来更新，而是因为 Agent 一旦离开开发者笔记本，原本隐藏在单机进程里的身份、凭据、工作区、工具权限、会话状态和审计问题会同时暴露出来。此时 Harness 不再只是包住模型的一层循环，而逐渐变成承载 Agent 的控制面。

2026 年 9 月 28 日，CNCF 博客发布了一篇成员文章，Stacklok 的 Craig McLuckie 以开源项目 Mecatl 为例，提出“cloud-native agent harness”的架构方向。需要先划清边界：这是 CNCF 网站上的 Member Post，不是 CNCF 宣布新标准，也不代表相关项目已经成为 CNCF 托管项目。文章本身也明确区分了当前能力与仍在讨论的设计方向。

官方原文：https://www.cncf.io/blog/2026/09/28/the-case-for-a-cloud-native-agent-harness/

真正的转折点不是模型，而是运行环境

早期编码 Agent 主要运行在开发者电脑上。一个交互进程往往同时承担用户界面、Agent 循环、沙箱、凭据存储、工具宿主、文件系统和会话数据库。对单人单机来说，这种设计非常高效：权限来自登录用户，工作区就是本地仓库，失败了也可以人工接管。

问题在规模变化后出现。假设平台团队把同样的进程直接塞进容器，希望同时运行数百个会话：

• 谁能调用哪些工具，不再能由“本机用户已经登录”来隐含决定；
• Pod 被替换后，会话和事件历史不能跟着临时磁盘消失；
• 同一会话可能从终端创建，随后由网页、手机或企业协作工具继续；
• 不同用户、Agent、子 Agent 与外部服务之间需要可解释的委派关系；
• 模型、工具和工作区之间的数据流需要被限制、记录和审计。

这就是 CNCF 社区语境与 Agent Harness 开始交汇的原因。云原生长期处理的正是这些问题：可替换计算节点、持久状态、显式接口、身份边界、策略控制、事件记录和独立扩缩容。把桌面 Harness 原封不动装进容器，只改变了部署位置，并没有拆开这些职责。

云原生 Harness 想拆开什么

成员文章给出的核心判断是：Agent 循环应该是一个独立、可版本化、可部署的组件，其他能力通过明确接口放在循环之外。以文中介绍的 Mecatl 为例，核心引擎负责推理循环、工具分发、权限、钩子和事件发射；周围则分成客户端、执行环境、工具生态和支持服务。

这里最重要的并不是“微服务越多越好”，而是责任可以独立变化。例如，模型提供方发生切换，不应迫使客户端重新设计；某个工作节点被替换，不应让已经持久化的会话彻底消失；工具权限发生变化，也不应要求把整套桌面环境重新打包。

为什么一个容器还不够

把桌面式 Harness 打进容器，确实解决了镜像分发和环境一致性，却没有自动解决运行时治理。容器内部如果仍然拥有完整 shell、长期凭据、会话数据库、工具插件和工作目录，那么一个进程被攻破时，影响面依旧覆盖整条链路。

更具体地说，平台团队需要回答的不只是“这个 Pod 能不能启动”，而是下面这些问题：

1. 会话属于谁：用户身份、Agent 身份、子 Agent 身份是否能区分？
2. 工具以谁的权限运行：调用外部系统时，权限来自用户、平台服务账号，还是一次任务授权？
3. 失败恢复到哪里：只能从最近一次持久化边界恢复，还是会误以为可以继续一条正在执行的副作用操作？
4. 工作区如何隔离：一个会话是否可能读取另一个租户的仓库、缓存或临时文件？
5. 凭据如何过期：工具调用是否使用短期、范围受限的授权，还是把长期密钥交给整个进程？
6. 谁能复盘：策略判断、工具调用、人工审批和输出结果是否进入同一条可查询事件链？

这些问题恰好解释了为什么 Harness 会从“模型调用框架”转向“平台控制层”。云原生不是包装形式，而是把故障、权限和状态边界设计成系统的一部分。

先保护哪些资产

按照威胁建模的思路，第一步不是列安全产品，而是先列资产。对云原生 Agent Harness，至少要保护七类对象：用户身份、完整委派链、工作区、工具权限、凭据、提示上下文和审计事件。

这七类资产之间并不是并列关系。用户身份会产生一次或多次委派，委派链决定工具权限；工作区承载待处理数据，凭据让工具触达外部系统；提示上下文与技能会改变 Agent 的行为；审计事件则需要把“谁、在什么会话、凭什么权限、调用了什么工具、造成什么结果”串起来。

如果只给工具调用记日志，却没有身份和委派链，日志只能说明“某个 Agent 做了某件事”，无法回答责任来源。反过来，如果身份很完整，但工作区和凭据共用，租户隔离仍然可能失效。

主要攻击路径与风险分级

云原生 Harness 的风险不只来自模型输出。更现实的攻击路径，是模型、上下文、工具和基础设施之间的组合失误。

风险等级不是行业统一结论，团队应按数据敏感度和工具副作用重新评估。只读文档问答与能修改生产集群的 Agent，不能共用同一套权限默认值。

文中已经实现了什么，又有哪些仍是方向

这篇 CNCF 成员文章对“当前能力”和“未来讨论”做了明确区分。按文中描述，Mecatl 当前展示的架构包括独立核心引擎、多种客户端接口、被分配的执行环境、工具目录、模型与会话等支持服务；其 Kubernetes 运行方式强调工作节点可替换与会话状态持久化。

不过，持久化并不等于分布式事务。文章说明，替换工作节点后只能从最近一次保存成功的回合边界恢复，不会恢复一个正在进行的操作，最后一次保存后的工作也可能丢失。这个限制非常关键：平台不能因为“会话可恢复”就假定外部副作用天然具备 exactly-once 语义。

另外三项被文章明确放在探索或设计阶段：

• 身份：设想使用独立 SPIFFE 信任域，并在 JWT 中编码用户、Agent、会话和多层子 Agent 的委派链。
• MCP 之外的工具数据路径：探索范围受限、可衰减的短期资源授权，让某些工具直接处理工作区数据，不必把全部字节送进模型上下文。
• 上下文证明：把打包提示、技能或上下文视作供应链制品，进行版本化、签名、归属和策略控制。

这些方向与云原生社区熟悉的工作负载身份、能力授权和软件供应链思路相似，但文中明确提醒：设计文档描述的是正在争论的问题，不是已经承诺交付的功能。评估时应以项目当前文档和可运行能力为准。

平台团队可以怎样做一个低风险试点

如果团队已经有多个 Agent 用例，不必第一天就建设一套庞大控制面。更稳妥的做法是选一个低副作用任务，先验证边界是否真的能独立治理。

1. 选只读任务：例如检索内部文档、分析测试失败或生成变更建议，不允许直接修改生产环境。
2. 固定工具目录：只暴露任务需要的工具，默认拒绝 shell、集群管理和任意网络访问。
3. 隔离工作区：每个会话获得独立目录和资源配额，销毁策略清晰。
4. 使用短期凭据：凭据不进入提示词，不写入工作区，不由客户端长期保存。
5. 定义保存边界：明确何时写入会话状态，恢复后哪些动作允许重试，哪些必须人工确认。
6. 关联审计事件：客户端请求、策略决策、工具调用、执行结果和审批记录使用同一会话标识。
7. 做节点替换演练：在无副作用阶段中断执行，确认恢复行为与设计一致，而不是只看 Pod 是否重建。

试点的验收结果不应只是“Agent 完成了任务”。更重要的是：平台能否解释每次工具调用的身份与权限；节点替换后是否在可接受边界恢复；会话结束后凭据、工作区和临时授权是否按预期清理。

哪些团队暂时不需要云原生 Harness

如果 Agent 只在单个开发者电脑上短时运行，所有操作都由用户现场观察，工具权限与本机账户完全一致，那么桌面 Harness 依然可能是成本最低、体验最好的方案。为了“云原生”而拆分服务，会增加部署、协调、可观测性和故障处理成本。

真正出现下面信号时，平台化才更有价值：

• 同一套 Agent 需要服务多个用户或多个租户；
• 任务持续时间超过单个交互进程，必须跨节点保留状态；
• 不同客户端需要连接到同一个会话；
• 工具具备生产写权限，必须实施最小权限与人工审批；
• 合规要求能够追溯身份、上下文版本、策略和工具调用；
• 执行环境需要按任务弹性分配，并在结束后可靠回收。

采用前的安全检查清单

• Agent 循环是否与客户端、工作区、工具和状态存储解耦？
• 是否能区分用户、会话、Agent、子 Agent 和服务身份？
• 每个工具是否有独立权限、资源范围、超时和撤销机制？
• 长期凭据是否可能进入模型上下文、日志或临时文件？
• 工作区、缓存和事件存储是否具备租户隔离？
• 状态恢复边界是否明确，外部写操作是否有幂等或审批保护？
• 技能、提示包和策略是否可版本化、追溯并固定来源？
• 审计事件能否关联到一次完整委派链和具体工具结果？
• 平台是否能在会话结束后回收执行环境与短期授权？
• 团队是否区分了“项目当前能力”和“设计文档中的未来方向”？

怎么看这次讨论

云原生 Agent Harness 的价值，不是把 Agent 贴上 Kubernetes 标签，而是把过去由一个桌面进程隐含承担的责任拆成可治理边界。Agent 的能力越强、运行越久、用户越多，身份、工具、状态、工作区和审计就越不能依赖本地默认值。

CNCF 博客出现这类成员讨论，说明 Agent 平台正在进入云原生社区熟悉的工程问题区：分布式运行、故障恢复、零信任身份、最小权限、供应链和可观测性。它目前更像一项值得验证的架构方向，而不是已经定型的行业标准。对平台团队而言，最实际的下一步不是追逐名词，而是拿自己的会话、工具与权限模型逐项对照，找出哪个边界仍然只靠“进程在自己机器上”维持安全。