本文介绍了Bassim Eledath提出的“代理工程成熟度模型”,将利用AI(特别是LLM)进行编码和工程实践的能力划分为8个连续层级。文章强调团队生产力的差距不在于模型能力,而在于驾驭模型的实践水平。提升层级能带来产出的复利增长,且团队协作效率取决于最短板成员的层级。文章为开发者提供了一张清晰的路线图,指明了如何从简单的AI辅助编码,一步步构建出能够自主协作的AI代理团队,从而实现生产力的指数级跃升。

引言

人工智能的编码能力正在超越我们有效驾驭它的能力。这就是为什么所有SWE-bench分数的飙升,并没有与工程领导层真正关心的生产力指标同步。当Anthropic的团队能在10天内交付像Cowork这样的产品,而另一个团队使用相同的模型却连一个破损的概念验证都无法推进时,其区别在于,前者已经弥合了能力与实践之间的鸿沟,而后者尚未做到。

这个鸿沟不会一夜之间消失。它需要分阶段跨越。一共8个层级。阅读本文的大多数人可能已经越过了前几个层级,并且应该渴望达到下一个层级,因为后续的每一个层级都代表着产出的巨大飞跃,而模型能力的每一次提升都会进一步放大这些增益。

你应该关注它的另一个原因是多人协作效应。你的产出在很大程度上取决于你队友所处的层级。假设你是一位7级 wizard,在你睡觉时,后台代理已经为你生成了几个高质量的PR。但如果你的仓库在合并前需要一位同事的批准,而这位同事还处于2级,仍在手动审查PR,那这就会严重制约你的效率。所以,提升你团队的整体水平对你也有利。

通过与几个团队和许多实践AI辅助编程的个体交流,我观察到以下层级演进过程,虽然顺序并非绝对严格:

第1级和第2级:Tab 补全与智能体 IDE

一切都始于GitHub Copilot 和代码补全。点击Tab键,自动完成代码。可能很多人已经淡忘了,而新进入代理工程领域的人则完全跳过了这一级。这种方式偏爱经验丰富的开发者,他们能在AI填充细节之前熟练地搭好代码骨架。

像Cursor这样以AI为中心的IDE改变了游戏规则,它将聊天功能与你的代码库连接起来,使多文件编辑变得异常简单。但天花板始终是上下文。模型只能根据它能看到的内容提供帮助,而令人恼火的是,它要么看不到正确的上下文,要么看到了太多错误的上下文。

处于这一层级的大多数人也在他们选择的编码代理中尝试“计划模式”:将一个粗略的想法转化为结构化的逐步计划给LLM,迭代优化这个计划,然后触发执行。在这个阶段,它运行良好,也是保持控制的一种合理方式。不过,在后面的层级中,我们会看到对计划模式的依赖会减少。

第3级:上下文工程

在2025年成为热门词汇的上下文工程,是在模型能够可靠地遵循合理数量的指令并拥有恰到好处的上下文时兴起的。嘈杂的上下文和模糊的上下文一样糟糕,因此努力的方向是提高每个令牌的信息密度。“每个令牌都需要为它在提示词中的位置而战”成为当时的信条。

在实践中,上下文工程触及的领域比人们意识到的要广。它关乎你的系统提示词和规则文件(如 .cursorrules, CLAUDE.md)。它关乎你如何描述你的工具,因为模型会读取这些描述来决定调用哪个。它关乎管理对话历史,以确保一个长时间运行的代理在十轮对话后不会迷失方向。它甚至关乎决定每轮对话暴露哪些工具,因为过多的选项会让模型不堪重负,就像它们会让人类不堪重负一样。

如今,关于上下文工程的讨论不多了。天平已经倾向于那些能够容忍更嘈杂上下文并在更混乱的环境中推理的模型(更大的上下文窗口也功不可没)。尽管如此,留意什么会消耗上下文仍然很重要。这里有几个例子说明它依然重要:

  • 较小的模型对上下文更敏感。语音应用通常使用较小的模型,而上下文大小也与首个令牌生成时间相关,这会影响延迟。
  • 令牌消耗大的工具和模态。像Playwright这样的MCP(模型上下文协议)和图像输入会快速消耗令牌,让你在Claude Code中比预期更快地进入“会话紧凑”状态。
  • 拥有数十种工具的代理,模型花费在解析工具模式上的令牌比做有用工作的还多。

