ksxz
Coding AgentAIContext EngineeringSubagentsInfoQ

Coding Agent 技术全景图 — Context Engineering、Subagents 与 Harness 的一年范式转移

宇琪（编译）··原文链接
收录于 2026/6/8 11:15:06

一句话

Coding Agent 的核心矛盾已从"模型够不够强"转为"你能不能搭出一套 Harness，让非确定性模型在确定性约束下安全交付"。

核心论点

一年前 vs 现在：范式转移

一年前（2025 中）：

  • Vibe Coding 刚兴起，MCP 在风口，Claude Code 还在襁褓
  • Context Engineering = rules files（AGENTS.md / CLAUDE.md），全量塞给 agent
  • 主要关注"从自动补全到 Agent"的进化
  • 工作模式：开发者坐在 session 前面，高频来回协作（supervised）

现在（2026 中）：

  • Context Engineering 已膨胀为 rules + commands + skills + subagents + plugins + specs 的完整体系
  • 云端 agent、headless mode、CLI 版编程助手成为标配
  • 核心问题从"怎么写 prompt"变成"怎么搭 Harness 让 agent 在约束下安全运行"
  • 减少/去除人类监督的趋势明确，但安全、成本、可维护性的代价才开始显现

Context Engineering：上下文工程

定义：精心筛选模型/agent 能看到的信息，从而获得更好的结果。听起来简单，但具体到 coding agent 场景，它演化出丰富含义。

核心组成：

  1. 可复用的 instructions 和 conventions：怎么写 React component、怎么 bootstrap 项目、代码规范等
  2. Context interfaces：skill 的 description、MCP server 暴露的 tool 列表、coding agent 内建的 tool 列表——LLM 基于这些接口判断"加载什么、调用什么"

Skills（重点概念）：Anthropic 基于社区实践推出的概念，做三件事——

  • 模块化 rules：按功能拆成子文件夹，不再一个文件塞全部
  • 按需即时加载：agent 先看 skill 简短描述，LLM 判断场景需要时才加载完整内容，避免 context window 塞爆
  • 文件夹而非单文件：里面除文档还放脚本，让 agent 直接调用本地已安装的 CLI 工具——很多人开始把 use case 从 MCP 转回更简单的 CLI 脚本方案

关键挑战：

  • "engineering"还带引号——版本管理、分发机制不成熟，插件市场刚起步
  • 加了 context 到底让结果变好还是变差？evals 体系还在早期
  • LLM 不保证一定加载你设计好的 skill，开发者变成"context 管理员"，要管理 context 也要监控 context 大小
  • 上下文预算：session 刚开 context window 就用了 15%（含 system prompt + skills + interfaces），必须精打细算

放大器效应：AI 本质是放大器——好的工程实践会被放大，坏的结构问题同样会被放大。烂代码库里 AI 出错概率更高，因为它照着已有烂模式走。

Subagents：子代理架构

定义：主 agent 可以派生出子 agent，各自拥有独立 context window。

典型模式：

  • 自动派生：agent session 开始时自动派生 Explore agent 研究代码库结构，只把结果汇报回主 session，不污染主 context
  • 手动创建：专门创建 code review agent——用"没有历史上下文污染"的独立 context window 做审查，甚至使用不同模型

与 multi-agent / swarms 的区别：

  • Subagents：主 agent 主动派生，数量少（1-5个），有明确分工，用户可控制
  • Agent teams：更克制的多 agent 协作（如 Claude Code preview 功能），5 个左右 agent，核心问题是 orchestration
  • Agent swarms：扔出几十上百个 agent，由 AI 决定用哪些，观察涌现行为——极早期，属于 hype 阶段

实用场景：

  • 代码库研究（自动）
  • Code review（手动，用独立 context + 不同模型）
  • 大规模迁移工作流（如几千个 CI/CD pipeline 迁移到 GitHub Actions，用不同 subagents + skills + MCP servers 组合）

关键思考：

  • 你想放大哪些编码规范？（AI 是放大器，选对放大什么很重要）
  • 能否基于这些能力构建现代化迁移工作流？
  • 组织该开放哪些工具（CLI / MCP servers / 语言服务器），让 agent 更容易执行操作？

Harness：脚手架

定义：围绕 agent 构建的一整套确定性约束系统——包括结构性测试、自定义 linter、沙箱、CPU-based 检查等——用来约束非确定性模型的产出，建立对 agent 的信任。

它解决什么问题：模型能力本身在进步，但变成了"背景变量"，更关键的是 surrounding system。核心矛盾是：agent 给出的"看起来很顺"的结果，可能在一年后才暴露可维护性代价。Harness 就是在"放手让 agent 跑"和"保证长期代码健康"之间建安全网。

