AI时代的「管理学」:什么是"Harness Engineering 驾驭工程"?AI时代的产品经理手册

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

8分钟 ·
播放数89
·
评论数0

大家好,欢迎收听《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 时代的管理,本质上没有变。


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