大家好，我是玄姐。

PS：

OpenClaw 火了，那么 OpenClaw 在企业如何落地？有哪些使用场景？具体的实践经验是什么？下周二会开场直播详细讲解，欢迎点击预约，直播见。

AI 的编程能力正在超越我们有效运用它的能力。这就是为什么各大模型在 SWE-bench 上的刷分，并没有转化为工程领导真正关心的生产力指标。

这个鸿沟不会一夜之间消失，它需要逐级攀登，共 8 个层级。每一层的跃升都会带来产出的质变，而且模型能力的每一次提升都会放大这些收益。

更值得关注的是多人协作效应：你的产出效率很大程度上取决于团队中最慢的那个人。如果你是 Level 7 的高手，能在睡梦中让后台 Agent 提交多个 PR，但如果你的同事还在 Level 2 手动审查代码，你的吞吐量就会被严重拖累。因此，提升整个团队的层级符合每个人的利益。

一、Level 1 & 2：代码补全与 Agent IDE

这是起点。GitHub Copilot 的 Tab 补全曾让经验丰富的开发者通过搭建代码骨架，让 AI 填充细节。但对于 Agentic Engineering 的新人来说，这个阶段往往被直接跳过。

Cursor 等 AI 原生 IDE 改变了游戏规则，将聊天与代码库连接，让多文件编辑变得简单。但天花板始终是上下文（Context）。模型只能看到它能看到的东西，而往往它要么没看到该看的，要么看了太多不该看的。

这个阶段的大多数开发者也在尝试各种"计划模式"（Plan Mode）：将模糊的想法转化为 LLM 的结构化执行步骤。这在早期是合理的控制手段，但在更高层级，我们对计划模式的依赖会越来越少。

二、Level 3：上下文工程（Context Engineering）

这是 2025 年的热门词汇。当模型能够可靠地遵循合理数量的指令并配合恰到好处的上下文时，上下文工程就变得至关重要。

噪声上下文和欠指定上下文同样糟糕。关键在于提高每个 token 的信息密度，"每个 token 都要为它在提示词中的位置而战"。

在实践中，上下文工程比你想象的涉及面更广：

• 系统提示词和规则文件（.cursorrules、CLAUDE.md）

• 工具描述的方式（模型通过描述决定调用哪个工具）

• 管理对话历史，防止长会话中的"失忆"

• 决定每轮暴露哪些工具（太多选项会压垮模型，就像压垮人一样）

现在上下文工程的说法变少了，因为新型模型对噪声更宽容，上下文窗口也更大。但在以下场景它依然关键：

• 小模型：语音应用常用小模型，上下文大小直接影响首 token 延迟

• 高 token 消耗的工具：Playwright MCP、图像输入会快速消耗 token，让你在 Claude Code 中提前进入"紧凑会话"模式

• 拥有数十个工具的 Agent：模型可能花费更多 token 解析工具 schema 而非实际工作

核心转变：从"过滤掉坏上下文"转向"确保正确的上下文在正确的时间出现"。

三、Level 4：复利工程（Compounding Engineering）

上下文工程优化当前会话，复利工程则优化未来的每一个会话。

这是由 Kieran Klaassen 推广的概念，让很多人意识到"氛围编程"（Vibe Coding）不仅能做原型。

这是一个计划-委派-评估-固化的循环：

• 计划：提供足够上下文让 LLM 成功

• 委派：让 Agent 执行

• 评估：检查结果

• 固化：记录经验，什么有效、什么出错、下次遵循什么模式

固化步骤是关键。LLM 是无状态的，如果你昨天刚移除一个依赖，除非你明确告诉它，否则明天它会重新引入。

最常见的固化方式是更新 CLAUDE.md（或等效规则文件），让经验融入未来会话。但要注意：不要把所有内容都塞进规则文件，指令过多等于没有指令。

更好的做法是创建让 LLM 能自主发现上下文的环境，比如维护一个随时更新的 docs/文件夹（Level 7 会详述）。

复利工程的实践者对输入 LLM 的上下文极度敏感。当 LLM 犯错时，他们本能地思考缺失的上下文，而非质疑模型能力。这种本能是让 Level 5-8 成为可能的基础。

四、Level 5：MCP 与 Skills

