Coding Agent 技术全景图：Context Engineering Subagents 与 Harnes...

编译｜宇琪

策划 | Tina

一年前，行业还在为“从自动补全到 Agent”的进化感到兴奋。然而一年过去，我们不难发现单纯靠“Vibe Coding”和“Prompt 调优”，面对非确定性模型带来的风险和成本问题，显然无法撑起企业级软件开发。

近日，Thoughtworks 的全球 AI 辅助软件交付负责人 Birgitta Böckeler 在 QCon 纽约站进行演讲，深度解析了过去一年 Coding Agent 领域的范式转移：从如何通过 Skills 和 Subagents 精准调控上下文，到如何在云端实现低监督甚至无监督的自主开发，再到最核心的问题：我们如何构建一套确定性的 Harness 作为安全网，来约束非确定性的模型产出？基于该演讲视频，InfoQ 对内容进行了整理。

核心观点如下：

• Context Engineering 正在变成一个非常强的“放大器杠杆”，而且这种放大是双向的：既能放大好的工程实践，也同样会放大坏的结构问题。

• 风险评估永远都离不开三个维度：概率、影响、可检测性。也就是：它出错的概率有多大？如果出错，后果有多严重？以及你能不能发现它出了错？

• 把原本为人类设计的工程约束系统，改造成 agent 可学习、可反馈、可优化的系统，这可能才是 Context Engineering 真正开始变得“工程化”的地方。

• 也许未来我们不再靠传统服务模板起步，而是一个 Harness 模版，实例化之后就能支撑我们的代码库。到那时候，我们可能甚至不在乎到底是 React 还是 Vue，决策维度可能会变成“有没有现成的 Harness，这样我就不用操心、不用从头搭了”。

Context Engineering 的演进

我去年也来过 QCon，当时演讲题目叫《From Autocomplete to Agents》，主要聊的是当时大家刚开始关注的新 agentic 模式："vibe coding"这个词大概才出现了两个月，MCP 正在风口上，Claude Code 还在襁褓里。现在我想回头看看，过去这一年里发生了什么。

有一件事演进得很快，那就是 Context Engineering。这个词去年 QCon London 的时候压根不存在，大概六月才开始流传起来。最简单的定义就是：你希望精心筛选你的模型或 agent 能看到的信息，从而获得更好的结果。定义听起来很简单，但具体到不同场景，比如构建 agent，或者使用 coding agent，它会演化出很多不同含义，而今天我主要会从 coding agent 的角度来讲。

一年前的 Context Engineering，基本就是 rules files，你在工作区放一个 AGENTS.md、CLAUDE.md，每次打开会话，agent 就会收到这个文件。常见的坑、老是重复犯的错，都可以写进去。我当时有个情况就是 agent 每次跑 Python 进程都忘记激活虚拟环境，这种事情就可以写进文件里。MCP servers 那时候也有了，可以帮 agent 更动态地获取数据。

这一年之间，出现了所有这些东西：不光是 rules 和 MCP servers，还有 commands、skills、subagents、plugins、specs……这个领域非常热闹。

我重点讲其中一个，因为我觉得很多人对它是困惑的。我去年底休了个假，回来之后发现 skills 出来了，我一开始也完全搞不清楚它到底是什么意思。

Skills

Skills 是 Anthropic 基于社区里很多已有实践推出的新概念，主要做三件事。

第一，帮你把 rules 模块化，你不用把所有东西塞进一个大文件，然后每次全量发给 agent，而是可以按功能拆成小的子文件夹，比如"这是我们通常构建 React 组件的方式"、"这是你从 AWS 测试环境里拉日志的方法"，都可以分别定义。

第二，这些模块可以被 LLM 按需即时加载。这种渐进式的、惰性加载的 context 很重要。agent 只会先看到一个 skill 的简短描述，比如这里有一个 get-log skill，描述可能只是：“从测试环境获取日志，用于 incident debugging。”然后，当 LLM 判断：“现在这个场景似乎需要这个能力，而且这里还有更多相关信息”，它才会真正加载这个 skill。这样一来，你不会在 session 一开始就把 context window 塞爆。