与 agent 本体的关系：Harness 不是 agent 的一部分，而是围绕 agent 的环境。分为——

  • Feedforward（前置输入）：principles、coding conventions、参考文档、how-to、CLI 脚本、Codemod、OpenRewrite recipes、语言服务器接入（如 IntelliJ 重构能力）——提高 agent 按意图行事的概率
  • Feedback（后置反馈）：静态分析、日志、启动应用检查、浏览器检查、code review agent——让 agent 先完成重复修正，才轮到人看

CPU-based vs GPU-based 混合：Harness 可以混合确定性工具（CPU-based：linter、结构性测试、Codemod）和推理工具（GPU-based：code review agent）。用确定性工具增强推理工具，提高准确率。

增强语义的 lint rules：不仅报错，还在错误信息里附加解释和设计建议——"正向 prompt injection"。例如：文件超 500 行的 lint 消息不只是"超限"，而是"这通常意味着模块划分不合理，应考虑拆分设计"。这让 agent 理解规则背后的意图，而非机械规避。

本质洞察：把原本为人类设计的工程约束系统，改造成 agent 可学习、可反馈、可优化的系统——这才是 Context Engineering 真正开始"工程化"的地方。

未来可能性：也许有一天我们有覆盖 80% 工作内容的 Harness 模版（数据仪表盘、CRUD 服务、事件处理器），实例化后支撑代码库。决策维度从"React 还是 Vue"变成"有没有现成的 Harness，这样我就不用操心、不用从头搭了"。

Coding Agent 工具横评

原文未做系统性横评表格，但散落的关键判断：

  • Claude Code：行业领跑者，skills / subagents / context monitoring / agent teams 均先发，其他人跟着复制
  • GitHub Copilot：跟随 Claude Code 的 context monitoring 功能，也有 CLI 和 GitHub Actions 集成
  • OpenAI Codex：最早引爆"云端 agent"概念（2025 年中），任务发到云端 agent 自己跑 20 分钟+返回结果
  • Cursor：推出 CLI 版，做了 agent swarm 实验（构建浏览器），承认有意选择高度可定义的任务做展示
  • Devin / Gas Town / Claude Flow：agent swarm 方向的探索者，极早期

工具趋势：

  • 几乎所有主流产品都支持云端 agent + CLI + headless mode
  • CLI 版成为标配（Cursor CLI、Copilot CLI、Claude Code）
  • 可接入 CI/CD pipeline（Claude Code GitHub Actions、Copilot 集成）

亮点 / 最值得记住的部分

  1. AI 是放大器，不是修复器。Context Engineering 是双向放大器——好实践和坏结构都会被放大。烂代码库里 AI 出错概率更高，因为它照着已有烂模式走。所以"先修好代码库再让 AI 进来"可能比"让 AI 修代码库"更合理。

  2. Agent swarm 实验的"作弊"本质。Cursor 和 Anthropic 的 swarm 实验（构建浏览器 / C 编译器）都选了高度可定义、specification 公开、有成熟测试套件的任务。而企业软件恰恰缺这些——没有那种级别的 specification，也没有那种级别的自动反馈系统。所以 swarm 现在是 show，不是 go。

  3. 成本蜜月期已过。2024 年初"100 行代码 12 美分"的说法已失效——现在一个重度用户每天 380 美元（年化 9.1 万美元，在德国已是不错的开发者薪资），而且"200 美元 flat rate"还有 request limiting。成本爆炸的原因：agent 工作流变长（研究→计划→实现→测试→lint→UI 检查→code review→总结），来回一大圈可能只改了两行代码。

我的判断

对 PC 前端团队的实操启发：

三个概念里，Skills + 增强语义的 lint rules 是现在就能拿起来用的。前端项目天然适合模块化 skills——React 组件写法、状态管理约定、CSS-in-JS 规范、测试模板，每个拆成 skill 文件夹，让 agent 按需加载。同时，用 dependency-cruiser 或 ESLint 自定义规则定义模块边界（如 UI 层不直接调 API、domain 不依赖 external SDK），并在 lint message 里附加设计解释——这等于给 agent 装了一个"架构导师"。

真信号还是炒作：

  • 真信号：Context Engineering 的"按需加载"思路、Subagents 的"独立 context 做审查"、Harness 的"确定性约束包裹非确定性模型"——这三个是工程问题，不是概念游戏，已经在头部团队验证。
  • 炒作区：Agent swarms 目前是纯 show，对 99% 企业场景不适用。Agent teams（5 个以内的协作编排）更务实但仍在 preview。
  • 灰色地带："Harness 模版替代框架选择"的愿景很美，但离前端现实还有距离——React/Vue 生态的脚手架（create-react-app / Nuxt / Vite）已经是某种 Harness 的雏形，但 agent 可学习、可反馈的闭环还没建立。

可带走的话：别急着让 agent 跑得更远，先让你的 Harness 拦得更准——structural lint rules + 增强语义的错误信息 + 独立 context 的 code review，这三件套是 2026 年最值得投入的 AI 工程基础设施。

返回首页