最近，我遇到了一次明显的 Agent 性能退化。

一个原本预计 20 到 30 分钟完成的开发任务，最后执行了将近 3 小时。它没有卡在某个特别困难的问题上，而是在读取、判断、验证和重新验证之间不断消耗时间。

我开始拆解它面对的工作环境。

Agent 变慢之前，环境已经变重了

我发现了三类问题。

第一类是代码库膨胀。仓库里出现了不少超过 3,000 行的源文件，还有一个约 110,000 行的临时 evidence 文件。.git 目录已经达到 72 MB。

这些数字本身不能证明它们分别造成了多少延迟。真正值得警惕的是：Agent 每次搜索、建立依赖关系和判断文件职责时，需要穿过的噪声明显增加了。临时产物一旦看起来像正式事实，它还必须花时间判断自己能不能相信它。

第二类是我过去让 AI 自动生成的 Skills。它们越来越长，包含大量 step-by-step 的 how-to，以及针对历史问题不断追加的例外。每一条单独看都有理由，合在一起却开始 micromanage Agent。

第三类是安全机制。为了降低错误风险，我给开发和 CI/CD 增加了很多 gate。结果是验证链越来越长，失败点越来越多。Agent 经常不是在解决原始问题，而是在修复验证机制产生的次生问题。

这三个问题共享一个模式：每次遇到风险，我们都增加一点东西。代码、文档和 gate 各自只增长一点，最后却一起进入 Agent 的工作路径。

我先做了减法

针对代码库，我开始检查 LoC 分布，找出异常大的文件，再逐个判断它们应该重构、归档、删除还是保留。

这里不能把“大文件”等同于“坏文件”。我先确认它的真实使用者、权威来源和恢复方式。临时证据文件可以删除，历史事实可能需要归档，承担明确职责的大模块才进入重构。对超过 1,000 行的代码，我会检查它是否混合了多个可以独立判断和测试的责任。

我还开始逐个 review 那些为了防御未来风险而写的抽象和机制。最近安装了 Ponytail，想看看它能否帮助我更稳定地识别过度设计。工具只能辅助判断；真正的问题仍然是：删除这层机制以后，哪个真实风险会重新出现？

更大的变化发生在 Skills 和 AGENTS.md。

从 how-to 转向 what、where 和 why

以前，我会告诉 Agent：

  1. 先运行什么命令；
  2. 再读取哪个文件；
  3. 遇到某个状态时走哪个分支；
  4. 最后按照哪些步骤验证。

这在写下来的那一刻通常是正确的。但 how-to 对外部状态非常敏感：工具会升级，目录会移动，分支会变化，运行时状态也会变化。昨天正确的操作路径，今天可能已经成为绕路。

现在，我更希望 Skill 回答四类问题：

  • What is there：这个领域有哪些实体，它们分别负责什么；
  • Where are they：权威事实、运行状态和输出各自在哪里；
  • What you might miss：哪些边界、例外和失败状态容易被忽略；
  • Why：为什么这些约束存在，保护的是什么。

一次 session 则用 Goal 描述本次要达到的结果、验收标准和授权边界。Agent 取得这些相对稳定的信息以后，根据当前环境自己找出 how。

Goal
  本次要完成什么，怎样算完成

Skill / Context
  有什么 → 在哪里 → 容易漏掉什么 → 为什么重要

Agent
  读取实时状态 → 决定这一次怎么做 → 用结果验证

这并不意味着完全不给操作指导。危险、不可逆或者必须保持一致的动作，仍然需要明确规则。差别在于：规则描述不变量和决策边界，操作手册只在确实存在唯一正确路径时出现。

这不是我一个人的错觉

后来我发现，行业正在用不同名字描述相似的变化。

Anthropic 将它称为 Context Engineering：上下文是有限的 attention budget，目标是找到能够产生预期行为的最小高信号信息集。过度硬编码 Agent 行为会形成脆弱、难维护的 Prompt；更好的做法是在足够具体和保留判断空间之间找到合适的高度。

Anthropic 在 SWE-bench Agent 中也采用了 minimal scaffold：提供任务、仓库和少量基础工具，让模型自己决定如何推进，而不是把工作流固化成严格的状态转换。

OpenAI 最近把代码库侧的实践称为 Harness Engineering。其中一个原则准确概括了我想做的事：集中强制边界，在边界内部保留自主性。人负责目标、优先级和验收；仓库让架构、工具和事实可被 Agent 发现；Agent 负责具体执行路径。

所以，“少写 how-to”只说对了一半。有效的减法需要同时完成两件事：

  1. 删除容易过期的过程控制；
  2. 提高环境事实、职责边界和验收条件的可发现性。

否则，简短的 Skill 只会变成信息不足。

初步结果

我把一批 Skills 里的 how-to 拆掉，保留职责、位置、遗漏点和原因。Skill 正文减少了 50% 以上。

目前我没有足够严谨的数据声称生产率提升了多少。主观体验是 Agent 更少陷入对旧步骤的机械执行，完成任务的速度更好。下一步需要记录任务耗时、无效工具调用、重复验证和人工介入次数，才能把这种体验变成可信的结论。

还没解决的是安全门

代码和 Skill 可以通过删除、归档与重构逐步瘦身。安全 gate 更难，因为等待成本很容易看见，被它阻止的事故通常没有发生，也就更难衡量。

我现在准备换一个审查方式。对每个 gate，不再只问“它是否让系统更安全”，而是问：

  • 它保护的是哪个已经识别的风险？
  • 它约束的是结果与不变量，还是在规定实现过程？
  • 它真实捕获过多少缺陷，又制造了多少误报和等待？
  • 它能否并行、按风险触发，或者移到更靠近最终边界的位置？
  • 删除它以后，现有测试、权限或回滚机制能否覆盖同一个风险？

OpenAI 的 Agent 实践指南建议根据真实发现的风险逐步增加 guardrail，并同时优化安全性和用户体验。对我来说，这意味着安全机制同样需要证据和生命周期；它不能因为名字叫“安全”就永久免于审查。

我现在对 Agent 协作的理解是：

给 Agent 目标、现实和边界。让它根据这一次的现实，决定这一次的路径。

Agent 变强以后，人最有价值的工作可能不再是写出更详细的步骤，而是让真正重要的事实更容易被看见，让关键边界更难被越过。