01-前言

从 Prompt 到 HarnessAI Agent 的工程化方法论-前言过去几年围绕人工智能最常见、也最容易制造情绪的问题是模型会不会替代程序员。这个问题当然抓人因为它直指职业焦虑、产业叙事和时代想象。但它也有一个明显缺陷它把视线过早集中在“人会不会被替代”上却忽略了“工作正在怎样被重组”。真正深刻的变化往往先发生在后者。先把两个场景并排放在脑子里。第一个场景里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 框架的功能清单上。它更关心方法论什么是 harnessharness 由哪些层组成为什么它会成为 agent 时代最重要的工程基础设施之一它会如何重写软件工程、团队协作与组织治理。如果你是一线工程师这本书会帮助你理解为什么越来越多技术工作开始转向“搭系统”而不只是“补实现”。如果你是技术负责人它会帮助你判断要让 agent 真正进入生产不只是换更强模型而是重构一部分工程环境本身。对产品负责人和组织管理者也是一样agent 系统不是简单自动化插件而是一种新的生产组织方式。这本书有一个坚定但克制的立场agent 的确正在改变软件生产。但改变的核心不是“AI 会写很多代码”而是“工程知识第一次被系统性重写成机器可读、可执行、可验证、可改进的形式”见参考文献[1]、[3]、[9]。如果它写得足够好读者读完后不该只记住几个新名词而应形成一种新的判断习惯看到一个 agent 系统表现惊艳时会追问背后的知识结构、验证链路和组织分工看到一个 AI 项目在现实里受挫时也不会立刻归因于“模型还不够强”而会去看仓库、流程、权限、反馈和责任到底如何分布。这本书也刻意保持警惕。任何新概念都容易在传播中被神化harness engineering 也不例外。它很容易被说成万能钥匙仿佛只要搭好支架agent 就会自动变成可靠员工。这种想象并不负责任。系统越复杂责任、边界、验证和治理的重要性就越高。Harness engineering 的价值不在于许诺一个无需管理的未来而在于承认我们必须更认真地管理。我希望读者读完后带走的不是对某种工具的短暂热情而是一套更稳定的判断框架面对任何 agent 系统都能追问目标如何定义、上下文如何组织、工具如何接入、边界如何约束、验证如何完成、经验如何沉淀、系统如何治理。从这个意义上说未来更稀缺的未必只是更会使用 agent 的人而更可能是那些能够把工作环境整理到足以让 agent 稳定进入的人。前言小结这本书的出发点很简单AI 对软件工程的冲击不只在模型而在工作环境如何被重新组织。谁更早把这个问题看成工程问题而不只是工具问题谁就更有可能在 agent 时代建立稳定优势。序章会先把这个问题钉在几个已经无法回避的现实冲突上。