Coding Agent 技术全景图：Context Engineering、Subagents 与 Harness，一年范转移式全解析

编译｜宇琪 策划 | 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 团队基本还是整个行业的领跑者，然后其他人再跟着复制他们做的东西，这算是我对