AI 圈的进化太快了发现已经跟不上节奏了还是上个季度大家都在讲 Prompt/Context Engineering说 AI 时代最值钱的技能是把上下文给到位。这个概念确实好懂很多人照着做也有效果我以为自己大概摸清楚了这条路。结果最近一刷技术圈发现关键词已经悄悄换了。大家嘴里开始出现一个新词Harness Engineering。Context 工程和 Harness 工程乍一听像换汤不换药但仔细看后者的范围要大得多。Context 只是其中一个环节就像给地图只是开车的准备动作Harness 说的是整套驾驶方法论怎么设计路线遇到红灯怎么处理抵达之后怎么确认没走错。这个转变背后有两个催化剂。一是 OpenAI 在今年 2 月发了一篇长文讲他们如何用 Codex Agent在五个月内写出了 100 万行代码零手写。紧接着 Anthropic 的工程师也发了一篇实战报告展示了如何用多智能体架构让 Claude 自主完成复杂的全栈应用开发。两家顶级公司不约而同地往同一个方向走这事值得好好聊聊。Harness 是什么意思先说这个词本身。Harness 的本意是马具就是套在马身上的那套缰绳和鞍具。用在 AI 工程里意思很直白给 AI Agent套上缰绳让它在可控的范围内干活。这不是一个具体的工具或者框架而是一套工程方法论。核心思路是人类工程师不再一行一行地写代码而是负责设计环境、定义意图、搭建反馈循环让 AI Agent在这个笼子里自主完成开发工作。听起来像是 prompt engineering 的升级版某种程度上是但 harness engineering 的范围要大得多。它涵盖了上下文管理、架构约束、质量保障、可观测性等一整套体系。Context Engineering 是它的地基但只是地基。OpenAI 的实践100 万行代码的实验OpenAI 的团队做了一个相当激进的实验。一个小型工程师团队完全依靠 Codex Agent来写代码五个月后交付了一个包含约 100 万行代码的 beta 产品。他们的 harness 体系围绕三个支柱构建上下文工程Context Engineering这是给Agent喂料的部分。团队在代码库中维护了一套结构化的文档目录包括架构地图、执行计划和设计规范作为Agent的唯一知识来源。同时Agent还能动态访问可观测性数据比如日志、指标和链路追踪信息。简单说就是让Agent随时知道我在哪、我该干什么、系统现在怎么样了。架构约束Architectural Constraints这是缰绳的核心。团队定义了严格的依赖流向Types → Config → Repo → Service → Runtime → UI每一层只能依赖它上游的层。这些约束通过 LLM Agent和确定性的自定义 linter 共同监控。有意思的是约束不是为了限制Agent的能力恰恰相反约束带来了自主性。当解决方案空间被明确限定后Agent反而能更可靠地完成工作。就像给新员工一本详细的操作手册比让他自由发挥效率高得多。垃圾回收机制这个名字起得很形象。团队部署了专门的Agent周期性地扫描代码库检查文档是否与实际代码一致、架构约束是否被违反。发现问题就自动修复或者标记出来。这其实解决了一个很现实的问题当代码量大到一定程度尤其是 AI 生成的代码维护一致性本身就成了巨大的挑战。Anthropic 的实践GAN 启发的多智能体架构Anthropic 工程师 Prithvi Rajasekaran 走了一条不同但同样有趣的路线。他的出发点是两个痛点上下文焦虑模型在处理长任务时会逐渐失去连贯性当它感觉自己快用完 context window 时会匆忙结束工作质量直线下降。自我评估偏差让Agent评价自己的输出它几乎总是说做得不错即使结果很平庸。这在设计类的主观任务上尤其明显因为没有明确的对错标准。他的解决方案很巧妙借鉴了 GAN生成对抗网络的思路把生成和评估分成两个独立的Agent。在前端设计场景中生成器负责写代码评估器通过 Playwright 实际打开浏览器、浏览页面然后根据四个维度打分设计质量、原创性、工艺水平和功能性。一个任务通常迭代 5 到 15 轮效果相当显著。文章中举了一个博物馆网站的例子经过十轮迭代后设计从普通的深色模板变成了一个 3D CSS 透视体验。在全栈开发场景中他用了三个AgentPlanner规划者把 1 到 4 句话的简短需求扩展成包含 10 到 16 个特性的完整产品规格Generator生成者基于 React Vite FastAPI 技术栈增量实现功能Evaluator评估者通过浏览器自动化测试运行中的应用在每个 sprint 开始前就定义好通过标准实际测试数据也很有意思。单独让 Claude 做一个复古游戏制作器用了 20 分钟花了 9 美元结果游戏机制基本不能用。用完整的 harness 架构花了 6 小时、200 美元但产出了一个真正可用的应用包含完整的物理引擎和 AI 集成功能。两种路线的异同把 OpenAI 和 Anthropic 的方案放在一起看能发现一些有趣的共识和分歧。共识方面两家都认为单靠提升模型能力是不够的你需要在模型外围搭建一套工程体系。无论是 OpenAI 的三支柱架构还是 Anthropic 的多智能体对抗系统本质上都在做同一件事让 AI 的输出从看起来像那么回事变成真正能用。两家也都强调了评估和反馈循环的重要性。OpenAI 用周期性的垃圾回收Agent来维护质量Anthropic 用独立的评估Agent来对抗自我评估偏差。核心逻辑一样不能让 AI 自己既当运动员又当裁判。分歧方面OpenAI 的方案更偏向组织级实践强调团队如何围绕 AI Agent重组工作流程文档体系、架构规范、可观测性这些基础设施是重点。Anthropic 的方案更偏向任务级架构关注的是如何在单个复杂任务中编排多个Agent协作GAN 对抗思路和迭代优化是重点。两者其实是互补的。一个讲的是公司层面怎么用 AI 写代码另一个讲的是具体怎么让 AI 把一个复杂任务做好。Harness 会随模型进化而变化Anthropic 的文章里有一个很关键的观察当 Opus 4.6 发布后之前架构中的 sprint 分解步骤变得不再必要了因为新模型本身的规划和长上下文能力已经足够强。但这并不意味着 harness 变简单了。Rajasekaran 说了一句很精辟的话**harness 的复杂性不会缩小只会转移。**模型变强了某些约束可以拆掉但新的能力又会带来新的编排可能性。就像手动挡汽车换成自动挡你不用管换挡了但你可以把注意力放在更高级的驾驶技巧上。Martin Fowler 网站上的评论文章进一步推测harness 可能会成为现代黄金路径服务模板的继承者。以前公司给新项目提供脚手架模板以后可能直接提供一套 harness 配置告诉 AI Agent在这个框架里干活。开源社区的三种路径理论归理论有没有人把 harness engineering 做成了普通开发者能直接用的东西还真有而且最近同时冒出了几个路子不同的项目。路径一强制流程派SuperpowersGitHub 上的Superpowersobra/superpowers目前超过 11 万星是这个领域最早出圈的开源实现。作者 Jesse Vincent 把 harness engineering 打包成了一套可安装的插件支持 Claude Code、Cursor、Codex、Gemini CLI 等主流工具。它的核心哲学是强制流程而非建议流程。启动编码Agent时Superpowers 不让 AI 直接动手写代码而是先触发头脑风暴技能逼着 AI 跟你确认需求、探索方案、输出设计文档通过了才进入实现阶段。实现阶段采用子Agent模式主Agent把计划拆成 2 到 5 分钟的小任务分发给子Agent完成后经过两轮审查。TDD 是硬约束先写失败的测试再写最少的代码让测试通过Agent敢跳过这步就要求删掉重来。路径二虚拟团队派gstackgstackgarrytan/gstack是另一个思路65,000 星作者是 Y Combinator 的 CEO Garry Tan。听到YC CEO 开源了自己的编码工作流可能觉得是 PR 稿但你看他的数据在过去 60 天里他一边全职运营 YC一边利用业余时间靠 gstack 产出了 60 万行生产代码每天 1 万到 2 万行其中 35% 是测试。仅最近一周3 个项目里 362 次提交净增 11.5 万行代码。gstack 的方法论是把 Claude Code 变成一个虚拟工程团队。它提供 23 个专家角色每个都是一个斜杠命令/plan-ceo-review让 AI 扮演 CEO 质疑你的产品决策/design-review让 AI 扮演挑剔的设计师检查 UI/review是代码审查/qa打开真实浏览器测试你的 staging 环境/cso运行 OWASP 和 STRIDE 安全审计/ship负责打包发 PR。角色分离是 harness engineering 的精髓。写代码的 AI 和审代码的 AI 分开就像 Anthropic 的生成器/评估器架构但 gstack 把这个思路拆得更细不同类型的挑刺交给不同的专家角色。路径三复利工程派compound-engineering-plugin最后一个是compound-engineering-pluginEveryInc/compound-engineering-plugin13,000 星来自媒体/科技公司 Every Inc.。这个项目的切入角度最哲学每一个工程单元都应该让下一个工程单元变得更容易而不是更难。传统开发是负复利每加一个功能就多一点技术债代码库越来越难维护。compound engineering 要反过来让工程工作像复利一样累积。实现方式是把工作流设计成 80% 规划评审 20% 执行。工作流程Brainstorm → Plan → Work → Review → Compound → 循环。最后的Compound步骤最有意思专门用来把这轮迭代学到的东西文档化让下次干类似的活时Agent有更好的上下文。这有点像 OpenAI 那个垃圾回收Agent的升级版不只是维护一致性而是主动积累知识。工具链支持 Claude Code、Cursor、Codex、Gemini CLI、Windsurf 等几乎所有主流编码工具。三条路的异同三个项目针对的问题是一样的怎么让 AI Agent的输出从能用变成可靠。但各自的侧重点不同Superpowers 靠强制约束gstack 靠角色分工compound engineering 靠知识累积。你不必选一个。很多人会把它们叠着用毕竟本质上都是在同一个 harness 框架下增加不同维度的控制。对普通开发者意味着什么有了这些工具harness engineering 已经不完全是未来的事了。但整体来说这个领域仍然处于早期探索阶段。几个值得关注的趋势写代码这件事本身在变。从人写代码到人指导 AI 写代码这个转变正在加速。Harness engineering 就是在为这个新范式建立工程规范。架构设计能力会更值钱。当写代码的门槛降低能设计好架构约束、搭建好反馈循环的人会成为稀缺资源。技术栈可能会收敛。当代码从打字变成指导生成行业可能会趋向更少、更标准化的技术栈选择。毕竟约束越统一Agent的效率越高。我自己跟不上的原因大概是Context Engineering 是一个知识点学了就学了。Harness Engineering 是一套实践体系不上手做很难真正理解。好在现在有这几个开源项目门槛已经比半年前低得多了。