AX
Agent 体验，即环境在多大程度上支持 Agent 在代码库中完成高质量工作。它是 DX 面向 Agent 的对应概念。当同一个 Agent 在一个仓库中表现良好，在另一个仓库中表现糟糕时，即便模型和 Harness 都相同，差异通常也来自 AX。人们本能地会责怪模型或重写 Prompt，但更常见的解决办法其实在仓库里。
良好的 AX 主要包含三个维度：
| 维度 | 良好 AX 的表现 |
|---|---|
| 自动化检查 | 快速、确定性的自动化检查，例如类型检查、测试和代码检查；Agent 无需人工参与，就能根据结果自行纠错 |
| 架构 | Agent 无需读完所有代码就能浏览的代码库：结构可预测，小型接口背后封装了大量行为，名称能准确说明各部分的用途 |
| 空闲上下文 | 保持 Agent.md、Skill 和工具精简，让大部分上下文窗口可用于当前任务，使 Agent 留在高效区间，而不是被信息淹没 |
AX 与 DX 有重叠：良好的检查和清晰的架构对两类使用者都有帮助，但二者也存在差异。人类可以容忍口口相传的知识、缓慢的 CI，以及“账单模块去问 Sarah”这样的做法，Agent 却做不到。IDE 工具提示和精美仪表盘对 Agent 没有帮助；它们需要以文本形式出现在工具结果中的失败信息。一个代码库可能拥有良好的 DX，却有很差的 AX。
避免把 AX 当作 DX 的同义词——两类使用者需要不同的投入。
用法：
“Agent 在 API 仓库里写得很好，在前端仓库里却写得一团糟。”
“API 仓库有严格类型和快速测试套件；前端仓库两者都没有，却有四十个始终加载的 Skill。这是 AX 差距，不是模型问题。”