一个做了六年 Kubernetes 的运维老兵，第一次认真看懂 Agent Harness 时的直觉。 写下来，既是复盘，也是想验证这个判断到底对不对。
我做了六年 Kubernetes。从手写 YAML、调调度器、处理节点故障、背排障手册，到后来看着团队把集群一步步"平台化"------把基础设施的复杂度包起来，让应用团队只写业务代码。
最近我开始认真研究 Agent Harness。脑子里突然冒出一个直觉：
K8s 和 Agent Harness，本质上是一回事------都是把工程化的复杂度抽离出来，让开发者专心写业务。
这个直觉对不对？我写下来，逐层拆开看。
一、先说我的结论
方向是对的，但可以更精确一点。
"把工程化抽离出来"这个表述，我做了六年之后回头看，觉得还不够锋利。更准确的表述应该是：
两者都在做同一件事：把"运行时（Runtime）"和"领域（Domain）"分离。
- K8s 抽离的是计算/网络/存储的运行时 ，让开发者只关心应用本身。
- Agent Harness 抽离的是模型执行/工具/状态/权限的运行时 ，让开发者只关心业务逻辑和任务目标。
这句话是我真正想说的。下面展开。
二、K8s 抽离了什么？
六年前我入行，K8s 最打动我的不是"容器编排"，而是它的抽象分层。它把一堆分布式系统里最难搞的工程问题，全部下沉到了平台层：
| K8s 解决 | 开发者不再操心 |
|---|---|
| 调度（Scheduler） | 我的 Pod 该跑在哪台机器 |
| 健康检查 / 自愈（Probe / ReplicaSet） | 节点挂了谁来拉起我 |
| 服务发现 / 负载均衡（Service / Ingress） | 别的服务怎么找到我 |
| 配置与密钥（ConfigMap / Secret） | 配置放哪、密码怎么不泄露 |
| 滚动更新 / 回滚（Deployment） | 怎么发布不中断 |
| 弹性伸缩（HPA / VPA） | 流量涨了怎么办 |
注意一个关键点：K8s 从来没有让开发者"不用懂"这些。 它只是把这些从"每个应用团队都要手写一遍的重复劳动"，变成了"平台统一提供、一次搞定"的能力。开发者依然要理解 Pod、Service、Ingress 的概念，但不需要再为每个服务单独实现一套。
这就是平台化的本质：把共性的、非业务的东西抽成平台能力，把差异化的、业务的东西留给开发者。
三、Agent Harness 抽离了什么？
我第一次看到 Agent Harness 这个词是在研究 ByteDance 的 DeerFlow 2.0。它对自己的定位不是"框架"，而是 SuperAgent Harness ------一个让 agent 真正干活、而不是只会聊天的运行时环境 citation:GitHub - bytedance/deer-flow。
这个定位让我瞬间联想到 K8s。因为 Harness 解决的，正是 agent 系统里那些"跟业务无关，但每做一个 agent 都要重复踩一遍"的工程问题。
业内对 Agent Harness 的定义高度一致：它是包在模型外面、负责执行的那一层运行时。一个经典的表述是：
Agent = Model + Harness
模型只是其中一个输入；而 Harness------工具、上下文、钩子、子代理、沙箱、记忆、权限门、校验器------才是绝大部分工程工作所在 citation:Agent harness engineering: the new discipline, decoded。
拆开看，Harness 抽离的东西和 K8s 惊人地对应：
| Agent Harness 解决 | 开发者不再操心 |
|---|---|
| 上下文管理（Context Management） | 怎么把相关材料塞进有限的上下文窗口 |
| 工具执行 / 工具循环（Tool Loop） | 模型怎么调用外部工具、怎么处理结果 |
| 状态持久化（State / Session Persistence） | agent 跨轮次、跨失败怎么记住进展 |
| 沙箱隔离（Sandbox） | agent 执行代码/命令时怎么保证安全 |
| 权限门（Permission Gates） | 哪些操作允许、哪些要人审批 |
| 生命周期钩子（Lifecycle Hooks） | 开始/结束/失败时怎么挂钩子处理 |
| 子代理编排（Sub-agents） | 复杂任务怎么拆解、怎么委派 |
| 记忆（Memory） | 长期信息怎么存、怎么检索 |
看到没？每一行都是"工程化"的活，没有一行是"业务"。 就像 K8s 的调度器不是业务、健康检查不是业务一样。
四、DeerFlow 的分层：App 层 vs Harness 层
DeerFlow 2.0 的架构特别能说明问题。它采用两层后端架构 ，把核心 agent 运行时/编排引擎，与应用特定的交付/集成层解耦 citation:Harness vs App Layer | bytedance/deer-flow | DeepWiki。
这就是"运行时 vs 领域"分离的教科书式落地：
- Harness 层：通用能力------沙箱、记忆、工具、技能、子代理、消息网关。跟"你做什么任务"无关。
- App 层：具体业务------研究、写代码、做 PPT、生成网页、生成图片、生成视频。这些是"领域"。
DeerFlow 里，技能（Skills）不是一次性全部加载进上下文，而是按需拉取 。这跟 Anthropic 的 Agent Skills 是同一个架构决策：技能是文件系统，不是系统提示词 citation:DeerFlow 2.0: ByteDance's 68k-Star... -- Till Freitag。
这个设计，本质上和 K8s 的"平台能力按需提供、开发者按需使用"是同一个哲学。
五、一个关键的分歧点：为什么"抽离"不完全等于 K8s
这里我要诚实地指出一个差异，避免把类比说得太满。
K8s 和 Harness 有一个本质区别：K8s 的"运行时"是确定的、可预测的；Harness 的"运行时"里有一个不确定的模型。
- K8s 里，调度器把 Pod 放到哪台节点，是确定性算法决定的。开发者可以预测、可以测试、可以复现。
- Agent Harness 里，模型下一步会调用什么工具、会怎么理解上下文，是概率性的。你无法完全预测。
所以"抽离工程化"这件事，在 K8s 里是把确定性的复杂度封装起来 ；在 Harness 里是把不确定性的风险兜住。
这带来一个结果：Harness 的"工程化"比 K8s 更难做，也更重要。 因为一个坏 Harness 会把好模型的潜力浪费掉，而一个好 Harness 能让普通模型发挥出超常水平。业内那句话说得很好：
一个平庸的模型配上优秀的 Harness，往往能稳定胜过优秀的模型配上糟糕的 Harness。 citation:Agent Harness Engineering --- Media Summary · GitHub
这句话，做 K8s 的人应该特别有共鸣------因为 K8s 也一直是"平台能力决定应用质量"，而不是"单个组件决定整体"。
六、那我的感悟到底对不对？
回到开头那个问题。
"都是把工程化抽离出来，让开发者专心写业务"------这个直觉是对的，而且是做 K8s 多年的人才能有的直觉。 因为只有真正被"工程化的复杂度"折磨过的人，才能一眼认出另一套系统里同样存在的"工程化复杂度"。
但如果要我把它打磨得更锋利，我会改成：
K8s 和 Agent Harness，都是把"运行时"与"领域"分离。前者分离的是确定性的基础设施运行时，后者分离的是不确定的模型执行运行时。目标一致：把工程化的复杂度下沉到平台层，让开发者专注业务本身。
这个表述，既保留了你的直觉，又点出了两者的关键差异。
七、做 K8s 的人，做 Agent 有什么优势？
最后说点实际的。如果你和我一样是 K8s 背景，转去做 agent 系统，我觉得有三块认知是直接可迁移的：
-
平台化思维：你会天然倾向于"把共性的东西做成平台能力"，而不是每个 agent 项目都从零手搓一套工具执行、状态管理、权限控制。这正是 Harness 的价值所在。
-
关注运行时而非模型：K8s 教会我们"单个组件不是全部，系统能力才是"。Agent 领域同样如此------模型只是输入，Harness 才是工程。你不会把注意力全放在"换更强的模型"上，而会去优化工具、上下文、钩子、沙箱。
-
对"确定性 vs 不确定性"的敏感 ：K8s 让你习惯了可预测的系统。到了 Agent 世界，你会比纯算法背景的人更早意识到：不确定性需要靠工程手段（沙箱、权限门、校验器、回滚路径）来兜底，而不是靠模型自己"自觉"。这是 K8s 的"自愈"思想在 agent 世界的延伸。
八、结语
六年 K8s，我最大的收获不是会调集群，而是学会了一种看系统的眼光：永远问一句------"这里哪些是共性的工程问题，哪些是真正的业务问题？"
看 Agent Harness 的时候，这个眼光自动就冒出来了。它让我一眼认出：Harness 就是 agent 世界的 K8s，K8s 就是基础设施世界的 Harness。
它们都在做同一件事：把复杂留给平台，把简单留给开发者。
这个感悟，我觉得是对的。你呢？
如果你也做过 K8s，现在在研究 agent 系统，欢迎聊聊你的感受。我特别想验证：这个"运行时 vs 领域"的视角，是不是你们也有共鸣。