Harness 工程十二条心法：Google 首席工程师一年实践，浓缩成可直接照做的流程和模板
- Ryan Lopopolo 现在是 Google Cloud 的首席工程师，此前在 OpenAI。他把过去一年的工作提炼成十二条心法，做成一个公开仓库，可以直接喂给自己的 Agent 当参考资料；十二条里的实证多来自 OpenAI 那段经历。
- 核心操作反直觉：选定的模型和编码 Agent 当成不可改的黑盒锁死，一个参数都不调，只改它周围的两样东西，上下文和工具。
- 十二条分三层。三条划边界：锁死 worker、把私有流程数据送进去、按实测结果衡量。六条是杠杆：整件活交一个 Agent、上下文按需路由、能力要用得动、让仓库自己教、权限写明白、在真环境举证。三条管复利：反馈变基础设施、守住长期连贯性、把已定的活跑成常驻循环。
- 撑起这套说法的实证：一个内部产品五个月从空仓库长到约一百万行代码，约 1500 个合并 PR，全部由 Codex 写成，人没有手写一行。
- 能直接带走：一套六步改进流程、三份填空模板、一张「你声称什么就得在哪取证」的十一行对照表、一份「什么情况下你的对照实验不作数」的九条清单。
十二条心法，和一个被译反的词
先把词摆正。harness 在这里是马具的意思，鞍、缰、蹄铁、挽带那一套，仓库简介开头就挂着一个马的表情符号。它很容易被读成「束缚」，方向正好反了。
马已经足够能跑。缺的是鞍、缰和跑道，让它的力气真的落到地上，去到该去的方向。harness engineering 做的就是配这一套东西。
写这套东西的是 Ryan Lopopolo。他现在是 Google Cloud 的首席工程师，做 agentic GCP 方向；在这之前他在 OpenAI，参与建设西雅图办公室和面向企业的 OpenAI Frontier，工作内容正是给 Agent 配上下文、工具、权限、评估、可观测性、编排和反馈回路。十二条里那些实证，多数来自这段经历。更早他在 Snowflake 做数据市场的技术负责人，在 Brex 带一个 40 人的团队支撑 350 人的工程组织，在 Stripe 做基础设施和支付的技术负责人，经历了公司从 600 人长到 6000 人。业余时间他用 Rust 写了一个 Ruby 实现，叫 Artichoke。
他把这十二条发出来的时候说，这代表了他过去一年的工作，是实践，也是技术。
他把自己的实践提炼成十二条心法，连同证据、案例和可执行的流程一起放进一个公开仓库，仓库自撰的内容采用 CC BY 4.0 授权。用法有两种：人直接读，或者把它和你要改进的系统一起交给编码 Agent，让 Agent 按里面的分流索引自己去查该看哪一条。
为什么值得看：十二条里每一条都挂着可查证的实证。一个内部产品五个月从空仓库长到约一百万行代码、约 1500 个合并 PR，代码全部由 Codex 写成，人没有手写一行；一次 60 小时、三亿多 token 的大改造只用了初始提示词加两次追问；打开一条代码检查规则（lint，自动揪出不合规范写法的工具）之后，约 600 处违规在同一个 PR 里修完并补齐了测试。
下面是十二条的全貌。分成三层是为了看懂它们的关系：最上面三条划定边界，中间六条是实际的杠杆，最下面三条决定这套东西能不能随时间累积。接下来一条一条讲。
第一条：把干活的那个「人」固定住
一次评估或部署周期里，模型、编码 Agent 的运行时、原生工具接口三样锁死不动。这三样里任何一样变了，就算换了一代，整套环境要重新验收一遍。
锁住黑盒的收益是失败变得可归因。一个明明很能干的 Agent 干不成一件活，原因通常落在五处：缺相关的机构上下文、缺一个真能用的能力、缺有用的反馈回路、缺权限，或者出口处缺证据。这五样都是部署环境的属性，都能查、都能改。不锁黑盒，你就永远卡在「到底是模型不行还是我没配好」之间打转。
你自己攒下的那套经验，也属于要重新验收的东西。旧模型教会你的那些习惯：任务该切多小、需要多少编排、内循环能等多久、哪些地方必须人盯着，原封不动带到新一代上，新模型多出来的本事就白给了。反过来，假设每个小版本都在每个维度变强，是另一个方向的错误。
他自己记下的一次观察：GPT-5.3 比 GPT-5.2 更不愿意去啃困难的活。这是一条单独的使用观察，不构成趋势。
换代能带来多大差别，有两个数字。GPT-5.2 发布的时候他正在休假，回来发现团队在没有任何额外环境投入的情况下，每个工程师每天多产出一到两个 PR。后来一次单独的 Symphony 环境改造，报告的是每个工程师每周 PR 数量十倍的增长。前一个来自模型换代，后一个来自环境改造，两者要分开记账，这正是锁住黑盒的意义。
GPT-5.2 发布期间，环境一行没改。
每人每天多出一到两个 PR。
Symphony 那次干预，worker 没换。
报告每人每周 PR 数量十倍增长。
内循环的延迟也属于验收范围。Agent 能推理到什么程度，取决于它在这一趟（一条轨迹，就是 Agent 干一件活从头到尾的整个过程）跑散之前能拿到多少反馈。GPT-5.2 时代的 Codex 环境没有后台 shell，Agent 会老老实实等阻塞的构建脚本跑完；GPT-5.3 加了后台 shell 之后它就不愿意等了。团队用一周时间把仓库的构建从自己写的脚本一路换到专业构建工具（先后试了 Bazel、Turbo、Nx），停手的条件是全量构建进一分钟以内。这一分钟被定成硬上限，一旦破线就停下手上的活去拆构建图。
验收还包含减法。为了让 Agent 看见界面，团队曾经自建过一套虚拟显示加录屏的东西；模型自己能看屏幕、点鼠标的能力（computer use）出来之后，这一整套被删掉了，端到端的验证并没有因此丢失。
第二条：部署进私有流程数据的水下部分
通用模型的权重里装着的，只是一个组织知识的尖。水线以下才是干活真正要用的那些东西，而且它们是私有的、一直在变的。
这一条要求把两套东西说清楚。一套叫数据本体：有哪些实体、指标、标识符，它们之间什么关系。另一套叫工作本体：有哪些结果、工作流、角色、工具、例外、证据和授权关系。
有个例子很能说明问题。一个内部的数据 Agent，光给它数据仓库的权限是不够的，它解决不了「收入」和「活跃用户」这两个词在公司内部互相打架的定义。它还需要知道公司有哪些产品线、客户怎么分层、有哪些团队、哪些客户在试点、当前的计划是什么、共享的指标定义是怎么写的。有了这些关系，它才能给出一个属于这家公司的答案。
当前的记录留在数据仓库、工单系统、文档系统、日志、代码库、客户系统里，用搜索和连接器取一片授权过的切片，不要造第二份会过期的副本。
组织形态上有一个可以直接抄的做法。Basis 这家公司有两个仓库：Arnold 是生产用的单体仓库，Atlas 是第二个仓库，专门放公司的上下文，在生产代码树之外。Codex 可以把个人笔记、公司运营知识和生产代码组合起来用，而这两批信息各自保留独立的更新路径。实现形态可以很朴素，他的原话是「就是 Codex 加一个装满 Markdown 的 Git 仓库」。
还有一件事属于这一层：稳定下来的决策要提拔到它管得着的那一层去。某个团队和安全部门一起选定了一个批准使用的加密实现，这个决定留在了 Slack 里。后来一位新工程师用 Codex 干活，Codex 装了另一个 npm 加密包。团队把这个决定捞回来，在仓库里写成守卫规则，然后重新跑了一遍那次改动。
第三条：一个 Agent 领整件活
委托的是结果，交给一条主轨迹全权负责：拆解、执行、整合、举证、安全收尾。步骤留给它自己定。人只在三个地方出手，方向、判断，以及有后果的授权。