再往下，skill 不只是一个 Markdown 文件。它其实是一个文件夹。里面除了文档，还可以放脚本，让 agent 直接执行。严格来说，这件事以前也能做，但现在越来越多人意识到：你完全可以在 Markdown 里直接告诉 agent 去调用你机器上已经安装好的 CLI 工具。这种思路出现之后，很多人在 agentic coding 场景里，开始把大量 use case 从 MCP 转移出来，重新关注：“我电脑上已经有哪些 CLI？”“我能不能直接写脚本让 agent 调用？”因为相比再额外维护一种后台进程，这种方式简单直接得多。

所谓 Context Engineering，本质上是几件事情的组合。第一，当然还是那些可复用的 instructions 和 conventions。比如怎么写 React component、怎么 bootstrap 一个新项目、代码规范是什么等等。第二，是各种“context interfaces”。比如 skill 的 description、MCP server 暴露的 tool 列表、coding agent 内建的 tool 列表。LLM 会基于这些接口判断：“这个场景里我要调用哪个 tool？加载哪个 skill？连接哪个 MCP server？”

核心问题其实始终是：你如何让这些信息被智能地、按需地加载。这里面永远存在 不确定性，你永远无法保证 LLM 一定会加载你设计好的 skill。于是，作为人类开发者，我的工作开始越来越像“context 管理员”。我要管理 context，也要监控 context 的大小。

虽然现在 context window 在技术上比一两年前大了很多，但一旦塞得太满，agent 的效果会明显下降，而且成本也会大幅上升，因为每次和模型来回交互，都要把整个 context window 发过去。

现在很多 coding agent 已经开始提供 context monitoring 功能，你甚至能看到“到底是什么东西在占空间”。比如左边这个 Claude Code 的截图，是我刚开启 session 不久时截的。明明我还没输入多少内容，context window 已经用了 15%。因为里面已经包含了 Claude Code 的 system prompt、skills、各种 context interfaces 等等。所以，当你设计 skills、给 agent 配置能力时，也必须开始思考“上下文预算”。右边 GitHub Copilot 现在也开始加入类似功能了。

目前来看，Claude Code 团队基本还是整个行业的领跑者，然后其他人再跟着复制他们做的东西，这算是我对现状的一个高层总结。

Subagents

还有一个我认为同样属于 Context Engineering 的强大能力：subagents。这个概念也是去年开始真正流行起来的，现在很多 coding agent 都已经内建支持。它的核心思想是：主 agent 可以派生出子 agent。

最常见、甚至很多时候用户都没显式控制的场景，是 agent 在 session 开始时需要研究代码库结构，它通常会自动派生一个 subagent 去做这件事。右下角这个 Claude Code 截图里，就有一个 Explore agent。因为“研究代码库”本身会消耗大量 token，它需要读很多文件、筛选哪些和任务相关，所以把这件事交给 subagent 很合理。subagent 最后只把结果汇报回主 session，而不会把所有中间噪音全塞进主 context。

你自己也可以主动使用 subagents。一个特别常见的用法，是专门创建 code review agent。很多人喜欢让一个“没有历史上下文污染”的独立 context window 来做 code review；甚至还会让它使用不同模型，这个能力其实解锁了很多后面会继续演化的新工作流。

在 Context Engineering 这块，我想提几个值得思考的问题。

第一，你想放大哪些编码规范？因为 AI 本质上就是“放大器”，好的会放大，坏的也会放大，你得小心。

