#Harness Engineering：真正拉开差距的，不是功能数量，而是工作秩序
平台：X 长文 目的：建立权威 标签：
#AI#Agent#工程#HarnessEngineering
---
#01 你的AI系统，正在悄悄崩溃
我上个月用AI跑一个复杂任务。
跑了47轮，最后一步报错。从头再来。
不是模型不够聪明。GPT-4o、Claude 3.5、Gemini 1.5，我都试过。结果一样——任务一长，系统就脆。
那一刻我才意识到：过去两年，整个行业都搞错了方向。
我们把所有注意力都放在模型能力上：推理更强了、上下文更长了、多模态来了。每隔几个月就有一次"这次不一样"的发布会。
但没人告诉你——
大多数AI系统，根本撑不过10轮对话。
不是模型不行。是系统从来没有被设计成能长期工作的样子。
---
#02 一个被低估的行业共识正在形成
最近几个月，OpenAI、Anthropic、LangChain在各自的技术博客里，开始密集讨论同一件事。
它有一个名字：Harness Engineering。
不是prompt工程。不是模型微调。不是RAG。
是给智能体系统搭建一套能让它长期工作、自我检查、保留状态、从错误中恢复的工程框架。
这件事，现在是AI基础设施里最被低估的方向。
---
#03 你把AI当工具，它把你当一次性用户
让我解释一下为什么大多数AI系统现在的状态是脆的。
当你调用一个AI完成任务，它的默认模式是：
接收输入 → 生成输出 → 结束。
这对短任务够用。写一段文案，翻译一段话——没问题。
但当任务变长、变复杂，这个模式开始暴露致命缺陷：
状态靠模型记忆。 任务做到一半，上下文满了，或者会话中断了，之前的进度没有任何外部记录，等于消失了。
没有强制验证。 AI说"完成了"，但有没有真的完成？系统不知道，因为没有检查机制。
无法从错误恢复。 出错了只能重来。没有检查点，没有回滚，没有"从第三步继续"。
环境对AI不透明。 智能体不知道自己在做什么项目的哪个部分，不知道约束是什么。每次启动都像第一天上班但没有人交接。
这四个问题加在一起，造成了一个现象：
AI很聪明，但系统很脆。
---
#04 三家公司，三种解法，一个答案
有意思的是，OpenAI、Anthropic、LangChain虽然切角不同，但都在收敛到同一个答案。
OpenAI：agent legibility（智能体可读性）
他们提出的核心工具是 AGENTS.md —— 一个放在项目根目录的文件，把整个系统的结构、规则、知识索引都写进去。
背后的设计哲学是：不要让智能体去猜环境，要让环境对智能体清晰可读。
这是一个认知翻转。以前我们调优AI的方式是"把prompt写得更好"。OpenAI现在在说的是：把环境本身设计得对AI更友好。
Anthropic：长任务连续性
他们的解法是显式进度工件：progress文件、feature list、阶段检查点。
不靠模型"记住"做了什么，而是把任务状态写进文件。任务中断了？读文件，接着干。
Anthropic的底层逻辑是：模型记忆是不可靠的基础设施，文件系统是可靠的。
LangChain：把 harness 当成可优化的系统
他们通过trace（追踪记录）找失败模式——定位哪个环节最容易断、最容易出错，然后系统性地修复。
LangChain的视角是：一个AI系统，和一个分布式软件系统没有本质区别。 你需要可观测性，需要日志，需要定位失败根因的能力。
---
#05 四个核心问题，这是完整的框架
把三家公司的实践提炼出来，Harness Engineering 要解决的是四个系统级问题：
任务持续推进
从"单次响应"变成"持续流程"。系统需要支持任务分解、阶段推进、中断恢复。
状态外部化
进度、约束、已完成项，存到文件里，而不是依赖模型记忆。做到了这一点，系统从"易碎"变成"可恢复"。
验证默认化
验证不是可选项，是系统流程的强制环节。在agent宣布"完成"之前，必须有守卫机制来检验。
环境可读性
让智能体能稳定获取关键上下文——项目结构、历史决策、当前约束、任务边界。
四个问题，一个方向：让AI系统能长期工作，而不只是当场表演。
---
#06 落地到实践，是六件具体的事
建立标准状态工件
|文件|用途|
|---|---|
|TASK.md|记录当前任务定义|
|PLAN.md|记录执行计划|
|PROGRESS.json|记录当前进度|
|CHECKS.json|记录验证结果|
|HANDOFF.md|记录交接上下文|
这套文件体系，就是系统的"脊椎"。
验证环节前置为系统守卫
不允许agent在没有通过验证的情况下宣布完成。验收标准在任务开始前就定义好，完成后由独立环节检查。
知识沉淀做成 agent-first 结构
文档的组织方式，要让AI能自己找到需要的信息，而不是让人类去翻、再转述给AI。
用 hooks 和 background tasks 承担长期治理
自动检查、自动扫描、自动整理，把治理做成系统的默认行为。
多agent场景明确任务合同
当多个agent协作时，任务边界、验收标准、交接规范必须显式定义。
从"功能数量"转向"工作秩序"
这不是一个技术动作，是一个产品哲学的转变。
---
#07 "工作秩序"是什么意思
功能，是agent能做什么。
秩序，是agent在出错、中断、超长任务时，系统能不能自己稳住。
一个有100个功能但状态随时丢失的系统，和一个有20个功能但能稳定运行72小时的系统——哪个更有价值？
在展示和demo阶段，功能数量更吸引眼球。
在真实使用场景里，工作秩序决定生死。
现在这个行业正好处在从"展示阶段"向"真实使用阶段"过渡的节点。
这个节点，是真正拉开差距的窗口期。
---
#08 认知陷阱：你还在用工具的心态做系统
这件事之所以难，不是技术难。是有一个认知陷阱很难跳出来。
大家习惯了把AI当"工具"用——用完就走，下次重来，出错怪模型，换个prompt再试一次。
这个心智模型在短任务上够用。
但Harness Engineering要求你换一个框架：把AI系统当成需要架构设计的长期工程。
不是"这个模型够不够好"，而是"这个系统的工程底座够不够稳"。
一字之差，系统成熟度差一代。
---
#09 最后
真正拉开差距的，不是功能数量，而是工作秩序。
这不是关于某一个模型的判断，也不是某一家公司的产品观。这是整个AI工程领域，在经历了两年功能爆发之后，正在集体转向的方向。
OpenAI、Anthropic、LangChain同时在讨论这件事，不是巧合。
你现在在用的AI系统，有没有状态工件？有没有验证守卫？有没有错误恢复路径？
如果都没有，你还在用工具的心态做系统级的事。
这不是落后，是正在被淘汰。
---
🔗 工程哲学系列：
🔍 实证来源：[[../../公众号/文章草稿/Claude源码泄露_三环模型_深度分析|Claude源码泄露·三环分析]]（源码揭示的正是Harness Engineering）
📝 语言精确性：[[../20260316-月入5万的人话都这么毒|月入5万·语言精确性]]（工作秩序的认知基础）
🛠️ 实操教程：[[../../公众号/文章草稿/小白用好baoyu-skills深度教程|baoyu-skills深度教程]]（如何建立Skill工程秩序）
---
#创作备注
核心赌注：切角从"介绍概念"升级成"行业转折点的亲历者视角"——不是科普，是判断。结尾三个问题比checkbox更开放，适合引发高质量评论。
>
配套策略：发布当天同步发一条短推引流，引用最有争议性的一句话作为钩子——「真正拉开差距的，不是功能数量，而是工作秩序」——单独发出，带长文链接。
>
推荐发布时间：工作日上午 9–11 点（北京/上海时区）