系统、故事与技能：2025 年回顾
Source: Dev.to
Introduction
在四年停更之后，2025 年是我终于重新坚持写博客的一年。
这是一个充满转变的一年，对整个行业以及我的个人职业生涯而言都是如此。2024 年底，我进入了 Enablement 与 Platform Engineering 领域，这标志着自大学毕业后，我首次在安全组织之外担任职务。从这个新视角，我看到生成式 AI 领域已从简单的聊天界面演变为自主代理、标准化工具以及可复用的技能。
超越炒作：实用性的崛起
当 ChatGPT 最初发布时，我并不感到惊讶。每周都有关于大型语言模型出现幻觉的文章。由于无法与外部数据源交互或驱动外部系统的变更，我认为它的价值有限。
在 2025 年，行业转向 通过模型上下文协议（MCP）进行标准化工具调用。
- 关注点已超越单轮聊天响应和智能代码补全。
- Agentic loops——能够通过 bash 命令验证实现或控制浏览器的代理——展示了编码代理的强大功能。
- 与其说是“全知”的 LLM，不如说重点转向 实用性 以及 使用工具 的能力（通过 MCP）。
从实验到执行
Claude Code 于今年年初出现，作为一个实用的编码代理，随着该领域的成熟，随后出现了许多竞争者。这些代理帮助我在上述的间歇期后重新投入个人项目。它们显著降低了实验成本，并帮助我避免了因无尽的反复试验而陷入的兔子洞。
其中一个项目是 Verifi，这是一款帮助开发者在不同编程语言生态系统中更轻松管理证书的工具。与其陷入语法细节，我与代理共同制定了一个明确的计划，朝着我关注的结果和非功能性需求前进。构建 Verifi 使我清楚地认识到，随着代理的采用率提升，阐述并演进计划的能力将比实现细节本身更为重要。
新的前沿：上下文工程
早期，我以为让代理访问更多的 MCP 服务器会让它更强大。然而，工具太多反而降低了性能——这进一步证明，代理的失败往往是 系统设计 的问题，而不是模型的局限。
- 提示工程 在单轮提示中表现良好。
- 提示长度与工具丰富度之间的矛盾，使 上下文工程 在 2025 年成为焦点。
上下文工程的核心是防止 上下文窗口 被工具定义、系统提示以及叠加在对话之上的自定义指令所淹没。
我如何改变评估标准
- 我不再仅以单次交互的最佳输出评判代理，而是评估它们的行为在更长的工作流中是否 可理解且可预测。
出现的策略
| 策略 | 功能说明 |
|---|---|
| 优化 MCP 工具定义 | 删除不必要的元数据以节省 token。 |
| 自定义/子代理 | 将专业任务委派给轻量级代理。 |
| 渐进式披露 | 仅加载当前步骤所需的上下文。 |
Agent Skills 标准（最初由 Anthropic 创建）帮助确保编码代理之间的一致性，从而在恰当的时机拉取正确的上下文。我创建了示例技能，其中包括一个关于 依赖管理 的技能。正如我在文章中概述的，代理现在可以 仅在包文件更改时 加载依赖管理技能，而不是在每条指令之前就预先加载。
展望2026：技能管理
类似于今年围绕 MCP 和扩展工具集的讨论，我预计随着技能的采用率提升，也会出现围绕 技能管理 的平行讨论。为了给今年画上句号，我利用假期间的空闲时间原型化了一个潜在的解决方案。
skset – “Skill Sets”
我构建了 skset（即 Skill Sets 的缩写），以探索技能管理生态系统可能的样貌。最初的关注点是 技能分散在不同代理目录中的基本问题。
在 2026 年，观察是否会出现一个 标准化的技能公开共享市场，超越我们今天看到的供应商特定生态系统，将会非常有趣。关于编码代理将如何根本性地重塑软件工程，以及这种转变将如何影响工程师整个职业生涯的讨论，已经在进行中。
最终思考
- 2025 年在基础模型性能方面取得了巨大的改进，但这些能力仅仅是基础。
- 随着我们迈入 2026 年，自动代码审查、社交编码以及大规模质量治理的“下游”影响将变得更加清晰。
对我而言，2025 年是人工智能的决定性转折点。正如我在 Cloudy With a Chance of Context 中所写，这个时代让人不禁联想到我在 2018 年经历的云计算转变——当时云计算从新兴技术转变为通用最佳实践，给治理团队带来了跟上的挑战。
2026 年将是我们看到这些自主工作流是否真的能够达到生产级工程高标准的一年。 根据我在构建 skset 并从事上下文管理的观察，挑战不会在于单一能力，而在于有效地协调技能、子代理、MCP 服务器以及其他能力的协同工作。团队需要：
- 在不超出上下文预算的前提下完成发现。
- 为每个项目配置逻辑分组。
- 理解这些特性之间的相互作用。
这段旅程才刚刚开始——敬请关注。