Agent 上下文需要完整的开发生命周期管理

我们非常高兴你的到来。你可以看到 TNS 最优质的内容将在周一至周五送达，让你随时掌握最新资讯并保持最佳状态。

请查收收件箱中的确认邮件，你可以调整偏好设置，甚至加入其他社群。

在你等待第一封 TNS 时事通讯时，看看最新的精选和热门故事。

技能、Agent 配置、Prompt 指令和规则文件。这些制品现在决定了你的编码 Agent 会产生什么。它们塑造了 Agent 生成的每一行代码、每一个架构决策、Agent 遵循或忽略的每一个约定。从功能上讲，它们就是软件。

然而没有人这样对待它们。团队编写一个 skill，提交到仓库，却从不测试它在模型更新后是否仍然有效。Agent 配置在团队之间被复制粘贴，没有任何版本控制。规则文件与它们所描述的代码库逐渐失去同步。当出现问题时，信号是开发者注意到奇怪的输出并在 Slack 上抱怨。

"如果 context 是新的代码，那它的软件开发生命周期是什么？"

Patrick 为缺失的部分提出了一个框架：Context 开发生命周期（CDLC）。CDLC 不是关于 context 窗口管理或如何在 prompt 中塞入更多 token。它是关于管理进入 context 窗口的各个部分的质量。一个 skill 是最新的吗？模型实际上能正确响应它吗？你是否在提供模型已经知道的 context？如果 context 是新的代码，那它的软件开发生命周期是什么？

Context 开发生命周期的四个阶段

CDLC 有四个阶段，直接映射到我们已经在代码上做的事情。

Generate（生成） 是每个人开始的地方。编写 skills、构建 prompt 配置、设置 Agent 规则。它相当于写代码，这也是目前大部分时间所在的地方。

Evaluate（评估） 就是测试。检查 front matter 上的 linting 是否正确，或者语法是否太长。在高级层面，你运行场景：加载一个 skill，提出一个具体问题，检查 Agent 是否产生预期结果。你跨模型和版本进行测试。你检查是否在写入模型已经知道的 context，这会浪费 token。你验证 skill 是否在正确的触发词上激活。

这就是 context 的 TDD 循环。编写 skill，编写场景，检查输出，迭代。

Distribute（分发） 就是发布。在最简单层面，它是将一个 skill 提交到仓库。在成熟层面，团队将 skills 发布到一个可安装的 registry，带有版本控制、可发现性和访问控制。将一个 skill 粘贴到 Slack 频道不是分发，就像 emailing 一个 .jar 文件不是依赖管理一样。

Observe（观察） 是生产监控。skill 被使用了吗？它在产生正确的结果吗？Agent 在开发者干预之前需要多少轮对话？开发者在哪些地方覆盖了 Agent 或纠正了它的输出？这是你的 context 的可观测性。

不要跳过测试

这里的成熟度曲线与过去二十年中软件开发实践发生的情况完全相同。组织先生成和分发。它们完全跳过评估。它们将 skills 发布到生产环境——也就是给使用它们的开发者——然后等待结果。

这与团队跳过测试驱动开发直接可比，尽管被告知要做。他们不知道痛苦，所以直接上生产。

痛苦来临时——一个 skill 在一个模型版本上工作但在下一个版本上坏了，或者它在错误的问题上触发并给开发者自信错误的指令。当一个 skill 强制执行的约定在六个月前是正确的，但代码库已经向前发展了——这些都是我们在未测试代码中看到的相同失败模式。回归、误报、过时的假设。

"你不能通过要求人类更仔细地审查来扩展代码质量。你通过投资于在两端编纂你标准的护栏来扩展它。"

每个代码库都有 AI consistently 搞错的模式。约定盲点、幻觉的 API、cargo-cult 代码、过度工程。在 Aviator，这些被称为 Invariants，或者 AI slop register。skill register 和 AI slop register 都体现了开发周期两端相同的基本原则：编目你的工程标准并将其提供给 Agent。

在代码生成之前，这意味着 skills。在代码审查时，它是一份 AI 在你的代码库中 consistently 搞错的模式目录。slop register 为自动化检查提供信息，捕捉漏网之鱼。你不能通过要求人类更仔细地审查来扩展代码质量。你通过投资于在两端编纂你标准的护栏来扩展它。