第二，你能否基于这些能力，构建现代化迁移的工作流？迁移本就是生成式 AI 特别擅长的场景，而现在有了 subagents、skills、MCP servers 这些能力之后，这类流程已经越来越容易工程化。我最近跟一个同事聊过，她的客户有几千个 CI/CD pipeline 在旧工具里，需要迁移到 GitHub Actions，她就在构建一个带人工监督、包含不同 subagents、skills、MCP servers 的工作流。

第三，组织里应该开放哪些工具，让 agent 更容易执行操作或获取信息？可以是 CLI，可以是 MCP servers，也可以是语言服务器。尤其是一些比较小众的编程语言场景，如果你能给 agent 提供真正理解语言机制的工具，而不只是纯文本上下文，效果会差很多。

还有一个问题也很重要：你到底想让 AI 放大哪些“实践”？我最喜欢的例子是改善架构决策记录、怎么做威胁建模，这些东西其实也完全可以被封装成 skills，帮助团队把优秀工程实践标准化。

开放问题也不少。首先，所谓 Context Engineering，其实那个“engineering”多少还带着引号。比如：这些东西怎么版本管理、怎么分发？现在已经开始出现一些插件市场，同样是 Anthropic 和 Claude Code 团队推动的，但还不够成熟，都在演化中。

另外一个大问题是，你加进去的 context 到底是让结果变好了还是变差了？这就涉及 evals，也就是如何评估 skills 的效果。Anthropic 最近发布了一些工具让 evals 更容易做，skills registry 平台 Tessl 也发了新东西，但都还在早期阶段。

越来越少的人类监督

随着模型能力的持续提升和 Context Engineering 越来越成熟，有一个明显的趋势：给 agent 更多自主权，减少人工监督。这大概也是所有 hype 最核心的问题：“AI 到底什么时候才能独立把代码全写完？”

所谓 supervised 模式，就是开发者依然坐在 session 前面，持续观察 agent 在干什么、不断介入、不断纠偏，双方高频来回协作。而 unsupervised 模式，则更像“把任务直接丢出去”。这张截图来自去年年中 OpenAI 的 Codex 刚发布的时候。当时大家第一次看到所谓 cloud agents：你把任务发到云端，然后 agent 在那边自己跑 20 分钟，甚至更久，回来再给你结果。

到了今天，几乎所有主流 coding agent 产品，都已经支持这种模式了。agent 不再只是本地 IDE 里的辅助工具，它们也开始在云端工作，如今你甚至还能直接在手机上操作这些东西。所以真的已经开始有人在通勤路上写代码了——前提是他们还需要通勤的话。

另一个推动力是 CLI 版编程助手的兴起。现在几乎所有大产品，都开始推出命令行版本：Cursor CLI、Copilot CLI，当然第一个真正引爆关注的还是 Claude Code。而一旦这些 agent 能以 headless mode 运行，你就可以把它们直接接入现有 pipeline 系统，比如现在已经有 Claude Code 的 GitHub Actions，Copilot 也有类似集成。

随之回来的是一个老朋友：沙箱。得给 agent 一个合适的环境，得想办法把它的工具、编译器、开发依赖都搞定。“Out of memory error“ 只是表象，核心是资源配给的问题。CI/CD 里的 internet access 也不简单，dev sandbox 的权限边界、agent 加载不可信 web 内容时遇到的 prompt injection 风险……有些是新问题，有些是本来就有的挑战。

不只云端，本地使用上减少监督的趋势也存在。这是 Steve Yegge 那个 Gas Town 博客里的一张图，叫《开发者进化为 AI 的 8 个阶段》。Stage 6 是同时跑 3 个 Claude Code 实例，Stage 7 是同时跑 10 个。我试过跑 3 个，真的是太多了，我老是把内容敲到错误的窗口里。但确实已经有一些团队开始这么工作了。

Agent Swarms

而最后那张图，也就是所谓“stage 8，则可以算是当前最新一轮 hype 的一个缩影，我姑且把它称作“agent swarms”。Gas Town 就是一个例子，还有一个叫 Claude Flow 的项目，其实已经存在挺久了，只是最近好像改了名字。最近 Cursor 和 Anthropic 也分别做了两个实验，引发了巨大关注。

