前言
过去几年，围绕人工智能最常见、也最容易制造情绪的问题是：模型会不会替代程序员。
这个问题当然抓人，因为它直指职业焦虑、产业叙事和时代想象。
但它也有一个明显缺陷：它把视线过早集中在“人会不会被替代”上，却忽略了“工作正在怎样被重组”。真正深刻的变化，往往先发生在后者。
先把两个场景并排放在脑子里。
第一个场景里，OpenAI 在几个月内用 Codex 做出内部产品，约束近乎极端：没有人手写应用代码，代码、测试、文档、CI、可观测性都交给 agent 产出。
第二个场景里，METR 找来熟悉仓库的资深开源开发者，让他们在真实项目中使用 2025 年初的 AI 工具，结果不是更快，而是平均慢了 19%。
如果只问“模型会不会写代码”，这两个场景无法同时被解释；如果改问“这些团队给模型准备了什么样的工作环境”，问题就突然清楚了（见参考文献[1]、[11]）。
更准确的问题是：当模型已经能读代码、懂仓库、调工具、改文件、跑验证并产出结果时，软件工程会被重组为怎样的形态。
换句话说，当一个原本只“回答问题”的模型开始“参与工作”，我们究竟要为它建造怎样的工作环境。
这本书试图回答的，就是这个问题。
在最初几年里，人们谈 AI 与工程，主要语言是“辅助”：辅助写函数、补文档、生成测试、解释报错。
那时，“如何更好地提示模型”几乎就是全部议题。这段历史并不虚假，它有真实突破，也确实改写了很多人的工作方式。
但到今天，这种语言已经不够用了。问题不再只是“模型能不能帮我做一点事”，而是“如果模型开始真正做事，我们该如何为它搭一个世界”。
这正是 harness engineering 之所以重要的背景（见参考文献[1]、[6]、[7]）。
如果要把这件事压成一个最容易记住的比喻，我更愿意这样说：让 agent 工作，不像给天才出题，更像给新同事开工位。
你当然要把任务说清楚，但还要给他工位、门禁、代码库、测试环境、值班手册、审批路径，以及出错时该找谁。只给一句吩咐，不叫组织工作；那更像把人扔进现场，看他能不能自己摸出来。
很多讨论把今天的变化理解为 prompt engineering 的延长线，仿佛只要把提示词再写准一点，就能得到稳定智能体系统。
现实很快证明没这么简单。agent 能否可靠完成任务，往往不取决于那一句 prompt 是否足够聪明，而取决于它身处什么环境：它看见什么、能调用什么、哪里可动、哪里禁动、完成后如何验证、失败后如何恢复、经验如何沉淀成规则。
OpenAI 的经验说明，环境一旦组织清楚，agent 产能会出现质变。
Anthropic 的经验说明，哪怕模型很强，如果没有进度日志、初始化脚本、feature list 和会话交接，长时程任务仍会反复失忆。
LangChain 的实验更进一步，把这种变化做成可测量结果：固定模型，只改 harness，也能把分数从 52.8 拉到 66.5。
这些材料重要，不是因为它们都支持乐观主义，而是因为它们共同逼出一个更严厉的判断：单次表达当然重要，但事情能不能收场，越来越取决于围绕表达存在的工作系统（见参考文献[1]、[9]、[10]）。
这个工作系统包括仓库结构、知识组织、工具接口、执行边界、测试与评估、可观测性、计划机制、回滚与升级路径，甚至包括团队如何分配责任。
Harness engineering 讨论的，就是这整套支架。它之所以重要，不是因为术语新，而是因为它概括了一个真实变化：很多原本主要服务人类协作的基础设施，正在被改写成 agent 也能进入的生产环境（见参考文献[1]、[3]、[9]、[10]）。
我写这本书时最在意的，正是这里。今天最流行的说法，常常要么过度乐观，要么过度防御。
乐观版本喜欢说“AI 已经会写一百万行代码”；防御版本喜欢用一个反例证明“AI 根本不行”。这两种说法都太轻。
更值得讨论的是：为什么有些团队开始获得复利，另一些团队却被交互摩擦、验证成本和隐性知识拖住。只有把这个问题说透，harness engineering 才不是热词，而是一套值得长期使用的工程视角。
这会带来一种微妙但深刻的角色迁移。以前，优秀工程师主要体现在能写多复杂的系统、解多难的 bug、把多混乱的实现重新理顺。
今天这些能力仍然重要，但工程师的价值越来越多体现在更上游：能否定义清楚目标，能否把隐性知识外显，能否把边界写成规则，能否把经验沉淀成默认路径，能否把一次错误变成系统“下次不再犯同样错误”的机制。
工程师的工作，正在越来越多地转向“组织任务得以被可靠完成的条件”。
这不是能力下降，而是能力发挥层次上移。你仍然需要懂实现、懂架构、懂系统、懂质量，只是这些能力不再只服务于自己写出的某段代码，而开始服务于一个更大的工作环境。
我写这本书，并不是为了神化某个模型、某个工具或某家公司的产品。
恰恰相反，我希望把讨论从产品宣传和短期热词里抽出来，回到更稳定的工程问题：如何设计环境、约束、验证、观测与反馈，让一个并不完美但足够强大的智能系统，在真实世界里稳定产生价值。
因此，这本书不会只讨论如何写 prompt，也不会把重点放在某个 IDE 或 agent 框架的功能清单上。
它更关心方法论：什么是 harness，harness 由哪些层组成，为什么它会成为 agent 时代最重要的工程基础设施之一，它会如何重写软件工程、团队协作与组织治理。
如果你是一线工程师，这本书会帮助你理解：为什么越来越多技术工作开始转向“搭系统”，而不只是“补实现”。
如果你是技术负责人，它会帮助你判断：要让 agent 真正进入生产，不只是换更强模型，而是重构一部分工程环境本身。
对产品负责人和组织管理者也是一样：agent 系统不是简单自动化插件，而是一种新的生产组织方式。
这本书有一个坚定但克制的立场：agent 的确正在改变软件生产。
但改变的核心不是“AI 会写很多代码”，而是“工程知识第一次被系统性重写成机器可读、可执行、可验证、可改进的形式”（见参考文献[1]、[3]、[9]）。
如果它写得足够好，读者读完后不该只记住几个新名词，而应形成一种新的判断习惯：看到一个 agent 系统表现惊艳时，会追问背后的知识结构、验证链路和组织分工；看到一个 AI 项目在现实里受挫时，也不会立刻归因于“模型还不够强”，而会去看仓库、流程、权限、反馈和责任到底如何分布。
这本书也刻意保持警惕。任何新概念都容易在传播中被神化，harness engineering 也不例外。
它很容易被说成万能钥匙，仿佛只要搭好支架，agent 就会自动变成可靠员工。这种想象并不负责任。系统越复杂，责任、边界、验证和治理的重要性就越高。
Harness engineering 的价值，不在于许诺一个无需管理的未来，而在于承认：我们必须更认真地管理。
我希望读者读完后带走的，不是对某种工具的短暂热情，而是一套更稳定的判断框架：面对任何 agent 系统，都能追问目标如何定义、上下文如何组织、工具如何接入、边界如何约束、验证如何完成、经验如何沉淀、系统如何治理。
从这个意义上说，未来更稀缺的，未必只是更会使用 agent 的人，而更可能是那些能够把工作环境整理到足以让 agent 稳定进入的人。
前言小结
这本书的出发点很简单：AI 对软件工程的冲击，不只在模型，而在工作环境如何被重新组织。谁更早把这个问题看成工程问题，而不只是工具问题，谁就更有可能在 agent 时代建立稳定优势。序章会先把这个问题钉在几个已经无法回避的现实冲突上。
