为什么我们要做自己的 Harness 框架？

现在做一个 Agent Demo，其实已经不难了。

Vibe coding 很容易让人产生一种错觉：好像自己也能很快搞出一套东西。尤其是看过、用过不少框架之后，这种“我上我也行”的感觉会更强。

你会发现，现成的东西已经很多了。

Claude Code、Codex 这种 Coding Agent，已经把“读代码、改代码、跑命令、跑测试”这条路打通了；LangChain、LangGraph 可以把模型、工具和执行流程串起来；Dify、Agno 能快速搭应用和简单的管理界面；AutoGen、CrewAI 讲多 Agent 协作；再往传统工程看，Airflow、Prefect 跑 DAG，Camunda、Flowable 管流程，Drools 做规则，Temporal 保证长任务执行。

看起来，拼一拼就够了。

要不直接仿一个 Claude Code？

或者给 LangChain 包一层？

再不行给 Dify、Agno 换个前端？

甚至给 Airflow 这种 DAG 加点 LLM 判断逻辑？

感觉随便组合一下，就能“自研一个 Agent 框架”。

但这其实是个错觉。

一旦真的进到企业业务里，很快就会发现：能把 Agent 跑起来，和能让它长期稳定跑，而且和人的意图对齐，完全是两回事。

我们要做自己的 Harness，不是因为框架不够多，也不是想再造一个 LangChain 或 Dify。

核心原因其实很简单。

第一，业务需要一套统一的抽象。

企业里的 AI 场景不会一直停留在问答。今天是知识库问答，明天可能是代码审查，后天是客服分诊，再往后就是调用内部系统、写文件、开工单、改数据的复杂 Agent。

如果每个场景都用不同的框架、不同的状态管理、不同的工具接入方式，短期开发是快，但很快就会变成一堆难维护、难复用的脚本。

所以必须有一层统一的东西。

比如：Agent 怎么定义，Skill 怎么拆，Tool 怎么接，Session 怎么跑，Context 怎么组织，Memory 怎么用，Workspace 怎么存，Trace 怎么看，Output 怎么验。

这些统一下来，不是为了好看，而是为了让不同业务能用同一套运行逻辑。

第二，是成本问题，本质是 Token 效率。

接上模型只是开始，规模一上来，问题马上变成：请求怎么分发，模型怎么选，哪些内容该进 Context，哪些该进 Memory，哪些可以 Cache，工具结果怎么压缩，历史怎么复用。

这些都直接影响成本。

Context 越长，钱越多，延迟也越高，还更容易引入噪音。Cache 也不是随便开，它要求你清楚哪些内容是稳定的、可复用的，哪些会干扰当前任务。

企业不能只停在“能调模型”。每一次调用，都应该是可解释、可衡量、可优化的。

第三，是从 Demo 到真正可用。

企业其实不缺能演示的 Agent，缺的是能上线、能复现、能回放、能验收、出问题能追的 Agent。

一旦进到真实业务，Agent 就不能只是个聪明的聊天框了。

它要知道目标是什么，边界在哪，哪些事情可以自己做，哪些必须人工确认，调用工具会不会有副作用，结果怎么验收，过程怎么记录，失败了怎么恢复。

这些不解决，Agent 很难真正成为系统的一部分。

所以我们做 Harness，并不是要替代现有框架。

底层模型可以接各种，执行可以用 LangGraph，工具、规则、长任务也都可以复用现有能力。

但在这些之上，需要一层统一的语义：Agent、Skill、Tool、Context、Memory、Cache、Workspace、Trace、Output、Cost。

这就是我们要做 Harness 的原因。

不是为了再造一个更大的框架，而是因为企业级 Agent 真正缺的，不是一个能跑 Demo 的工具，而是一层能把业务、成本和运行都兜住的基础设施。