Agent Harness 不是要安装的软件包-IT资源栈

做生产级 Agent，很多人第一反应是挑一个框架、看一眼文档、运行一下 Hello World，然后觉得大事已定。

Mike Piccolo 的文章 How to Build Your Own Agent Harness 直接拆穿了这个幻觉。他的核心论点只有一句话：Harness 不是你要安装的软件包，而是你的系统为了让 Agent 跑得久、跑得稳、出了问题查得清，必须一件件做完的工作集合。

原视频：

框架的陷阱

选框架最大的风险，在于框架把所有职责打包进了一个 Monolith。

Policy 引擎、审批逻辑、凭证管理，全都耦合在一起。等你跑到生产上，发现自带的 Policy 引擎不合需求，往往就得重写整个 Harness，不是换掉其中一个组件的事。

控制权就这样悄悄锁死了。

Mike 把一个生产级 Harness 应该承担的责任列成了 15 项：

接收 Turn → 解析凭证 → 查模型能力 → 跑状态机 → 加载 Skill → Pin System Prompt → 流式推理 Token → Policy 检查 → 人工审批 → 预算追踪 → Hook 分支 → Session 上下文压缩 → 事件流 → 分布式 Tracing

每一项都是独立边界。重点在”独立”——换 Policy 引擎不动 Tracing，换模型供应商不动审批逻辑。表格里每一行是一个可以随时换掉的单元。

学术界的 ETCLOVG 七层（执行、工具、上下文、生命周期、可观测、验证、治理）说的是同一套东西，只是更偏架构视角。两者合着看比单独看任何一个都清楚。

Mike 给了一个具体的 Turn 执行路径：

Durable 状态机是关键。一根调用栈挂了就什么都找不回来；Durable 状态机把”Turn 在哪一步”变成持久状态，随时可查、可恢复。

从 Turn 入口就注入 Trace，整个执行轨迹从第一毫秒起就是可观测的，不用事后拼凑。

过去工程师争论 Thin Loop 还是 Thick Agent——Thin 指 Harness 尽量薄、把更多工作留给模型；Thick 指 Harness 承担更多编排、更多检查。

Mike 说这个争论本身是假的。

从 Thin 到 Thick，只是在 Config 里增减 Worker。Wire Protocol 不变，Trace 形状不变。

框架替你锁死了这个 Slider，把它变成了一个产品决策。如果用自建 Harness，这个 Slider 在你手里。需要更严格的 Policy 检查就加 Worker，不需要就去掉，对整体结构没有影响。

这才是可替换性的意思——不是”组件理论上能换”，是”换的时候你不需要拆掉整个系统”。

Mike 最后给了一份不依赖具体框架的行动清单：

它不绑定任何框架，也不要求现在就把 15 项全做完。它只是告诉你哪些地方如果一开始设计错了，后来改的代价最高。

我们已有的 Langfuse 部署对应的是 ETCLOVG 里的 O 层（可观测性）。相对薄弱的是 G 层（治理）里的 Policy 检查和预算追踪——这两项在测试环境里缺失通常无感，但在生产环境里每次 Turn 跑起来都是在消耗没有上限的资源。

Thin vs Thick 的连续谱视角对我们有直接意义：现在用 Claude Code 和 Hermes Skill 的架构，已经是在 Thin 一端；往 Thick 方向移动不需要换底层，只需要在 Config 里加 Worker——比如加一个预算检查 Worker，或者加一个人工审批节点。

Harness 不是包，是工作清单。每项工作由谁来干，你说了算。