更广泛的观点是,上下文工程并未消失,它只是进化了。重点已从过滤掉糟糕的上下文转变为确保在正确的时间出现正确的上下文。这一转变引出了第4级。

第4级:复利工程

上下文工程优化的是当前会话。而复利工程优化的是之后的每一次会话。由Kieran Klaassen推广开来的复利工程,对我和许多其他人来说都是一个转折点,它让我们意识到“氛围编码”能做的远不止原型设计。

它是一个 计划、委托、评估、固化 的循环。你为任务提供足够的上下文,确保LLM能成功。你委托任务。你评估输出。然后,最关键的是,你固化你所学到的东西:哪些有效,哪些出错,下次应遵循什么模式。

这个“固化”步骤正是使其产生复利效应的关键。LLM是无状态的。如果它们昨天 reintroduced 一个你明确移除的依赖项,除非你明确告知不要这样做,否则它们明天还会重复。关闭这个循环最常见的方法是更新你的 CLAUDE.md(或等效的规则文件),这样学到的教训就能融入未来的每一次会话。需要提醒的是:将所有东西都固化到规则文件中的本能可能会适得其反(过多的指令等于没有指令)。更好的做法是创造一个让LLM能轻松自行发现有用上下文的环境,例如维护一个最新的 docs/ 文件夹(更多内容见第7级)。

复利工程的实践者通常对他们输入给LLM的上下文高度敏感。当LLM犯错时,他们本能地会先想到上下文是否缺失,而不是责怪模型的能力。这种本能正是实现第5到8级的基础。

第5级:MCP与Skills

第3级和第4级解决的是上下文问题。第5级解决的是能力问题。MCP和Skills让你的LLM能够访问你的数据库、API、CI流水线、设计系统、用于浏览器测试的Playwright、用于通知的Slack等。模型现在不仅能思考你的代码库,还能对其采取行动

关于MCP和Skills的优质资料已经很多,我就不赘述它们是什么了。但这里分享一些我使用它们的例子:我的团队共享一个PR审查技能,我们都(并且仍在)对其迭代。这个技能会根据PR的性质有条件地启动子代理。一个子代理负责处理与数据库的集成安全性。另一个运行复杂度分析,标记冗余或过度工程。还有一个检查提示词的健康状况,确保我们的提示词符合团队的標準格式。它还会运行linter和Ruff。

为什么要在审查技能上投入这么多?因为当代理开始大量生成PR时,人工审查变成了瓶颈,而不是质量把关。Latent Space提出了一个有力的观点:我们所知的代码审查已经消亡。取而代之的是自动化、一致、由技能驱动的审查。

在MCP方面,我使用Braintrust MCP,这样我的LLM就可以查询评估日志并直接进行修改。我使用DeepWiki MCP,让我的代理无需手动拉取就能访问任何开源仓库的文档。

当团队中有多个人开始编写相同技能的各自版本时,就该将它们整合到一个共享注册中心了。Block(默哀)有一篇很棒的文章讲述了这一点:他们建立了一个内部技能市场,拥有超过100个技能,并为特定角色和团队策划了捆绑包。技能得到了与代码同等的待遇:拉取请求、审查、版本历史。

还有一个值得指出的趋势:LLM使用CLI工具而非MCP正变得普遍(似乎每个公司都在推出自己的CLI:Google Workspace CLI,Braintrust也即将推出一个)。原因是令牌效率。MCP服务器会在每一轮交互中将完整的工具模式注入上下文,无论代理是否使用它们。CLI则反过来:代理运行一个有针对性的命令,只有相关的输出进入上下文窗口。正是出于这个原因,我大量使用 agent-browser,而不是使用Playwright MCP。

