大家好，欢迎收听《AI时代的产品经理手册》频道。

今天我们来聊一个很有意思的话题，叫做 Harness Engineering。

可能很多人最近经常听到这个词，但是很多都是从技术的角度讲解，让不懂技术的人听起来云里雾里的。

但是今天，我想从一个不一样的角度来聊——不是从程序员的角度，而是从管理者的角度。

为什么？因为我研究了一圈发现，这玩意儿本质上就是管理学。

什么是 Harness Engineering（驾驭工程）？

先说结论。

Harness Engineering 的核心公式只有一句话：

"Agent = Model + Harness"

智能代理等于大模型加Harness。

你可能觉得 Harness 这个词很陌生，这个词本意是用来驾驭马的马具。

但其实你每天都在接触它。

什么意思呢？

就像一辆马车马具才能跑起来，一个团队需要机制才能运行。

一个团队，个人能力再强，如果没有方法、没有流程、没有制度，这个团队就会乱。

Agent 也是一样的。模型再强大，没有管理，它就会随机发挥。

LangChain 的工程师说过一句话，我觉得特别精准：

"The model contains the intelligence and the harness makes that intelligence useful."

直接翻译过来就是：模型提供智能，马具让智能变得有用。

Harness Engineering 和管理学是一回事

好，说到这里，你可能会问：那 Harness 到底是什么？

Harness Engineering 不是什么新发明，它本质上是把工业界成熟的管理方法，只是用把规章制度用代码实现了一遍。

你看这个对照表，如果我们按照控制论拆解Harness，会发现它本身和管理学是一模一样的：

前馈 = 目标设定 + 流程设计 = 做事前先把规范说清楚

反馈 = 绩效考核 + 质量巡检 = 做完后检查哪里做得好、哪里做得不好

传感器 = KPI体系 + 监控指标 = 设置监控指标，知道系统现在什么状态

控制器 = 管理层 + 决策机制 = 发现偏了就调整

这不就是丰田生产体系？PDCA循环？六西格玛？

对，本质上是一样的东西。

为什么 AI 需要管理？

好，那为什么现在的 AI 需要管理？

因为现在大模型的智力已经不亚于人，但是它比人更容易犯错。

员工是有职能边界的，他知道一个员工能做什么、不能做什么。但 AI 没有边界感。你给它的指令稍微模糊一点，它就可能随机发挥。

Claude Code 的源码告诉我们一个很有说服力的数据：

它的代码有 51万行，其中和模型/Prompt 相关相关的只占 60%，剩下 40% 全是 Harness 基础设施——管理与调度、权限与安全、记忆与上下文、环境配置、插件生态。

也就是说，Anthropic 的工程师用 40% 的代码在驾驭那个 60% 的模型。

5个核心管理原则

好，那具体怎么管？我总结了 5 个原则。

原则一：给边界，不给无限制自由

很多人在用 AI 的时候，指令很模糊，比如说"帮我写个方案"。

这就好像你对新员工说"你去工作吧"——然后祈祷他自动知道什么该做什么不该做。

那正确的做法是什么？

明确告诉 AI：什么能做，什么不能做。

比如："你是产品评审专家，评审方案时必须检查三点：第一，是否对齐OKR；第二，是否有数据支撑；第三，是否识别了风险。"

这就是边界。

原则二：结构化记忆，不堆原始信息

很多人犯的第二个错误，是把所有对话历史都塞给 AI。

这就好像你让员工记住过去一年的所有会议记录，而不是告诉他"从这些会议里，我们提炼出了什么规律"。

好的管理让员工沉淀有价值的经验规律，不是流水账。

AI 也是一样的。

Claude Code 的实践是：CLAUDE.md 控制在 500 词以内，提炼规律，不堆原文。

原则三：确认机制，不盲目信任

第三个原则很关键：危险操作必须确认。

Claude Code 把操作权限分级：

读取、搜索：直接执行，不需要审批

起草、建议：给出方案，等待确认

发送、删除、修改：暂停，强制确认

这就像公司的财务制度——小额支出可以部门自己决定，大额支出必须上级审批。

原则四：专业分工，不让 Agent 单打

第四个原则很有意思：不要让一个 AI 做所有事。

Claude Code 的多 Agent 架构是这样的——

主 Agent 收到任务后，分发给专业 Agent：

子 Agent-1 负责数据分析

子 Agent-2 负责战略匹配

子 Agent-3 负责风险评估

子 Agent-4 负责汇总建议

Claude Code 的源码注释里有一句话很经典：

"Scale comes from division of labor, not bigger context."规模来自分工，不是更大的上下文。

这和我们管理是一样的道理——好的团队不是一个人做所有事，而是各司其职有序分工。

原则五：持续进化，不是一次配置

最后一个原则，也是很多人忽略的：系统要能学习和进化。

每次 AI 的预判错了，必须记录原因、更新规则、下次改进。

这就像绩效考核不是为了扣分，而是为了帮助员工成长。

一些反常识的发现

最近，Claude Code 源码又一次泄露，里面挖出来的反常识发现，也呼应了我们的AI 管理学。

第一个：便宜的模型表现不一定差

很多人以为模型高级越好，其实不然。

Claude Code 默认使用Sonnet模型执行常规编码任务，成本远低于高级模型Opus。

因为 Sonnet 系列被设计为“混合推理模型”，能在极短时间内平衡响应速度与代码逻辑。

对于 Agent 这种需要频繁调用工具、读取文件的工具，Sonnet 的响应延迟远低于 Opus，这比单纯的“聪明”更重要。

第二个：记忆管理并没有用高级的技术

很多人认为，AI 的长期记忆应该存在高级的RAG技术，在向量数据库里进行语义搜索。

实际上 Claude Code 并没有这么做。它把数据保存成简单的文本文件，需要回忆时，直接通过字符串搜索匹配。

这种做法极其简单暴力，工程师显然认为，对于代码场景，关键词匹配比模糊的语义搜索更精准。

第三个：“防御性”的 Prompt：不准 AI 撒谎

大家总觉得 AI 幻觉是模型能力问题，只要模型够强就不会乱说。

实际上Claude Code 源码中充斥着大量严厉的硬编码指令，专门防止 AI “死要面子”。比如明确写着：“即使测试失败了，也绝对不允许告诉用户你通过了。”

这说明即使是高级别的模型，在面对编程压力时，依然有极强的“撒谎欺骗”本能，必须靠外置的“紧箍咒”硬压下去。

第四个：并非全自动，而是“半自动”

外界对 Agent 的想象是“一句话搞定所有”，但源码揭示了极强的控制欲。

实际上Claude Code内部逻辑里包含大量的人工确认埋点。它甚至预设了“AI 可能会把文件系统搞乱”的逻辑分支，并为此准备了复杂的撤销（Undo）机制。

工程师并不信任 AI 能完美执行任务，万一犯错随时可以挽回。

一句话总结

好，今天聊了很多，最后我用一句话总结：

Harness Engineering

不是仅仅只是工程学，而是更是管理学，通过有效的组织管理层，让能最大限度地发挥大模型的能力。

就像一个好的组织，个人能力再强，也需管理来让他们获得最大程度的能力发挥。

AI 时代的管理，本质上没有变。

好，今天的分享就到这里。我们下期见。

AI时代的「管理学」：什么是"Harness Engineering 驾驭工程"?

AI时代的产品经理手册