看到一篇关于 Harness 的长文，讲 AI Agent 的 7 大组件。文章用了一个特别贴切的比喻——组织一次家庭聚餐，来解释为什么光有大模型不够，还需要一套工作系统。

这个比喻很妙。你请了一个很聪明的私人助理帮你安排聚餐，它思考能力很强，但如果没有一套工具、规则和信息系统，它最多只能给建议，不能真正把事办成。

LLM 是聪明的大脑。Harness 是让这个大脑能干活的工作系统。

这句话我特别认同。现在做 AI Agent 的很多人还停留在一个很浅的理解里——给大模型写一段提示词，让它回答问题、生成内容、调用工具。但只要真的做过 Agent 落地，就会发现 Prompt 只是开始。

难的是另一堆问题：它该用哪个模型？能调用哪些工具？从哪里拿业务知识？怎么防止越权、乱说、乱操作？出错以后又怎么定位？

7 个组件，每一个都不简单

这篇文章把 Harness 拆成 7 个组件，每个组件都用"家庭聚餐"和"文章 Agent"两个场景来解释，非常清晰。

模型网关——不是什么任务都要用最贵的模型。该用好模型的地方不要省，该用便宜模型的地方不要浪费，能用规则解决的就别麻烦大模型。

工具注册表——告诉 Agent 有哪些"手脚"可以用，每个工具需要什么参数，调用失败怎么办。它只回答"有没有这个工具"，不回答"该不该调用"。

知识库引擎——Agent 不能只靠大模型的通用知识工作。它要懂你的业务、你的历史、你的观点体系。知识库是你的"判断力缓存"。

记忆系统——不是记得越多越好。记太少，Agent 没有连续性。记太多，上下文会污染，成本会飙升。产品经理真正要设计的是：记什么、记多久、什么时候压缩或者忘掉。

策略引擎——把规则和红线变成强制约束。Agent 不能"看情况发挥"。策略引擎的作用不是让 Agent 更会干，而是让 Agent 不越界。

可观测性——没有可观测性，就没有 Agent 运营。你都不知道它哪里好、哪里坏、哪里浪费成本、哪里反复出错。

配置管理——让 Agent 可以持续调教。今天改选题标准、明天调标题风格，不能每次都找开发发版。

最有价值的观点

整篇文章最让我有感触的，是最后那段话——

大模型解决的是智能问题。Harness 解决的是交付问题。

传统产品经理交付的是功能。AI 产品经理交付的是效果。

这两句话点透了 AI 产品的本质。

我们这一代人经历过移动互联网时代，那时候的好产品标准是"功能完整、体验流畅"。但在 AI 时代，好产品的标准变成了"效果可预期、交付可信赖"。

用户不在乎你的 Agent 用了什么模型、搭了多少组件、写了多复杂的策略。用户只在乎一件事——这件事你能不能帮我办成。

我的看法

这篇文章的价值在于，它不是从技术架构的角度讲 Harness，而是从产品经理的视角讲——每个组件解决什么业务问题、产品设计时需要注意什么陷阱。

比如讲记忆系统时，作者不说"用向量数据库存上下文"，而是说"产品经理真正要设计的是：记什么、记多久、什么时候压缩或者忘掉"。这才是产品经理该想的问题。

再比如讲策略引擎时，作者不说"用 RBAC 控制权限"，而是说"Agent 不能看情况发挥"。这句话比任何技术方案都更直击要害。

未来有价值的 Agent，不是会聊天的 Agent，而是能在具体业务里稳定交付结果的 Agent。写文章是这样，做企业 AI 落地，也是这样。

大模型解决智能问题，Harness 解决交付问题。这句话，值得所有做 AI 产品的人记在脑子里。