在我们继续之前有一点要说。第3到5级是所有后续内容的基石。LLM在某些方面出奇地好,在另一些方面则出奇地差,在堆叠更多自动化之前,你需要培养一种直觉,去感知这些能力的边界在哪里。如果你的上下文嘈杂、提示词定义不足或错误、或者工具描述不清,那么第6到8级只会放大混乱。

第6级:驾驭工程与自动化反馈循环

Harness Engineering

这是火箭真正开始起飞的地方。

上下文工程是关于策展模型所见的内容。而驾驭工程是关于构建完整的环境、工具和反馈循环,让代理能够在无需你干预的情况下可靠地工作。给代理反馈循环,而不仅仅是编辑器。

OpenAI的Codex团队将Chrome DevTools、可观测性工具和浏览器导航集成到代理运行时中,使其能够截取屏幕截图、驱动UI路径、查询日志并验证自己的修复。给定一个简单的提示,代理可以重现一个bug,录制视频,并实施修复。然后它通过驱动应用进行验证,开启一个PR,响应审查反馈,并合并,仅在需要判断时才上报。代理不仅仅编写代码。它能看见代码产生的结果,并像人类一样对其迭代。

我的团队为技术故障排查构建语音和聊天代理,所以我创建了一个名为 converse 的CLI工具,它允许任何LLM与我们的后端端点聊天,进行逐轮对话。LLM进行代码更改,使用 converse 在实时系统上测试对话,并进行迭代。有时这种自我改进的循环会持续运行数小时。当结果是可验证的时候,这种方法尤其强大:对话必须遵循这个流程,或者在这些情况下调用这些工具(例如,升级到人工代理)。

实现这一点的关键概念是背压:自动化的反馈机制(类型系统、测试、linters、预提交钩子),让代理能够在无需人工干预的情况下检测并纠正错误。如果你想要自主性,就需要背压。否则你最终得到的只会是一台垃圾制造机。这也延伸到安全领域。Vercel的CTO提出,代理、它们生成的代码以及你的秘密应该存在于独立的信任域中,因为如果所有东西共享同一个安全上下文,隐藏在日志文件中的提示注入可能会诱骗代理泄露你的凭证。安全边界就是一种背压:它们约束了代理在失控时能做什么,而不仅仅是它应该做什么。

这里有两点很有帮助:

  • 为吞吐量而非完美而设计。当每次提交都要求完美时,代理会卡在同一个bug上,并相互覆盖对方的修复。最好容忍小的、非阻塞的错误,在发布前做最终的质量检查。我们对人类同事也是这么做的。
  • 约束优于指令。逐步提示(“做A,然后B,然后C”)正变得越来越过时。根据我的经验,定义边界比给出检查清单效果更好,因为代理会固守清单而忽略清单之外的任何东西。更好的提示是:“这是我要的,你一直做,直到通过所有这些测试。”

驾驭工程的另一半是确保代理无需你就能浏览你的仓库。OpenAI的方法是:保持 AGENTS.md 大约100行,作为指向其他地方结构化文档的目录,并将文档的新鲜度纳入CI流程,而不是依赖会过时的临时更新。

一旦你构建了所有这些,一个自然的问题就浮现出来:如果代理可以验证自己的工作、浏览仓库并自行纠正错误,那你为什么还需要坐在椅子上呢?

提醒一下,对于处于早期层级的朋友,下一部分可能听起来有些陌生(但可以收藏起来,以后再看)。

第7级:后台智能体

有一个大胆的观点:计划模式正在消亡

Claude Code的创建者Boris Cherny如今仍有80%的任务是从计划模式开始的。但随着每一代新模型的推出,计划后的一次性成功率持续攀升。我认为我们正接近这样一个临界点:计划模式作为一个独立的人工介入步骤将逐渐消失。不是因为计划不重要,而是因为模型已经足够优秀,可以自行很好地规划。一个重要的前提是:你必须已经完成了第3到6级的工作。如果你的上下文清晰,约束明确,工具描述得当,反馈循环紧密,那么模型无需你事先审查就能可靠地规划。如果你没做这些工作,那你仍然需要盯着计划。