Agent swarms 基本就是，你派出大量 agent，几十个甚至几百个。尽可能多地往墙上扔，看什么东西能粘住，观察有没有涌现出新的行为，怎么协调这些 agent 等等。

Cursor 和 Anthropic 的那两个实验，确实让很多人开始紧张。Cursor 让一群 agent 跑了大概一周来构建浏览器，Anthropic 让它们构建 C 编译器。于是很多人开始惊呼：“AI 已经能独立构建这些东西了吗？”

但这里有个非常重要的背景必须意识到：这两个任务，其实都属于“高度可定义”的问题。而且我怀疑，他们也是故意挑这种任务来做展示的。Cursor 自己其实也承认过，他们是有意选择这个方向。因为无论是浏览器还是 C 编译器，它们的 specification 在互联网上到处都是。尤其 C 编译器这个场景，还有极其成熟、庞大的测试套件。agent 可以不断运行测试，通过反馈判断自己是不是做对了。

而这恰恰是企业软件开发里经常缺失的东西。我们并没有那种级别的 specification，也没有那种级别的自动反馈系统。所以，我并不觉得你一定要立刻跑去尝试 Gas Town，至少对于大多数企业开发环境来说，现实问题完全不是一个量级。但如果你想稍微“试探一下水温”，有一种更务实的方法：Claude Code 有个还在 preview 的功能叫 agent teams。

有些人把 agent teams 和 swarms 当一回事，我倾向于把它们看成两个不同的概念。swarms 是扔出几十上百个 agent，甚至由 AI 决定用哪些；teams 则更克制一些。比如这里，我只用了五个 agent。核心问题在于 orchestration（编排），主 agent 需要决定哪些任务可以并行；不同 agent 之间还能互相通信、交换结果等等。但总体来说，这一切都还非常早期。

如何衡量监督程度

先稍微回到现实一点的话题，“减少监督”这件事本身。有几个问题，我觉得每个团队现在都应该开始认真思考。

第一，在哪些场景下你愿意拿云端 agent 或低监督 agent 做实验？不同组织的环境差异很大。有些团队可能完全无法承受高风险实验。但即便如此，你依然可以从一些低风险场景开始，比如清理 feature toggles。很多团队现在也会用 AI 做 code review 之类的工作。

第二，你怎么判断一个任务需要多少监督？更进一步说，你又该如何帮助组织里的其他人建立这种判断能力？

我发现自己在用 AI 的时候，一直在做各种小型、有时是较大型的风险评估：“这个任务该不该交给 AI？”“应该让它做到什么程度？”“我要 review 到多细？”风险评估永远都离不开三个维度：概率、影响、可检测性。也就是：它出错的概率有多大？如果出错，后果有多严重？以及你能不能发现它出了错？

在 AI 编程这个场景里，我首先会评估：AI 出错的可能性有多大。这个概率，通常来自几个因素，包括：我对当前上下文的理解程度；我对这个工具能力边界的了解；以及我过去在类似任务里使用它的经验，这是一种需要时间积累的直觉，还包括我对自己的需求有多大把握，我到底能不能把一个需求说清楚。第二，如果 AI 搞错了，影响有多大？取决于使用场景的重要性。是 PoC 或者 spike？还是那种会让我周末凌晨两点被电话叫起来的核心流程、是我在 on-call？第三，可检测性，我能不能发现 AI 搞错了？这里面全是我对自己的反馈循环有多了解。

评估完之后，我就决定用什么工作流：是非常精细的、开头要先做大量规划的，还是直接扔一个 prompt 就上？这也决定我审查多少：是完全 vibe coding，一眼都不看，还是逐行检查，还是在中间的某个点？还要决定我放手让它跑多久不去管，因为跑得越久，事后要回顾验证的内容就越多。

