解读OpenAI实验：AI Agent的核心竞争力不再是提示词

起初，我猜测这会是老生常谈的内容：如何撰写提示词、如何提供上下文、如何切换模型。然而，读完整个实验报告后，我最深刻的体会可以概括为一句：

如今AI Agent的竞争焦点，确实已不再是Prompt了。

更精确地说，提示词固然仍有其重要性，但它已不再是决定成败的关键因素。真正能拉开差距的，在于你是否为Agent铺设好了“赛道”。

环境并非次要角色，整个赛道的状况才真正决定Agent能否稳健运行。

最触动我的并非“3名工程师、5个月、100万行代码、零行手写”这类数字。

这些数字固然惊人，但并非核心。

真正让我驻足反复阅读的，是OpenAI在总结中自己指出的那句话：他们当前最艰巨的挑战，集中在环境设计、反馈循环和控制系统上。

你会发现，这句话与“模型中心论”截然不同。

它没有提及模型不够强大，也没有说提示词不够精妙，而是强调了一个更为基础的事实：环境若未就绪，Agent便无法稳定运行。

我本人出身于后端开发，因此对此深有感触。

因为这与我们早已熟知的一套工程常识几乎如出一辙。

一个服务编写得再精良，倘若缺乏注册中心、链路追踪、熔断机制、CI/CD流程、监控系统以及边界约束，整个系统依然可能崩溃。AI Agent如今也步入了同一阶段。

这篇文章清晰地总结了近三年的演变历程，读后我认为值得直接铭记：

最初人们认为，只要提示词写得足够详尽，AI就会更顺从。后来发现这还不够，于是开始补充上下文、补充文档、补充RAG、补充工具输出。再往后才逐渐意识到，即便知识再丰富，如果环境缺乏围栏、缺乏反馈、缺乏验证，它同样会偏离轨道。

因此，我越来越认同一个判断：上下文能让Agent知晓其所知，但赛道才能决定Agent是否会做错事。

从提示词到上下文，再到赛道，这才是近几年最关键的发展路径。

在OpenAI的那个实验中，有一点我特别赞同。

他们早期进展慢于预期，并非因为Codex不够强大，而是因为环境规范、工具抽象和结构边界都尚未准备就绪。

这个结论颇具反直觉性。

大多数人的第一反应往往是：“是不是模型还不够强？”

但现实似乎越来越向我们揭示：很多时候并非引擎动力不足，而是赛道太过糟糕。

我认为这句话对许多团队都具有警示意义。

因为我们遇到Bug时的第一反应，常常仍是“换个提示词再试试”、“再向它解释一遍”、“再补充一条规则”。

但真正更有效的追问应当是：

我们不再仅仅是那个亲手编写每一步代码的人，而是越来越像那个提前铺设好道路、弯道、护栏和刹车装置的人。

这一段论述我十分欣赏，因为它几乎与许多人的直觉相悖。

许多人可能会认为，Agent越自由，发挥空间越大。

但文章提供的经验恰恰相反：规则越清晰，Agent反而运行得越快。

原因很简单。

对人而言，规则有时像是束缚；但对Agent来说，规则更像是导航。

若不告知它什么能做、什么不能做，它就只能在各处试探，四处碰壁。

如果你将分层定义清楚、锁定依赖方向、收窄跨领域入口、明确Linter报错信息，它就不必浪费那么多轮次进行试错。

架构围栏并非束缚，而是让Agent避免盲目冲撞的导航系统。

读完这一段后，我最深的感受是：如今许多团队最急需补足的，并非再多学习几种提示词的写法，而是将项目中那些“人脑默认知晓、但Agent并不清楚”的边界，真正系统地编写出来。

OpenAI的实验是在组织层面进行的，但Mitchell Hashimoto的那套个人实践，我认为对普通开发者更具参考价值。

尤其是前三步，读完我几乎想立刻付诸实践：

你开始从“让我少写一些代码”，转向“让我少重复犯同样的错误”。

这恰恰是Harness Engineering最具工程特质的地方。并非一次性完成所有事情，而是每出现一次错误，就将这个错误封装进系统，确保其未来不再发生。

从聊天交互，到协同共处，再到持续在线，这才是许多人真正的采纳曲线。

如果你觉得前面的例子离自身还有些距离，那么LangChain的那个结果则更为直接。

他们没有更换模型，仅仅改进了Harness，排名便从全球第30位跃升至第5位。

这说明了什么？

说明在许多情况下，性能的提升并非源于“更换更强大的大脑”，而是“将外部环境建设得更像一个能够稳定输出的工地”。

我特别喜欢这类结果，因为它清晰地阐明了一件事：同样的模型，置于不同的环境中，可能产生截然不同的结果。

我认为至少有三个方面特别值得深思。

第一，真正有价值的能力正在发生迁移。

过去人们总认为“编写速度快”更有价值。如今趋势越来越表明，谁更理解系统、谁更擅长设定边界、谁更清楚错误最常从何处冒出，谁就更具优势。

第二，你今天就可以开始搭建自己的Harness。

无需等待什么行业标准。从最基础的元素开始：AGENTS.md文档、测试命令、禁止触碰区域、常见错误列表、验证方式。每次Agent犯错，就补充一条系统规则。

第三，新人不能完全跳过手写代码这一关。因为你必须先了解系统会如何出错，才知道护栏应该安装在何处。

在未来复杂项目中，真正的竞争很可能不是大模型对大模型。

而是大模型对大Harness。

模型会变得越来越强大，但若缺乏环境、反馈、验证和约束，再强大也会出现漂移、失控和腐化。

因此，读完这篇文章后，我最大的改变并非“我又学会了一套新的提示词”，而是我终于更清晰地认识到：

真正高级的工程，并非将经验仅留存于脑中，而是将经验写入赛道之中。