"Harness Engineering"这个词可能弊大于利。Agent = Model + Harness 这个框架，低估了构建真实 Agent 产品所需的工程量。Claude、ChatGPT、Devin 这些产品都不是这个模式——它们都是系统，处理身份认证、多租户、部署、可观测性、成本控制、会话状态管理、RBAC、资源隔离。Harness 只是系统工程的一个子集。

更好的框架是 Agent = Model + System。你不能把原始 API 调用直接暴露给用户，必须有完整的系统把模型转化成一个产品。

Coding Agent 的模式是特定形态的产物

Harness 模式是由 Coding Agent 这类具体形态塑造的：单一用户、在终端里运行、访问本地文件系统。这些模式对这个形态有效。把它泛化到更宽泛的 Agent 系统，可能对整个生态有害。

文件系统做记忆层：在一个人在自己笔记本上跑一个 Agent 的场景下有效，做真实产品时全面崩溃。数据库天然支持并发访问、查询、访问控制，文件系统不支持。现在有人构建"虚拟化文件系统"用数据库模拟文件系统——到这个地步，为什么不直接暴露数据库？

没有多租户和 RBAC：50 个工程师如何安全共享一个 Agent？如何控制哪些用户能触发哪些操作？这些是 RBAC 和授权问题，没有任何文件系统模式能解决。

没有资源隔离：如何阻止一个租户的失控 Agent 烧穿整个 Token 预算？这些是系统层面的资源隔离问题，Harness 层根本不存在这个概念。