如果你仔细看这整个判断过程，其实真正“全新”的部分，只有我现在标黄的这一块“你对 AI 在某类任务上的真实能力到底有多了解”。其余能力，其实成熟开发者本来就应该具备。我们真正需要强化的，是这一项新的能力。某种意义上，这有点像游乐园里的那句提示：“你得长到这个高度，才能坐过山车。”在 AI 开发里也是一样：你得具备足够判断力，才有资格减少监督。

AI 出错的概率，在烂代码库里面会升高，因为它会照着已有的烂模式走。如果现有模式本身就混乱，那结果只会被进一步放大。又比如，一个系统的信息分散在很多地方，AI 就更难真正获取完整上下文。可检测性也跟代码库质量有关，没有良好的反馈循环，没有可靠的测试自动化，那么不仅你自己更难验证 AI 的输出，agent 本身也更难验证自己的结果。

安全与成本

安全

现在几乎每周都有什么事故报告出来，基本都和 prompt injection 有关，agent 从不可信来源拿到了内容，而那个内容包含了你不曾意识到的指令。

一种后果是 unwanted command execution。现在几乎所有 coding agent 都有 allow list 功能。你可以配置哪些命令允许自动执行、不需要再询问用户；而另一些命令，则始终要求用户手动确认：“是的，你可以执行。”但这些机制本身，目前其实还存在不少实现层面的漏洞。再加上很多配套机制本来也还没完全成熟，以及 AI 本身天然具有不确定特性，于是整体风险就会迅速放大。

另一个非常大的安全风险，是 secrets extraction。尤其是在开源项目场景下，这个问题非常严重。很多项目允许任何人提交 GitHub Issue，然后又会自动触发 agent 去处理 issue，而且中间几乎没有人工监督。有一次攻击里，攻击者就是通过 GitHub Issue 中的 prompt injection，成功诱导 agent 泄露了 secrets，最终获得了向 npm registry 发布恶意版本的权限。这些问题不一定都直接适用于企业内部环境，但它至少说明了一件事：我们对整个依赖生态的风险敞口，正在急剧增加。我们必须比过去更加谨慎地思考：到底把哪些生态组件引入自己的系统。

Simon Willison 在 25 年 6 月写过一个很好的思维模型，叫 lethal trifecta（致命三要素）。当你的 agent 同时满足这三个条件：接触不可信内容、能访问私有数据、可以对外通信，那么安全风险就处于高位。

而这件事，其实在企业 agent 场景里更加危险。因为很多业务场景一开始就会接入邮箱系统，而且通常还是 read/write 权限。那一刻起，你其实已经满足 lethal trifecta 了。所以，这并不只是一个“技术问题”，它更像是一个“概念层面的问题”。未来那些我们被承诺过的企业 agent 场景，到底能不能真正绕开这些风险，我觉得会非常值得观察。

在减少人工监督的背景下，安全方面想想这些事：你有没有在简化 agent 的沙箱使用，不只是在云端，本地也是？可以用 dev container，我最近大量在用这些。还有一堆新产品冒出来，在人机交互沙箱这块有一些有意思的想法。另外，组织里工程师的 AI 安全素养怎么样？他们知道底层在发生什么吗？比如，有些 agent 有所谓“YOLO 模式”，连命令确认都不需要，agent 想执行什么就执行什么。这种模式，真的不要随便开。

成本

关于成本，蜜月期显然也已经结束了。2024 年初，我听过一场 keynote，演讲者说"生成 100 行代码只需要大约 12 美分，你想想开发者工资有多贵。"先不说“代码行数”本身就是一个非常糟糕的价值衡量指标，问题在于：现在早就不是 12 美分了。

这是 2025 年夏天的数据，有一些网站会公开用户的 token 消耗情况。其中有个人，平均每天花费大约 380 美元。如果按每月 20 个工作日、一年 12 个月来算，那就是年成本 91,200 美元。而在德国，这已经是一份相当不错的开发者薪资了。更何况，那还是“去年夏天”的数字。

