一年前我们还在研究怎么写更好的 Prompt。一年后的今天，Prompt Engineering 几乎成了过时的概念。Coding Agent 生态系统已经彻底变了——Context Engineering、Subagent 编排、Harness 模板化，三股力量正在重新定义「用 AI 写代码」这件事。
§1 那个让你颤抖的问题
你知道今天一个 Coding Agent 在执行任务时，背后在做什么吗？
它可能在读你的整个代码库，把 import 图展开三层的依赖，从前端组件一路追踪到数据库 schema。它可能在同时调度七八个 Specialist Agent——一个查文档、一个跑测试、一个写代码、一个做 review。它可能在用一套标准化模板管理 context 窗口的每一寸空间，精确到哪些文件要全文读、哪些只读签名、哪些直接跳过。
而你还在调 Prompt。
这不是鄙视链。这是一个正在发生的范式断层。2025 年，「给 AI 写 Prompt」还是开发者的核心技能。到了 2026 年中，这个技能已经被自动化和工具链层层包裹，变成了底层的「基础设施操作」。真正站在 C 位的，是三个听起来有点学术的概念：Context Engineering、Subagent Orchestration、Harness Templating。
每一个都在改写我们对「AI 编程」的基本认知。更重要的是，它们不是你选 A 就放弃 B 的关系——三者互相咬合，构成了一套完整的新型开发范式。
§2 从 Prompt 到 Context：一年间的范式漂移
回溯一下剧情。
2023-2024 年，大家还在玩「提示词工程」。把需求写进 prompt，调 temperature，加 few-shot examples，塞角色设定。那时候的共识是：Prompt 写得好不好，直接决定了模型输出的质量。网上有大量「Prompt 工程指南」，工程师之间互相分享「让 GPT-4 输出 JSON」的 prompt 技巧。
到了 2025 年，情况开始微妙变化。Cursor、Windsurf（当时还叫 Codeium）、Devin 这些工具的崛起，让开发者第一次见识到什么是「真正在写代码的 AI」。它们不是简单地在聊天框里塞 prompt——它们能读文件结构、理解项目规范、自动调用终端命令。Prompt 不再是输入的全部，Context——上下文——成了新的变量。
然后 Claude 3.5 Sonnet 在 SWE-bench 上的表现震惊了所有人。人们发现，只要给足高质量的上下文，模型的代码能力可以再上一个台阶。Prompt 的质量当然还有影响，但「给多少上下文」和「怎么组织上下文」对结果的影响，已经远远超过了「怎么写 prompt」。
到了 2026 年中，技术社区里已经没有多少人还在讨论「prompt engineering」了。现在的 hot topic 是：如何构建一个能精准捕捉项目意图的 context 系统？如何编排多个 specialist agent 并行工作？如何用标准化 harness 让 agent 的行为可预测、可复用？
这就是从 Prompt Engineering 到 Context Engineering 的范式漂移。它不是一夜之间发生的，回头看却快得让人喘不过气。
§3 Context Engineering：将上下文从「燃料」变成「导航系统」
如果说 Prompt 是 Coding Agent 的燃料，Context Engineering 做的就是把燃料变成导航系统。
3.1 Context Engineering ≠ 塞更多上下文
一个常见的误解是：Context Engineering 就是「尽可能多地把上下文塞进模型窗口」。错了。Claude 和 GPT 的 context window 再大，也是有限资源。而且模型在长上下文上的表现并非线性——中间部分的 recall 率会明显下降（U 型效应）。
真正的 Context Engineering 在解决一个问题：在有限的 context 窗口里，如何让模型看到最需要看的东西，并且以最佳顺序看到它们。
3.2 上下文过滤与优先级排序
现代 Coding Agent 的 Context Engine 通常包含这几层：
项目范围估算：在开始任何任务之前，引擎先估算「这个问题会涉及代码库的哪些部分」。是修一个函数（局部）还是重构一个模块（全局）。估算结果决定了 context 的采集范围。
依赖图展开：不会把整个代码库丢进窗口。相反，它会从目标文件出发，沿着 import 语句展开依赖图，深度优先但限制层级（通常不超过 3 层）。前端组件跳转到 API 层，API 层跳转到数据库层。每一层只保留关键信息——函数签名、类型定义、接口文档。
按优先级分层：最核心的信息（改动目标附近 50 行代码、相关接口签名、测试用例结构）放窗口顶部。边缘信息（项目介绍、技术选型说明、config 文件注释）放底部或压缩为摘要。文件路径和行号是自动嵌入的「引用锚点」，方便后续定位。
动态增量更新：Agent 执行到一半发现需要更多信息，不会重新加载整个窗口——而是增量插入新的上下文，同时把不再相关的旧上下文压缩或清除。这个机制有多智能，直接决定了 Agent 的「续航能力」。
3.3 为什么这比 Prompt Engineering 难一个数量级
编写一个 Prompt 基本上是平面任务：你写一段话，期望模型理解并执行。
做 Context Engineering 是一个系统工程：你需要理解代码的结构化特征、需要设计上下文采集算法、需要考虑 token 预算的数学优化、还要处理增量更新中的一致性问题。
一个具体的例子：Claude Code（Anthropic 官方的 coding agent）在读取大型代码库时，不会一次性加载所有文件。它会先执行一个「探索阶段」（Explore Phase），快速扫描文件结构、识别关键文件、建立索引。然后才进入「执行阶段」（Execution Phase），带着探索阶段构建的「mental model」去处理具体的编码任务。这个设计思想，本质上就是 Context Engineering 的实践。先理解，再行动。
Cursor 的做法更激进：它把 context 信息分成几层——Project Rules（项目级持久上下文）、System Prompt（工具定义）、Current File（编辑点）、Related Files（关联文件）。每一层有明确的加载优先级和生命周期，由引擎自动管理。
§4 Subagent Orchestration 与 Harness 模板化
如果 Context Engineering 解决了「模型怎么看世界」的问题，Subagent 和 Harness 解决的就是「模型怎么动手干活」的问题。
4.1 从单 Agent 到 Specialist 编排
一年前，Coding Agent 的主流形态是「一个模型做完所有事情」。它要理解需求、写代码、跑测试、读报错、改 Bug——像一个万能土木工，什么都干但每样都不精。
今天的 Coding Agent 生态已经完全走向了Specialist Agent 路线：
- Reader Agent：专门负责阅读和理解代码。它的 context window 里全是代码分析和检索相关的内容。不会写一行代码，但读代码的速度和精度远超通用 Agent。
- Editor Agent：专职写代码。它会带着 Reader Agent 的分析结果，按照项目的 coding style 和架构规范，生成具体的代码修改。
- Reviewer Agent：Code review 专家。在 Editor Agent 完成修改后自动启动，检查代码质量、潜在 bug、安全漏洞、测试覆盖。
- Executor Agent：负责跑命令。运行测试、启动 dev server、执行 lint。它的输出会被反馈给 Editor 和 Reviewer 做闭环控制。
- Planner Agent（可选）：高层级的任务分解 Agent。它不写代码，不读代码——只把用户需求拆解成可执行的子任务列表，然后调度其他 Agent 去执行。
这套模式的核心价值在于：每个 Agent 的 context 窗口只装载它擅长的内容。Reader 不需要被写代码的工具定义污染 context，Editor 不需要被代码分析算法分散注意力。分工带来的效率提升，远超过 Agent 之间通信的开销。
4.2 Subagent 通信与竞合机制
多 Agent 编排中最棘手的问题不是「怎么分工」，而是「怎么协同」。
现在的做法大概分两种流派：
消息总线型（如 OpenHands / OpenDevin 架构）：所有 Agent 通过一个事件总线通信。Reader 发布「代码分析结果」，Editor 订阅这个事件开始工作，完成后发布「修改完成」事件，Reviewer 订阅。事件总线提供了松耦合，但事件格式需要严格定义。每次通信都附带必要上下文，不能多更不能少——多了浪费 token，少了 Agent 理解不了。
主从调度型（如 Claude Code 的 subagent 模式）：一个主 Agent 负责任务分解和调度，生成 subagent 任务描述后启动新的 subagent 进程。subagent 带着任务描述和必要上下文独立运行，完成后把结果返回给主 Agent。主 Agent 负责整合、验证、调整。这种模式的优点是鲁棒性高——某个 subagent 失败了不影响其他工作，主 Agent 可以重新调度。
真实场景中，两种模式常常混合使用。比如主从调度处理宏观任务分解，消息总线处理细节层面的 Agent 间协作。
这里还有一个被低估的机制：竞合（Competitive Collaboration）。简单说就是让多个 Agent 对同一个任务产生不同方案，然后由评审 Agent 选出最优解。听起来浪费，但实际证明——尤其在涉及架构决策或安全审计的场景中——多个视角产生的方案质量远超单 Agent 的输出。代价是 token 消耗增加 2-3 倍，但对于关键任务来说，这个成本往往值得。
4.3 Harness：从手写 template 到标准化
最后要说 Harness。这是目前中文技术社区里讨论最少、但在我看来最重要的概念。
Harness 是什么？
简单说，它是一套「模板化 + 参数化」的 Agent 行为框架。就像 Web 开发中模板引擎把 HTML 生成从手写字符串拼接变成了绑数据渲染一样，Harness 把 Coding Agent 的执行行为从「写一段话 + 描述清楚」变成了「选一个模板 + 填参数」。
一个标准的 Harness 模板可能包含：
- goal: "修复 {file_path} 中的 {bug_category} 类型 bug" - context_recipe: - read_file: {file_path} - read_dependencies: {max_depth: 2} - search_similar_bugs: {repo: {repo_name}} - agent_setup: - primary: "editor" - reviewers: ["reviewer"] - executor: "executor" - output_schema: - diff: "string" - explanation: "string" - test_result: "object"用户只需要填入文件路径和 Bug 类型，Harness 引擎会自动装配上下文、调度 Agent、执行任务、输出结构化结果。
这意味着什么？
第一，Agent 行为变得可预测。同一个 Harness 模板，输入不同参数，Agent 的行为模式是高度一致的。这让企业级部署成为可能——你不会因为模型输出的随机性而提心吊胆。
第二，Agent 能力可以组合复用。别人写好了一个「单元测试生成 Harness」，你直接拿过来用，不需要理解它底层的 Agent 编排逻辑。这和传统软件工程里的「模块化」异曲同工。
第三，Agent 执行的 trace 可以标准化。每次执行都有完整的上下文采集记录、Agent 调用链、token 消耗明细——可以审计、可以优化、可以追溯。
市面上已经有不少 Harness 的实现雏形。Anthropic 的 Claude Code 提供了一套默认的 Agent 工作流模板，用户可以在配置文件里自定义。Cursor 的 Agent Mode 本质上也是一个 Harness——你告诉它做什么，它自动帮你配置 Agent 参数、调度执行、展示结果。但真正的「Harness 生态」还在早期，就像早期 Django 和 Rails 的 MVC 框架——最早的一批开发者在使用时会遇到各种边界情况，但随着社区贡献的模板越来越多，标准化程度会越来越高。
我的判断是：到 2027 年，Coding Agent 的主流使用方式不会是写 Prompt，也不会是写 Subagent 编排代码，而是「装 Harness → 选模板 → 填参数」。就像今天我们用 Web 框架而不是手写 HTTP 服务器一样自然。
§5 这对你意味着什么？
如果你是独立开发者或小团队：
尽快停止在 Prompt 优化上的重复投入。学会使用 Cursor / Windsurf / Claude Code 这些工具的 Context 管理功能。理解它们的上下文采集机制，配置好 Project Rules 和 Reference。你现在花半天优化一个 Prompt 的时间，不如花半天理解 Context Engineering 的基本原理。
如果你是技术团队的负责人：
把 Harness 标准化提上日程。让团队成员在日常编码中使用同一套 Agent 工作流模板。记录不同 Harness 的效果——哪个模板对 React 组件开发最有效？哪个模板对 API 接口设计最稳定？这些数据本身就是你团队的「Agent 效能指数」。
如果你是创业者：
关注 Harness 生态的空缺。当前 Coding Agent 工具圈的竞争集中在底层模型和 IDE 集成层，中间「Agent 行为框架」这一层几乎还是空白。一个标准化的、开源可扩展的 Harness 模板市场，可能是 Coding Agent 时代的基础设施级别的机会。
如果你是所有开发者：
不要恐慌。Coding Agent 的发展不是让你失业——它是在重新定义你的「工种」。当「写代码」本身被大量自动化后，留下来的核心技能是：理解系统架构的能力、定义好问题的能力、以及设计 Agent 工作流的能力。你不会失业，但你的工具箱会换一批。
一年前，我们还在问「如何写更好的 Prompt」。一年后的今天，问题变成了「如何设计更好的 Agent 工作流」。再过一年，可能会变成「如何构建更好的 Agent 生态」。
这就是技术世界的速度。我们都在被带着跑。唯一的选择是跑得更快一点，或者——选择最顺脚的那双鞋。
Harness 就是那双鞋。