澄清一下,计划作为一种通用实践不会消失。它只是在改变形态。对于新实践者来说,计划模式仍然是正确的切入点(如第1、2级所述)。但对于第7级的复杂功能,“计划”看起来不再像是编写逐步大纲,而更像是探索:探查代码库,在工作树中制作原型,绘制解决方案空间。而且,越来越多的后台代理正在为你进行这种探索。

这一点至关重要,因为它正是解锁后台代理的关键。如果一个代理能够生成可靠的计划并执行,无需你签字同意,那么它就可以在你做其他事情时异步运行。这是从“我同时处理多个标签页”到**“工作在我之外发生”**的关键转变。

Ralph循环是一个流行的切入点:一个自主代理循环,反复运行编码CLI,直到完成所有的PRD条目,每次迭代都会产生一个带有清晰上下文的新实例。根据我的经验,正确实现Ralph循环很难,PRD中任何规定不足或错误的地方都会反咬一口。它有点“一劳永逸”的感觉。

你可以并行运行多个Ralph循环,但启动的代理越多,你就越能注意到你的时间实际花在了哪里:协调它们、安排工作顺序、检查输出、推动进展。你不再编写代码。你成了一个中层经理。你需要一个协调代理来处理调度,这样你就可以专注于意图,而不是后勤。

为此我一直在大量使用的工具是 Dispatch,这是我为Claude Code构建的一个技能,它把你的会话变成一个指挥中心。你待在一个干净的会话中,而工作进程在隔离的上下文中完成繁重的工作。调度员负责计划、委派和跟踪,因此你的主上下文窗口得以保留,用于统筹协调。当某个工作进程卡住时,它会提出一个澄清问题,而不是默默失败。

Dispatch在本地运行,这使其非常适合需要贴近工作的快速开发:反馈更快,交互式调试更容易,且没有基础设施开销。Ramp’s Inspect 则是一种互补的方法,适用于运行时间更长、更自主的工作:每个代理会话在云端沙箱化的虚拟机中启动,包含完整的开发环境。产品经理发现一个UI bug,在Slack中标记,Inspect就会在你的笔记本电脑合上时接手并处理它。其代价是操作复杂性(基础设施、快照、安全性),但你能获得本地代理无法比拟的规模和可重复性。我的建议是两者都用(本地和云端后台代理)。

在这个层级,一个出奇强大的模式是:为不同的工作使用不同的模型。最优秀的工程团队不是由克隆人组成的。他们由经历各异、带来不同优势、思考方式不同的人组成。同样的逻辑也适用于LLM。这些模型经过不同的后训练,有着截然不同的“秉性”。我经常派遣Opus负责实施,Gemini负责探索性研究,Codex负责审查,这样累积的产出比任何单一模型单独工作都要强大。可以把它想成是“群体的智慧”,但应用于代码。

至关重要的是,你还需要将实施者与审查者解耦。我已经吃过太多次苦头才明白这一点:如果同一个模型实例既实施又评估自己的工作,它会带有偏见。它会掩盖问题,并告诉你所有任务都完成了,而实际上并没有。这不是恶意,就像你不会给自己的考卷打分一样。让一个不同的模型(或一个带有审查专用提示词的不同实例)来进行审查。你的信号质量会大幅提升。

后台代理也为将你的CI与AI结合打开了闸门。一旦代理可以在没有人类参与的情况下运行,就可以从你现有的基础设施触发它们。一个文档机器人,在每次合并时重新生成文档,并提出一个PR来更新 CLAUDE.md(我们就是这么做的,省时省力)。一个安全审查机器人,扫描PR并开启修复。一个依赖机器人,实际上能升级包并运行测试套件,而不仅仅是标记它们。优秀的上下文、复利规则、强大的工具、自动化的反馈循环,现在所有这些都在自主运行。

第8级:智能体团队

还没有人完全掌握这个层级,尽管有少数团队正在探索。这是活跃的前沿领域

