我原本以为，2026 年 Agent 这一波继续往前走，最值得追的是模型升级。后来越看越觉得不对。模型当然还在进步，但真正开始决定系统能不能长时间稳定工作的，越来越像是另一个层：上下文工程，以及围绕它长出来的技能层。

Anthropic 在 2025 年专门写了 Effective context engineering for AI agents，OpenAI 这边也在 Codex 上持续把 skills、harness、app server、长任务、orchestration 这些能力补出来。它们其实都在回答同一个问题：当 agent 不再只是回答一轮问题，而是要持续工作、跨任务迁移、调用工具、在大仓库里找信息时，什么东西能让它不越来越乱？

为什么我会把重点从模型切到上下文

因为很多团队现在遇到的真实问题，已经不是“模型不会做”，而是“模型做着做着就把上下文搞坏了”。它可能忘记前面已经试过什么，可能把无关日志带进后续推理，可能在大仓库里抓错文件，也可能把一堆低价值工具定义塞满上下文窗口。

这时候继续追一个更强模型当然有帮助，但往往不如把上下文整理方式、引用方式、压缩方式、技能封装方式做好更有效。因为后者直接决定 agent 在真实系统里能不能维持稳定表现。

上下文工程不是 prompt 技巧，而是运行时设计

我很认同 Anthropic 的一个表述：context engineering 不是只改 prompt，而是管理推理时进入上下文窗口的整套信息。这个定义很重要，因为它把问题从“怎么写一句更好的提示词”拉回到了“系统应该如何组织信息”。

• 哪些信息应该预加载，哪些应该按需拉取；
• 哪些内容只保留引用，不保留全文；
• 什么时候做 compaction，压缩成什么粒度；
• 哪些工具调用结果应该被结构化保存；
• 哪些历史经验应该沉淀为可复用 skill，而不是反复临场发挥。

这已经很像传统软件里的缓存策略、索引设计、模块边界和运行时调度了。区别只是现在这些设计直接影响模型的表现、成本和稳定性。

为什么技能层会越来越重要

OpenAI 在 Codex Skills 文档里把 skill 定义成一组可复用的说明、资源和可选脚本，目的是让 agent 更可靠地走完某种工作流。我觉得这背后是一个非常现实的工程判断：与其每次都指望模型现场发挥，不如把那些高频、易错、流程相对固定的任务，封装成一个受控的技能层。

name: fix-failing-pytest
instructions: |
  先读取 pytest 输出，再定位最近改动文件，最后只修复最小范围。
resources:
  - docs/testing.md
  - scripts/collect_test_context.py
scripts:
  - python scripts/collect_test_context.py

这类技能封装真正省掉的，不只是 prompt 时间，而是把“正确的任务路径”固定下来。对一人开发者和小团队来说，这比追求一次性更聪明的生成更重要，因为它更可控、更能复用，也更容易调试。

被低估的一点：技能层其实是在对抗漂移

我很喜欢 OpenAI 在 harness engineering 里提到的一个现实：全自主代理会复制仓库里已有的模式，久而久之会产生漂移。这个问题不是靠“更聪明的模型”自动消失的。很多时候，你需要的是一层明确的工作流护栏，让 agent 知道什么资料先读、什么命令先跑、什么结果不能省略。

从这个角度看，skills 并不只是“给 agent 加能力”，更像是“给系统加秩序”。它把一些原本散落在工程师脑子里的经验，沉淀成机器也能稳定遵守的路径。

但这条线同样有维护成本

这里也不能神化。上下文工程和技能层很容易变成新的维护面。你会遇到这些问题：

• skill 太多以后，谁来维护版本和适用范围；
• 资源文件过期后，agent 会学到旧流程；
• 压缩策略一旦过猛，关键上下文会丢失；
• 不同 skill 之间可能互相冲突，导致行为不一致。

也就是说，这条线不是没有代价，而是把代价从“临场失误”换成了“系统维护”。如果你没有高频重复任务，或者项目本身还在快速变化，过早沉淀太多 skill 反而会拖慢自己。

个人开发者现在最适合沉淀什么

如果我是个人开发者，我不会先做一套宏大的技能平台。我会先沉淀三种东西：

• 最常复用的诊断流程，比如测试失败、构建失败、日志定位；
• 最容易忘步骤的发布流程，比如版本检查、迁移检查、回滚说明；
• 最容易污染上下文的任务，比如大仓库检索、跨文件重构、文档与代码对齐。

这些地方最适合通过 skill + 资源 + 脚本的方式固化下来，因为它们足够高频、足够耗注意力、也最容易因为临场发挥而漂移。

半天内最值得做的验证

• 挑一个真实高频任务，分别用“裸 prompt”和“skill 封装”跑 5 次；
• 比较失败率、输出一致性和审阅成本；
• 观察 agent 是否更少无意义地读取文件和调用工具；
• 确认技能资源更新一次后，流程是否更稳定还是更脆弱。

这类对比不需要大规模 benchmark，但很容易让你看清：你真正缺的是更强模型，还是更清晰的运行时约束。

我的判断

上下文工程和技能层，接下来很可能会成为 Agent 时代新的核心工程能力。它们没有模型升级那么吸引眼球，但更接近真实系统的稳定性来源。对个人开发者和小团队来说，我会把它列为“现在就值得投入”的方向，优先级甚至高于继续追逐每一次模型版本更新。前提是别做得过重：先围绕真实高频任务沉淀少量高价值 skill，再让系统慢慢长出自己的秩序。

参考来源类型：Anthropic 工程文章（Effective context engineering for AI agents、Effective harnesses for long-running agents、Scaling Managed Agents），OpenAI 官方博客与文档（Codex Skills、Harness engineering、Unlocking the Codex harness、Symphony）。