Harness Engineering：一个非专业人士的不负责任追问
欢迎使用 dotBlog
Harness Engineering：一个非专业人士的不负责任追问
事情的起点很简单——我最近在捣鼓一个 Agent。
用 OpenClaw 精准完成任务，说实话，太难了。于是我换了个思路：与其给 Agent 完全的自由，不如给它划一个圈。它一出圈，我就把它赶回来返工；它让我满意了，才进入下一步。
恰好 OpenAI 那段时间大放送，Codex 用量双倍，我就用这套逻辑做了一个小玩意：我来选题，Agent 去 Reddit 搜信息，然后写一篇文章。案例文章可以参考：
Sora 关停背后：OpenAI 的视频梦碎，还是 AI 泡沫折返点的到来？0 赞同 · 0 评论
做完之后，虚荣心作祟，我把代码甩给 Claude 问了一句：这算不算 Harness Agent？
Claude 说，基本算。原因如下：
- 控制权完全在框架层
- 质量门由框架执行，不是 Agent 自评
- GoalManager / ResearchPlan 完全在框架层
但也有不符合的地方：
- Agent 拥有工具调用权
- SEARCH 阶段 Agent 自决搜索策略
- 没有 Agent-to-Agent 的显式编排
它还顺带给我科普了一下：什么是 Harness Agent？
Harness Agent 的核心特征是：Agent 本身不直接执行业务逻辑，而是作为”控制框架”协调其他组件；外部循环驱动，由非 Agent 的代码控制状态推进、重试、分支决策；Agent 只做局部推理，每次调用只负责一个具体的子任务；框架层可以审查 Agent 输出、拒绝结果、注入反馈。
读到这里，你有没有觉得哪里不对劲？
我在读 Hello-Agents 做读书笔记的时候，有过一个感受：Agent 的产生，本质上是因为 LLM 的能力提升跨过了某个阈值——这是 Agent 区别于 N8N 那类 workflow 工具的核心。Agent 之所以是 Agent，是因为它能自主判断，而不只是执行预定义的流程。
但 Harness 告诉我什么？——用框架，让 Agent 只做局部推理。
按这个标准，Harness Agent 本质上更像是“LLM 作为工具的自动化流水线”，而不是真正意义上的 Agent。
当然，你可以反问我：OpenClaw 大火，你认为它是真正的 Autonomous Agent 吗？
它内部有大量编排框架在限制边界，而且随着每次更新，控制和约束只增不减。我真正上手用的时候，发现它也无法独立完成一个边界模糊的复杂任务。
作为制造业人士，我再想一个类比：流水线工人。他的工序顺序是固定的，但他在每道工序上仍然有判断力。我们会说他有自主性吗？——工序内有，工序间没有。
如果把 Agent 比作工人，Harness 就是给它安排好的工序间隔。工序内的聪明劲儿是真实的，但谁来决定”下一道工序是什么”——不是它。
所以 Harness Engineering 的真实性质是什么？
它不是一个关于 Agent 的理论，而是一个关于当前 LLM 局限性的工程补偿方案。
它隐含的世界观很清晰：
LLM 的自主判断现在不可靠，所以用确定性的框架来替代它不可靠的部分，然后等待模型能力提升到框架可以被拆除的那一天。
这并不是凭空假设。当前 LLM 在完全自主运行时的真实表现，任何用过的人都多少有数：
- 目标漂移：长任务中容易忘记原始目标，被中间产物带偏
- 自我欺骗：倾向于认为自己已经完成，而不是承认不足
- 无法感知循环：不知道自己在原地打转，除非被显式告知
- 幻觉累积：每一步的小偏差，在多步之后会指数级放大
所以 Harness 的逻辑是：把 LLM 的不确定性视为需要被管理的风险，而不是需要被发挥的能力。
如果你期待的是”让 LLM 完全自主运行”，那 Harness 确实是一种倒退。但如果你期待的是”让 LLM 可靠地完成事情”，那它又是目前最诚实的答案。
到这里，我产生了一个有趣的想法，不保证正确，但值得说出来：
OpenAI 和 Anthropic 在用行动投票——他们并不认为当前乃至近期的 LLM 可以胜任真正的 Autonomous Agent。
而且，这个选择对他们来说，结构性利益完全一致：
如果 LLM 可以完全自主地完成复杂任务，用户只需要一个模型就够了。但如果复杂任务需要框架、编排、工具链、guardrails，那么：
- Anthropic 卖 API + Claude
- OpenAI 卖 API + Assistants + Agents SDK
- 整个生态需要框架工程师、咨询、平台、middleware
Harness 思路客观上扩大了市场，把”让 LLM 做事”变成了一个需要持续工程投入的领域。
这不一定是阴谋。但结构性的利益一致，本身就值得被注意。
当然，我还有几个更阴暗的猜测——或者说，更”非专业”的猜测：
一、安全与控制的政治需求
Anthropic 尤其明显。他们的核心叙事是 AI Safety，而 Harness 天然契合这个叙事：一个被框架约束的 LLM，比一个自主运行的 LLM，显然更容易被监管、被审计、被解释。你不能说这是错的，但你也不能说这跟他们的品牌定位完全无关。
二、掩盖模型真实的能力边界
当前顶级模型在真正自主运行时，长链条任务的失败率仍然相当高。如果让模型完全自主，失败会非常显眼。但 Harness 的效果是：把模型的失败转化为框架的重试，把不可靠变成了可管理。用户看到的不是模型失败，而是系统在处理异常。这是一种很聪明的体验设计，但也顺手模糊了能力的真实边界。
三、路径依赖的合理化
软件工程几十年积累下来的最佳实践——状态机、事务、幂等性、可观测性——都天然指向 Harness 模式。换句话说，做过传统软件工程的人，看到 LLM 的第一反应就是”这个东西需要被管理”。这不一定是错的，但它可能是一种把惯性包装成方法论的过程。
以上全是非专业人士的不负责任推测，不构成任何严肃意见。
但有一个问题我觉得值得认真回答：
Harness 的本质究竟是什么？
是当前时代最诚实的工程解法？是对 Autonomous Agent 理想的阶段性妥协？还是一套客观上有利于平台方、同时也确实解决了真实问题的方法论？
也许都是。而这本身，就是它最耐人寻味的地方。
你怎么看？