在第7级,你有一个协调LLM,以中心辐射模式向工作LLM分派任务。第8级移除了这个瓶颈。代理之间直接相互协调,认领任务,分享发现,标记依赖关系,解决冲突,而无需将所有事情都通过一个单一的协调者路由。

Claude Code的实验性功能 Agent Teams 是一个早期实现:多个实例在一个共享代码库上并行工作,队友们在自己的上下文窗口中操作,并直接相互通信。Anthropic使用了16个并行代理从头构建了一个可以编译Linux的C编译器。Cursor则运行了数百个并发代理长达数周,从头构建了一个网页浏览器,并将他们自己的代码库从Solid迁移到了React。

但仔细观察,你会发现其中的不完美。Cursor发现,没有层级结构,代理会变得规避风险,毫无进展地空转。Anthropic的代理不断破坏现有功能,直到添加CI流水线来防止回归。在这个层级进行实验的每个人都说同样的话:多代理协调是一个难题,目前还没有人接近最优解

老实说,我认为对于大多数任务来说,模型还没有为这种程度的自主性做好准备。即使它们足够聪明,对于编译器、浏览器构建这样的登月项目之外的日常工作来说,它们仍然太慢消耗令牌太多,经济上不划算(虽然令人印象深刻,但远非清晰明确)。对于我们大多数人日常所做的工作来说,第7级才是产生最大杠杆作用的地方。如果最终第8级成为主流模式,我不会感到惊讶,但现在,我会把我的精力集中在第7级(除非你是Cursor,并且这项突破就是你的核心业务)。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线科技企业深耕十二载,见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事,早已在效率与薪资上形成代际优势,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包

  • ✅ 从零到一的 AI 学习路径图
  • ✅ 大模型调优实战手册(附医疗/金融等大厂真实案例)
  • ✅ 百度/阿里专家闭门录播课
  • ✅ 大模型当下最新行业报告
  • ✅ 真实大厂面试真题
  • ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ,朋友们如果有需要 《AI大模型入门+进阶学习资源包》下方扫码获取~
在这里插入图片描述

① 全套AI大模型应用开发视频教程

(包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点)
在这里插入图片描述

② 大模型系统化学习路线

作为学习AI大模型技术的新手,方向至关重要。 正确的学习路线可以为你节省时间,少走弯路;方向不对,努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划,带你从零基础入门到精通!
在这里插入图片描述

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档,我精选了一系列大模型技术的书籍和学习文档(电子版),它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。
在这里插入图片描述

④ AI大模型最新行业报告

2025最新行业报告,针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。
在这里插入图片描述

⑤ 大模型项目实战&配套源码

学以致用,在项目实战中检验和巩固你所学到的知识,同时为你找工作就业和职业发展打下坚实的基础。
在这里插入图片描述

⑥ 大模型大厂面试真题

面试不仅是技术的较量,更需要充分的准备。在你已经掌握了大模型技术之后,就需要开始准备面试,我精心整理了一份大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余

图片

以上资料如何领取?

在这里插入图片描述

为什么大家都在学大模型?

最近科技巨头英特尔宣布裁员2万人,传统岗位不断缩减,但AI相关技术岗疯狂扩招,有3-5年经验,大厂薪资就能给到50K*20薪!

图片

不出1年,“有AI项目经验”将成为投递简历的门槛。

风口之下,与其像“温水煮青蛙”一样坐等被行业淘汰,不如先人一步,掌握AI大模型原理+应用技术+项目实操经验,“顺风”翻盘!
在这里插入图片描述
在这里插入图片描述

这些资料真的有用吗?

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理,现任上海殷泊信息科技CEO,其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证,服务航天科工、国家电网等1000+企业,以第一作者在IEEE Transactions发表论文50+篇,获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目,无论你是小白还是有些技术基础的技术人员,这份资料都绝对能帮助你提升薪资待遇,转行大模型岗位。
在这里插入图片描述
在这里插入图片描述

以上全套大模型资料如何领取?

在这里插入图片描述

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