现在成本已经进一步爆炸。我们已经从最早每月 20 美元的“无限套餐”时代（Copilot 最开始甚至可能只要 10 美元），一路走到了今天这种所谓“200 美元 flat rate”，而且还不是真正 flat，因为会有 request limiting。于是你会看到 Reddit 上开始有人发帖：“这个月才过一半，我 token 已经用完了，怎么办？”“我们现在已经离不开这些工具了。”

为什么现在做一个改动的成本远不止 12 美分？那个 keynote 演讲是 2024 年初，那时候大家主要还在用自动补全，最多在聊天框里问几行代码。而现在的流程是：agent 研究已有代码，制定计划，我们审查调整计划，开始实现，跑测试、修测试、检查 lint 错误、修错误，如果是 UI 功能还要检查浏览器，再修，跑 code review agent，回应审查意见，做总结。来来回回一大圈，最后可能只改了两行代码。

我们现在在哪

经过这 12 个月之后，如果把所有变化放在一起看，一个更清晰的轮廓其实已经开始浮现 Context Engineering 正在变成一个非常强的“放大器杠杆”，而且这种放大是双向的：既能放大好的工程实践，也同样会放大坏的结构问题。

现在你确实可以通过一整套手段，让 agent 更大概率按照你的意图去工作。模型能力本身当然也在进步，这一点几乎是默认前提，但有意思的是，它反而变成了一个“背景变量”，没有 surrounding system 那么关键了。

而更重要的结果是：一股很强的力量正在把我们“推出人类干预循环”。你会越来越频繁地面对这种诱惑：要不要更少介入？要不要让 agent 自己跑？要不要直接把这一块交给自动化？这种体验往往是“非常爽”的，因为反馈很快，产出很多，看起来效率极高。

但问题也随之出现：在某些组织或某些 use case 里，这种“脱离人类循环”的决策，可能在一年之后才会暴露代价。于是核心矛盾变成了一个判断问题：在什么地方我们可以顺着这种自动化趋势走？又在哪些地方，这其实是一种“看起来很顺，其实很危险”的路径依赖？

现在整个行业都被一种强烈的驱动力推动着：speed、throughput、PR 数量。“我们这个星期 merge 了多少 PR？”“我们比上个月快了多少？”这些指标变得越来越显性。但当 autonomy 提升、supervision 降低之后，问题也开始从单一的“安全”和“成本”，扩展到一个更长期的维度：代码可维护性到底会发生什么变化？

OpenAI 的一个团队最近有篇文章很有意思。他们在过去五个月里维护一个 codebase，这个项目一开始是 greenfield，从零开始。他们给自己定了一个非常激进的规则：尽量不直接手写代码，而是只和 agent 交互，让 agent 去改代码，然后他们不断优化周边系统，让 agent 更容易在这个环境里自主维护代码。整个过程其实是一个混合系统：一部分是 Context Engineering（skills、规则、工具接口），另一部分是更 deterministic 的机制，比如 custom linters、结构化测试（structural tests）等等。

即便如此，他们仍然发现熵在增加，漂移在发生，代码库并不会自动变得更整洁。于是他们引入了一个他们称之为“garbage collection”的过程，让 agents 持续在代码库上运行，进行清理和整理。

通过 Harness Engineering 建立信任

这些“架构约束 + 确定性工具 + agent 自动维护”的组合，正在越来越多团队的实践中出现。我自己也做过一点类似尝试，这本质上就是把结构性测试变成 agent 的反馈。比如 Java 生态里的 ArchUnit 或 Spring Modulith，或者在 TypeScript 里，我用的是 dependency-cruiser，说实话，我以前甚至没怎么接触过这个工具。

