03-第一篇-术语、起源与范式迁移

03-第一篇术语、起源与范式迁移一场变化真正开始深入现实往往不是先改工具而是先改语言。旧语言还在人们却越来越频繁地感觉到它不够用了明明问题出在知识入口、验证回路、交接结构和责任边界团队却还在用 prompt、工具数量和模型强弱来解释成败。语言一旦落后解法就会跟着落后。问题就在这里旧词为什么开始失效新词为什么会被逼出来问题重心又为什么会从模型单点表现转向系统组织方式。在方法出现之前坐标必须先被立起来。本篇图示见图 1-1 至图 1-4。图 1-1 Prompt、Context、Agent、Workflow、Harness 的关系图Prompt engineering把意图说清楚Context engineering让模型看见正确的信息Agent engineering让模型能采取动作Harness engineering把目标、上下文、工具、约束、验证、记忆与改进组织成系统这张图里最关键的不是“先后顺序”而是问题范围的扩大。Prompt engineering 主要解决表达问题context engineering 处理可见性问题agent engineering 让模型拥有行动能力harness engineering 则试图把前面这些能力放进一个可运行、可验证、可治理的整体之中。本篇证据骨架本篇核心命题主要证据反向证据或边界本篇要得出的判断prompt 已不足以解释 agent 成败OpenAI、Anthropic、LangChain 都把问题重心放在环境、验证、交接与工具上而不只是 promptMETR 提醒我们即使有 AI 工具真实生产也可能先变慢争论正在从“怎么问”转向“怎么建系统”harness 先在工程现场里发生再被术语命名Mitchell Hashimoto 的经验总结、OpenAI 的内部实践都先有踩坑再有抽象如果只看术语史容易把它误写成“某篇文章发明一个词”harness engineering 是被现实逼出来的工程语言同一模型会因系统差异而表现悬殊LangChain 在固定模型下只改 harness 就显著提分METR 显示真实熟悉仓库里的隐性知识会削弱增益模型能力重要但系统能力开始主导生产结果1. 当旧词开始失效Prompt engineering 在今天仍然重要但它的解释力已经开始收缩。它擅长处理的是表达问题如何让模型更准确地理解意图如何减少歧义如何通过 few-shot 示例把输出拉近目标。只要任务停留在单轮问答、一段代码补全或一次性生成的边界内这些技巧就足以解释大部分成败。真实工作却不是这样。真实工作总是一个多步骤过程理解目标、寻找背景、调用工具、修改对象、观察反馈、验证结果、必要时跨多个阶段继续推进。只要任务跨越了这些步骤prompt 就会迅速从“主变量”退回到“众多变量之一”。原因很简单。prompt 只能回答“我要你做什么”却无法单独回答另外几个更难的问题你看见了什么你能动什么你怎么知道自己做对了你失败后该如何恢复。前者属于 context 和 tool 的问题后者属于 verification、memory 和 improvement 的问题。它们合在一起才是 agent 的真实工作系统。这也是为什么很多团队会出现一种共同感受继续打磨 prompt边际收益开始下降但一旦重做知识入口、任务模板、测试链路和反馈回路整体质量却明显上升。这里并不是语言不再重要而是语言被纳入了更大的结构。所以说 prompt engineering “过时”并不准确更准确的说法是它已经不再足以独立解释 agent 时代的生产问题。它仍然是入口的一部分却不再能够单独构成全部解释见参考文献[1]、[9]、[10]。2. 一条更清楚的时间线术语史最容易被写错的地方是把它写成“某一天某个人发明了一个词”。真正推动术语变化的通常不是发明而是失配。旧词还能解释局面时新词不会真正站稳只有当现实反复溢出旧词边界新术语才会从口头感受慢慢长成可共享的工程语言。这也是为什么第一篇不能只做定义表。它还必须交代在什么时间点上工程团队开始持续感觉到 prompt 已经不够tool use 已经不够workflow 这个词也不够。因为只有这条时间线立起来读者才会明白 harness engineering 不是一个“更潮的说法”而是一组工程压力长期积累后的命名结果。如果把过去几年最关键的公开材料排成一条线大致会看到下面的迁移图 1-2 从 prompt 到 harness 的压力时间线2023-2024Prompt 仍能解释大多数单轮生成问题2025-05Codex 等执行型系统公开化隔离环境、可执行验证开始上升2025-11Anthropic 强调长时程 agent 的交接、日志与 clean state2026-02-05Mitchell Hashimoto 把反复犯错的问题转成环境机制问题2026-02-11OpenAI 正式把这一层经验命名为 harness engineering2026-02-17 之后LangChain、Thoughtworks、Mollick 等把它外化成行业语言这条时间线里最值得注意的不是最后那个名字而是前面的压力如何一点点累积。2025 年 Codex 等系统公开以后工程团队第一次大规模遇到一种新现实模型不只是在回答问题而是在读仓库、调工具、跑验证、跨文件改动、进入带状态的运行环境。这时很多过去可以被一句 prompt 掩盖的问题都浮出来了比如目录信息是否可发现、默认命令是否正确、测试是否足够快、失败后能否恢复、权限和边界是否被写清楚见参考文献[2]。到了 2025 年底Anthropic 讨论长时程 agent 的文章把另一层问题推到台前即使模型单次任务表现不错只要任务持续时间够长系统就会很快暴露出 handoff、progress log、clean state 和 thread continuity 的重要性。问题已经不再是“模型会不会做”而是“系统有没有办法让它持续做、交接做、恢复做”见参考文献[9]。2026 年初Mitchell Hashimoto 用一种更接地气的语言把这种变化说透了当 agent 反复犯同一种错真正值得做的不是重复抱怨模型而是把“防止它下次再错”的机制写进环境。这一步看似朴素却完成了一次重要转向错误第一次不只被理解成模型失误而被理解成环境没有把经验沉成机制见参考文献[6]。几天之后OpenAI 把这层变化明确命名并公开展示它在团队内部已经长到什么程度不只是 prompt 和工具而是 repo 结构、文档布局、评估回路、worktree、可观测性、background cleanup 和默认路径全部一起被当成一个工作系统来设计见参考文献[1]。再往后LangChain 用 benchmark 证据说明固定模型只改 harness 也能显著提分Thoughtworks 则把它重新拆解为 context、constraints 和 garbage collectionMollick 又把 harness 推到更广泛的 agent 使用讨论里见参考文献[7]、[8]、[10]。所以术语史如果写得准确应该不是“谁发明了 harness engineering”而是工程现场先持续撞上一类旧词解释不了的问题后来才终于找到一个更能容纳这些问题的词。这也是为什么本书要把“术语、起源与范式迁移”写成同一篇而不是拆开来分别讨论。它们本来就是同一件事。3. harness engineering 是怎么被逼出来的重要概念很少是先由理论家发明再由工程团队照着执行的。Harness engineering 的生成过程恰好相反工程团队先在真实工作里撞上了同一类问题才逐渐需要一个更大的词把这些分散动作收拢在一起。这些问题都很具体。模型单轮看起来很聪明一进真实仓库就容易失焦单次输出看起来不错一跨会话就开始失忆一开始像在帮忙规模一上来却不断复制坏模式。工程团队慢慢意识到问题不只是模型而是“围绕模型的东西”知识是不是可发现工具是不是闭环测试是不是够快边界是不是够清楚错误信息是不是足够有用系统是否能观察到 agent 的中间行为。Mitchell Hashimoto 在 2026 年初回顾自己的 AI 使用历程时把这种直觉说得很朴素当 agent 反复犯同一种错真正值得做的不是继续抱怨模型而是把“防止它下次再错”的机制写进环境里。这个机制可以是AGENTS.md可以是验证脚本也可以是目录说明和边界约束。这个表述的力量不在于抽象而在于它来自工程现场反复踩坑后的反应见参考文献[6]。OpenAI 随后把这类反应推进到更极端的位置。2026 年 2 月那篇文章里他们描述的不是一个“提示词技巧合集”而是一支几乎不手写代码的团队如何被迫把文档、规则、工具、测试、可观测性和 repo 结构全部重写成 agent 能工作的环境。文章最值得注意的不只是那些惊人的产能数字而是他们明确承认一份越写越长的AGENTS.md很快会失效真正起作用的是把知识拆进仓库、让 worktree 可运行、把日志和 DevTools 暴露给 agent、再用评分系统和 background cleanup 持续收敛质量见参考文献[1]。因此harness engineering 的传播速度本身就在说明一件事它命中了一个已经普遍存在、却还没有被清楚命名的问题。这个词的价值不在于替代所有旧概念而在于给工程团队一个更高一层的观察视角。4. 几次典型误判是怎样把系统问题重新讲回旧语言的一门新工程语言真正站稳之前总会先经历一段误判密集期。大家已经感觉到旧解法不够用了却还没有完全承认问题已经换层于是会本能地把新问题重新翻译回旧语言。第一篇如果不把这些误判写出来后面的方法论就很容易显得只是换了一套名词。最典型的误判至少有四类。第一类误判是把一切失败都继续归因于 prompt 不够好。一个 agent 找错目录、漏掉关键上下文、在错误路径上持续推进团队最容易做的动作仍然是“再改一版 prompt”。但很多时候真正缺的不是表达而是知识入口、目录地图、默认命令、退出条件和快速验证。继续只在 prompt 层打磨等于在错误层级上投入越来越多精力。第二类误判是把工具数量当成 agent 成熟度。工具当然重要没有工具agent 很难进入真实工作但工具一多并不自动等于更强。太多团队在早期会把“接了浏览器、接了 shell、接了数据库、接了外部 API”理解成能力升级却忽略了更难的问题这些工具之间有没有清晰默认路径授权带是否明确错误是否可观察失败后有没有足够快的恢复手段。工具扩张和系统成熟不是同一件事。第三类误判是把局部成功当成普遍规律。OpenAI、Anthropic 或 LangChain 这样的前沿案例很容易制造一种错觉似乎只要把模型接进工作流所有团队都会自然获得高吞吐。METR 的结果恰好提醒我们现实并不会这么顺滑。真实熟悉仓库里那些隐性知识、局部默契、未文档化边界和脆弱验证会让 agent 的增益大幅缩水甚至先表现为摩擦见参考文献[11]。因此成功案例不能直接当通用规律反例也不能直接当全面否定两者都必须被放回“环境条件”之内理解。第四类误判是把 harness engineering 看成“老工程常识换个名字”。这个误判之所以顽固是因为它表面上很像对的文档、规则、测试、日志、模板、平台这些东西过去本来就重要。问题在于过去它们首先服务人现在它们还必须服务 agent。对象一旦变化很多旧实践就不再只是“原样延续”而是被迫进入新的组织方式。不能被机器发现的知识、不能被系统执行的规则、不能被自动回路使用的验证都会在 agent 时代暴露出新缺口。把这几类误判放在一起看就会发现一个很稳定的模式每当新问题出现团队总会先尝试用旧词解释它而 harness engineering 之所以必要正是因为旧词已经无法持续容纳这些问题。图 1-3 典型误判如何把系统问题重新讲回旧语言系统问题出现归因给 prompt归因给模型不够强归因给工具还不够多归因给团队还没更努力真正根因继续留在环境里因此术语不是修辞装饰而是一次根因重分配。它逼迫团队承认不是所有失败都发生在输出层也不是所有成功都来自模型层。很多真正决定结果的变量早已上移到环境、控制和组织层。5. 从“模型能力”到“系统能力”在纯生成场景中把性能主要归因于模型能力是有道理的。模型更强系统通常更强模型更弱系统通常更弱。进入 agent 场景之后这种理解开始显得粗糙。同一个模型在两个团队手里可能表现出完全不同的生产力。原因不在模型参数而在系统能力。一个团队有清晰的知识入口、快速测试、明确边界、稳定工具链和持续改进回路另一个团队的事实散落在会议、聊天记录和个人脑中验证脆弱目录混乱错误信息含糊权限设计粗放。两者即使使用同一模型也几乎不在一个竞争平面上。LangChain 在 2026 年给出的实验把这件事讲得很直白使用同一个模型gpt-5.2-codex只改 harness不改模型就把 Terminal Bench 2.0 的分数从52.8拉到了66.5。这当然不能直接外推到所有真实工作但它至少提供了一个清楚证据系统设计本身就足以改变上限见参考文献[10]。另一方面METR 的研究又提醒我们系统能力不是“给 agent 加更多能力”这么简单。在熟悉自己仓库、依赖大量隐性知识的真实项目里2025 年初的 AI 工具让资深开发者平均慢了 19%。这说明系统能力还包括另一层判断什么任务形态适合 agent什么环境整理程度足以支撑 agent什么场景里人类专家仍然占据明显上下文优势见参考文献[11]。把这两个结果放在一起看结论就比较稳了模型能力仍然重要但真正决定产出能否被兑现的已经越来越是整套系统能力。知识组织、验证链路、边界清晰度、记忆结构和改进回路这些东西第一次从“辅助条件”上升成了更接近主导变量的位置。图 1-4 从模型能力到系统能力的转移模型能力推理、生成、工具使用系统能力知识结构、验证、边界、记忆、改进更强模型更强环境把模型能力兑现为稳定产能真实生产结果6. 术语不是名词游戏而是解题路径这个领域最大的噪声之一就是术语混乱。很多时候人们用不同的词在说同一件事也常常用同一个词指代完全不同的东西。对工程团队而言这不是学术问题而是解题路径问题。词一旦用错解决方案就会错配。下面这个区分是本书后续讨论的坐标系名词它首先解决什么问题典型误判Prompt engineering如何把意图说清楚把所有失败都归为“prompt 不够好”Context engineering模型究竟看见什么以为“多给一点信息”就等于更好Agent engineering模型怎样拥有行动能力以为工具越多越强Workflow automation多步骤怎么被串成流程以为流程存在就等于系统可靠Harness engineering如何把目标、上下文、工具、约束、验证、记忆与改进组织成系统把系统问题重新讲回单点工具问题这个分层之所以重要是因为它能帮助团队识别问题到底在哪一层。一个 agent 明明拥有正确工具却总从错误文件开始改很可能是 context 问题一个 agent 输出格式正确却行为错误更像 verification 问题一个 agent 单次任务表现不错跨会话后持续退化则大概率是 memory 和 improvement 的问题。如果没有清楚的分层团队就很容易陷入一种昂贵模式发现问题后下意识去改 prompt、换模型、加工具结果却始终没有碰到根因。术语看似只是语言实际上决定了解法。7. 为什么本书坚持用“harness engineering”本书选择“harness engineering”作为总框架不是为了追赶热词而是因为它最能容纳这组变化。它允许我们在一个统一视角下同时讨论目标如何被定义知识如何被组织工具如何被接入边界如何被编码验证如何被运行记忆如何被延续经验如何被改进也只有在这个视角下我们才不至于把所有新问题都重新说回“prompt 怎么写”或“模型够不够强”。问题先在这里被校准。再往下走讨论就不能只停在命名上了那个“登录与邀请流程改造”的小案例也会在下一篇里被真正拆开变成一条能反复照见结构的贯穿线。本篇小结这一章的意义不在于再发明一个术语而在于把观察角度从模型单点表现推向系统组织方式。旧词为何失效新词为何出现压力如何从表达问题一路传到验证、交接与责任问题坐标到这里才算真正立稳。下一篇会把这些压力继续拆开落到一套可设计、可修补的七层系统上。