Level 3-4 解决"上下文"问题，Level 5 解决"能力"问题。

MCP（Model Context Protocol）和自定义 Skills 让 LLM 能访问数据库、API、CI 流水线、设计系统、Playwright 浏览器测试、Slack 通知等。模型不再只是"思考"代码库，而是能"操作"代码库。

实践案例： 作者的团队共享一个 PR 审查 Skill，它会根据 PR 性质条件启动子 Agent：

• 集成安全：检查数据库集成安全性

• 复杂度分析：标记冗余或过度工程

• Prompt 健康检查：确保 Prompt 遵循团队标准格式

• 运行 linter 和 Ruff

为什么要在审查 Skill 上投入这么多？因为当 Agent 开始批量产出 PR 时，人工审查成为瓶颈，而非质量门禁。Latent Space 的观点是：传统的代码审查已死，自动化、一致性的 Skill 驱动审查正在取代它。

MCP vs CLI 的趋势：越来越多团队让 LLM 使用 CLI 工具而非 MCP，原因是 token 效率。MCP 服务器每轮都会将完整工具 schema 注入上下文，无论是否使用。而 CLI 只将相关输出带入上下文。作者大量使用 agent-browser 而非 Playwright MCP 正是为此。

关键提醒：Level 3-5 是后续所有层级的基础。如果上下文嘈杂、提示词欠指定、工具描述糟糕，Level 6-8 只会放大混乱。

五、Level 6：Harness 工程与自动化反馈循环

这是火箭真正开始发射的地方。

上下文工程是策展模型看到什么，Harness 工程则是构建让 Agent 无需人工干预就能可靠工作的完整环境、工具和反馈循环。

给 Agent 反馈循环，而不仅是编辑器。

OpenAI 的 Codex 团队将 Chrome DevTools、可观测性工具和浏览器导航接入 Agent 运行时，让它能截图、驱动 UI、查询日志、验证修复。给定一个 Prompt，Agent 能复现 bug、录制视频、实现修复，然后验证、开 PR、响应审查、合并，只在需要判断时升级。

作者团队构建了语音和聊天 Agent 用于技术支持，为此开发了 CLI 工具 converse，让任何 LLM 能与后端端点进行多轮对话。LLM 修改代码后，用 converse 在实时系统上测试对话并迭代。这些自我改进循环有时会持续数小时。

核心概念：反向压力（Backpressure）

自动反馈机制（类型系统、测试、linter、pre-commit hooks）让 Agent 能检测和纠正错误，无需人工干预。想要自主性，就需要反向压力，否则会沦为"垃圾制造机"。

安全层面也是如此：Vercel CTO 认为 Agent、生成的代码和密钥应处于不同的信任域，因为日志文件中的 Prompt 注入可能诱骗 Agent 泄露凭证。安全边界是一种反向压力，它限制 Agent 能做什么，而非仅限制它应该做什么。

两个关键原则：

• 为吞吐量设计，而非完美：如果要求每次提交都完美，Agent 会在同一 bug 上反复纠缠。更好的做法是容忍小的非阻塞错误，在发布前做最终质量把关。

• 约束 > 指令：步骤式提示（"先做 A，再做 B"）已过时。定义边界比给清单更有效，因为 Agent 会执着于清单而忽略清单外内容。更好的 Prompt 是："这是我要的，做到通过所有测试为止。"

六、Level 7：后台 Agent（Background Agents）

争议观点：计划模式正在消亡。

Claude Code 的创造者 Boris Cherny 今天仍有 80% 的任务从计划模式开始，但随着新一代模型的 one-shot 成功率持续提升，计划模式作为独立的人机协作步骤将逐渐消失。

不是因为计划不重要，而是因为模型已能自主做好计划。大前提：你必须完成了 Level 3-6 的工作。如果上下文干净、约束明确、工具描述清晰、反馈循环紧密，模型无需你审查就能可靠计划。否则你仍需 babysit。

后台 Agent 的关键在于：如果 Agent 能生成可靠计划并无需你签字就执行，它就能异步运行，让你去做其他事。这是从"我在多标签 juggling"到"工作在我不知情时发生"的关键转变。