优化自己 Agent 循环的开发者获得更好的个人结果，但改进只属于他们。当他们修复一个 skill 时，没有其他人受益。当他们发现一个失败模式时，没有其他人从中学习。ROI 是 1x。

Patrick 使用两个位于传统 DORA 指标之上的指标来构建扩展问题。

第一个是 human touch：开发者在给定 Agent 工作流中需要多频繁地干预？每次干预都是一个信号，表明 context 缺失或错误。减少 human touch 是衡量你的 Agentic 编码循环实际有多自主的直接指标，它通常与成本相关，因为更多轮次意味着更多的 Agent 支出。

"减少 human touch 是衡量你的 Agentic 编码循环实际有多自主的直接指标。"

第二个是 reuse multiplier：当你改进一个 skill 时，有多少开发者受益？如果一个开发者修复了一个 skill，只有他们从中受益，那是 1x。如果该修复进入共享 registry，50 个开发者获得它，那是 50x。

这两个指标共同迫使组织走向共享基础设施。没有共享的、经过良好测试的 context，你无法大规模减少 human touch。没有分发和版本控制，你无法获得 reuse multiplier。

你的平台团队已经知道怎么做

这个组织结构已经存在。平台团队花了十年时间构建使开发团队能够可靠地发布代码的基础设施：版本控制、CI/CD 管道、制品 registry、安全扫描、依赖管理和访问控制。这个 playbook 几乎可以直接转移。

平台团队为代码仓库做什么，就为 skills 做什么。提供一个 registry。配置访问控制和组权限。设置评估基础设施。运行安全扫描并报告发现。构建仪表板，显示哪些 skills 表现良好，哪些在退化。跟踪所有权，以便在模型更新后 skill 坏掉时，有人为此负责。

平台团队不做的是编写 skills 或在它们坏掉时修复它们。拥有 domain 的团队拥有这个 skill。平台团队提供治理层和工具，这与代码的工作分工相同。

"不要构建工具。构建构建工具的工具。"

孤儿 skills 问题已经出现。一个开发者编写一个 skill，分享它，转到另一个团队，现在没有人维护它。模型更新打破了它，平台团队默认继承了这个问题。这又是孤儿的 GitHub repos。解决方案相同：所有权策略、维护要求、弃用路径。

Patrick 简洁地描述了这些层次："不要构建工具。构建构建工具的工具。平台团队为构建构建工具的工具的人构建工具。"

用可观测性闭合循环

在大多数组织中，最不成熟的阶段是观察，尽管它是最重要的。没有它，就没有学习系统。你手动生成和分发 context，希望它能工作，并在有人提出投诉时修复问题。

Agent 可观测性仍处于早期阶段。标准正在形成。Agent MD 被广泛采用。Skill 和插件标准更新。工具还不够成熟，但模式很清晰：检测你的 agents，集中化信号，并跨团队分析它们。

我们之前认为，生产反馈循环是 AI 辅助开发中缺失的部分。当东西在生产中坏掉时，追溯到变更，识别错误类别，并将其反馈到 prompt 和验证层。CDLC 可观测性阶段将这个想法从代码质量扩展到 context 质量。从 Agent 日志、开发者纠正和轮次计数收集的信号直接反馈到生成更好的 skills、编写更有针对性的 evals 和分发改进版本。

自我改进的 Agentic 开发

完全闭合的循环看起来像一个系统，其中 Agent 日志进入识别差距的分析。那些差距生成新的 skills 或对现有 skills 的更新。更新后的 skills 在发布前通过评估。它们通过带有版本控制的 registry 分发。循环重复。

Patrick 对最终状态很现实。"黑暗工厂"愿景——agents 以零人类参与生产代码——是他所说的"一个崇高的方向，但一场危险的游戏。"最接近的团队——那些可以自信地说他们不再阅读代码的团队——是那些在 context、测试和可观测性基础设施上投入大量资金的团队，这些基础设施使他们的 agents 足够可靠，在每个周期中需要更少的人类介入。