原因其实很简单：这些工具一直都存在，但在“人类主导写代码”的时代，它们并不是刚需。因为开发者本身就能理解模块边界，也知道怎么拆分结构。但现在它们突然变得很重要，因为它们变成了 agent 的“反馈系统”。

在我的实验里，我定义了应用的分层结构，然后配置了一系列规则。比如其中一条规则是：external SDK 只能在特定的 client folder 里被引用，而 domain 层完全不允许直接依赖这些外部 SDK。这些规则不只是约束代码，也是在反向塑造 agent 的行为。

更有意思的一点是：这些 lint rules 和结构性测试，现在其实可以被“增强语义”。它们不仅仅是错误提示，它们也可以变成一种“带解释的反馈通道”。这有点像一种“正向 prompt injection”。你可以在错误信息里附加解释：“这个错误不仅仅是违反规则，它可能意味着你的设计出现了问题，建议你考虑重构。”

如果你设定规则：每个文件不能超过 500 行代码。如果不加引导，agent 可能会“投机取巧”，比如把一行写成多个 statement 来规避限制。但如果你在 lint message 里补充上下文，比如：“这通常意味着模块划分不合理，应考虑拆分设计。”那么 agent 就会开始理解规则背后的意图，而不是机械规避。

本质上，我们正在做的事情是：把原本为人类设计的工程约束系统，改造成 agent 可学习、可反馈、可优化的系统，这可能才是 Context Engineering 真正开始变得“工程化”的地方。

说到底，这就是怎么建立对 agent 的信任——构建一整套 Harness。那个 OpenAI 团队管这叫做 Harness engineering，因为归根到底，我们不是说几年后要让 agent 写出完美的代码，我们自己写的代码也从来不完美。问题是，在特定场景下，我们怎么获得足够的信心和信任来安全、快速、可持续地交付软件？

我最近一直在思考一个心智模型，我前面聊了大量的 Context Engineering、skills 等等，所有这些都是喂给 agent 的前置输入。我们在预判 agent 可能会犯什么错，然后提前给它所有工具和指令，提高它按我意图行事的概率。这些东西包括 principles、coding conventions、参考文档、how-to 等等。然后 agent 产出第一版代码之后，我们就给它反馈：静态分析、给它接入日志、启动应用看能不能跑、检查浏览器。所有这些反馈让 agent 先把那些重复的修正工作做完，才轮到我看。

这些东西可以是 CPU-based 和 GPU-based 的混合。这个框架我是从一家叫 Moderne 的公司学的。什么意思呢？我们有 code review agent，但它本质还是基于 GPU 推理的。如果我们把它用大量 CPU-based、更确定性的东西来增强呢？而同样的事情也可以在 feedforward 侧做，不只是给 agent 基于 GPU 推理的工具和信息，如果给它接入 CLI、bootstrap 脚本、Codemod、OpenRewrite recipes 这些更确定性的工具，一样可以让它更大概率做对事情。这也回到我前面提到的语言服务器，比如现在你可以给 agent 接入 IntelliJ 的重构能力，它可以用"rename symbol"功能来做一次重构，而不是到处做文本 diff，这样它的准确率就更高了。

这套东西全部加在一起，我管它叫 Harness。有些是 coding agent 自己内置的，他们可以持续改善代码编辑的方式、代码搜索的方式，这些都算 Harness 的一部分。还有一些是我们可以自己控制、针对自己的情况定制的，人类是这套东西的舵手。

那个 OpenAI 团队做的就是这件事，不断改善 agent 周围这个 Harness。当然，我们也可以用 AI 来帮我们搭建 Harness。我前面说的那些结构性测试和 linting，之前大家不会自己去写这些自定义工具，太费工夫。但我那个实验，全部都是用 AI 做的，不是我手写的。风险比生产代码低太多了。