Ralph 循环：一个反复运行编码 CLI 直到完成所有 PRD 条目的自主循环，每次迭代都生成带有干净上下文的新实例。但实现好的 Ralph 循环很难，PRD 的任何欠指定都会反噬。

你可以并行运行多个 Ralph 循环，但 Agent 越多，你越会发现时间花在协调、排序、检查输出上，你不再写代码，而成了中层管理者。你需要一个编排器 Agent 来处理调度，让你专注于意图而非后勤。

Dispatch 工具：作者构建的 Claude Code Skill，将你的会话变成指挥中心。你在干净的会话中，而工作者在隔离上下文中处理重活。调度器负责计划、委派和跟踪，保留你的主上下文窗口用于编排。

多模型策略：最好的工程团队不是由克隆人组成的。同理，用不同模型做不同事：Opus 实现、Gemini 探索研究、Codex 审查，累积输出强于任何单一模型。

关键：解耦实现者与审查者

同一模型实例实现和评估自己的工作是有偏见的，会忽略问题并声称所有任务完成。让不同模型（或不同 Prompt 的实例）做审查，信号质量会大幅提升。

CI 与 AI 的结合：一旦 Agent 能无人值守运行，就能从现有基础设施触发。比如：文档 Bot 在每次合并后重生成文档并提 PR 更新 CLAUDE.md；安全审查 Bot 扫描 PR 并开修复；依赖升级 Bot 真正升级包并运行测试，而非仅标记。

七、Level 8：自主 Agent 团队（Autonomous Agent Teams）

尚未有人完全掌握，但少数团队正在探索。这是活跃的边疆。

Level 7 是编排器 LLM 以 hub-and-spoke 模式调度工作者 LLM。Level 8 移除这个瓶颈，Agent 直接相互协调，认领任务、分享发现、标记依赖、解决冲突，无需通过单一编排器路由一切。

Claude Code 的实验性 Agent Teams 功能是早期实现：多个实例在共享代码库上并行工作，队友在各自上下文窗口中直接相互通信。Anthropic 用 16 个并行 Agent 构建了能从源码编译 Linux 的 C 编译器；Cursor 用数百个并发 Agent 运行数周，从零构建 Web 浏览器，并将自己的代码库从 Solid 迁移到 React。

但细看仍有裂缝：Cursor 发现没有层级时，Agent 变得风险厌恶并在无进展时空转；Anthropic 的 Agent 持续破坏现有功能，直到加入 CI 流水线防止回归。多 Agent 协调是难题，目前无人接近最优解。

作者认为模型对大多数任务的这种自主性级别尚未就绪，且即使够智能，它们仍太慢、太耗 token，在经济上不可行（除了编译器、浏览器构建等登月项目）。

对日常工作的 leverage，Level 7 才是当下的甜点。Level 8 终将成为主流模式，但现在应该把精力放在 Level 7（除非你是 Cursor，突破本身就是业务）。

八、Level ?：未来展望

一旦你能流畅编排 Agent 团队，界面就无需局限于文本。语音对语音（甚至思维对思维？）的交互，对话式 Claude Code，而不仅是语音转文本输入，是自然的下一步。

看着你的应用，口头描述一系列改动，然后看着它们在你眼前发生。

有一派人在追逐完美的一次性生成：陈述需求，AI 一次 pass 完美实现。问题在于这预设了人类确切知道自己要什么，我们从来不确切知道。软件始终是迭代的，只是会变得更容易、超越纯文本交互、速度更快。

九、结语：你在哪一级？

层级	关键特征	你的检查点
1-2	Tab 补全/Agent IDE	还在手动点击 Tab？
3	上下文工程	每个 token 都在战斗吗？
4	复利工程	你有 CLAUDE.md 或规则文件吗？
5	MCP & Skills	Agent 能操作数据库/发 Slack 吗？
6	Harness 工程	Agent 能自我修复吗？
7	后台 Agent	你睡觉时 Agent 在工作吗？
8	自主团队	多 Agent 直接对话吗？

所以：你在哪一级？你正在做什么来攀登下一级？

PS：

OpenClaw 火了，那么 OpenClaw 在企业如何落地？有哪些使用场景？具体的实践经验是什么？下周二会开场直播详细讲解，欢迎点击预约，直播见。

好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~

—1—

加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即预约！