我甚至在想，这会不会成为某种新的抽象层。会不会将来某一天，我们会有一些覆盖 80% 工作内容的拓扑结构？我们经常构建那种从其他 API 收集数据并展示的数据仪表盘，或者可能是 CRUD 业务服务、事件处理器，也就是我们编写的那些典型应用类型。然后我们有一个关于它们应该怎么结构化、用什么技术栈的定义。

也许未来我们不再靠传统服务模板起步，而是一个 Harness 模版，实例化之后就能支撑我们的代码库。到那时候，我们可能甚至不在乎到底是 React 还是 Vue，决策维度可能会变成“有没有现成的 Harness，这样我就不用操心、不用从头搭了”。

但我前面讲的这一切，都是关于可维护性和内部代码质量的。对于功能正确性这件事，我的问号还是非常非常大。当然，这是最终的关键。我们不仅希望安全关键的系统能正常工作，我们希望所有软件都能正常工作。

我们需要更多关于如何给应用的不同维度加 Harness 的思考。我讲了很多可维护性，但也许还有架构健康度，比如怎么给可运维性加 Harness，怎么给性能加 Harness？然后是行为正确性。现在大多数人的做法是，前面用描述喂给 agent，后面看看测试是不是绿的，但测试也是 AI 生成的，然后再做一点手动测试，到此为止。有些人说他们会更多审查测试等等，但我有时候有点怀疑，这不够，我们需要更好的办法。

模型进步确实提高了一些我的信任度。更精细的 Context Engineering、context 的渐进式加载、更多的工具集成、subagents，所有这些都提供了很多新的建立信任的手段。围绕 static analysis 能走多远这件事，也多了很多新的思考空间。

但我还是天天看到模型犯蠢的事情。Reddit 上有个帖子很火，agent 说："你说不，但我以为你是在拒绝我问你要权限，所以我就自己直接去做了。"就像个青少年："你说不，但我理解成了别的意思。"

另外还有那种"还在 loop 里却已经认知超载"的感觉。有越来越多的人开始说他们用 AI 之后感到倦怠，要么是被审查的工作量压垮，要么是同时切多个会话根本看不过来，眼花缭乱。有一个很有意思的现象：真正能把 AI 开到最大这种自主度跑起来的，通常都是非常资深的工程师。他们有更强的认知承载力，他们本来就有了极强的经验积累。

然后还有来自上面的速度压力。一旦给人们施压"你的 AI 产出是什么?"、"你用了 AI 怎么还能这么慢"，他们就会走捷径、变粗心。有意思的是，Amazon 最近出了一篇内部复盘，提到一些疑似由 AI 生成代码相关的故障。他们的对策之一是增加关卡，让 senior 工程师必须 review 生产内容的引入。这有点讽刺，不是说好的要更快上线吗，结果我们反而加了更多手续？这大概也不是正解。

我最近越来越频繁地问自己，我们到底需要多快？什么才是 Goldilocks 速度（刚刚好的速度），够快但不太快？这种速度到底带来什么风险？速度是怎么真正帮到组织的？有没有其他更值得我们关注的事？

AI 就像一把瑞士军刀，有着大量潜在的使用场景。其中很多场景在有人类监督的情况下才真正有用，未必会让你不堪重负，反而会是你原本必须手动完成、耗时极长的工作的一种良好延伸。过去一年里涌现出了那么多进展，让 AI 的使用变得更高效，也让你在把 AI 当作自身能力增强时，获得了更好的开发者体验。

接下来这 12 个月，我们会学到更多东西。会有新的好主意，也会暴露更多让我们担忧的东西：过载、技能退化等等。这些，也不过是我抛给你们反思的一些问题：如果你想在交付中给予 AI 更多自主权，你准备好了吗？你的自动化安全网是什么？你的安全态势如何？眼下团队的 AI 素养到了什么程度？在这些方面做提升，永远是值得的，对人类本身同样值得。如果你将来想做好准备，AI 甚至今天就能帮你去完善那张安全网。

演讲原链接：https://www.youtube.com/watch?v=_R83pFpUWyM