智能体并没有变聪明——变的是项目

六个月前,一项编码任务需要花费整整一个会话来解释。上周,同类型的任务只需一句话。这两次会话之间,模型并未发生变化。Claude Opus 4.6为两者提供了服务。相同的权重、相同的架构、相同的上下文窗口、相同的能力。

从第1次会话到第500次会话,AI智能体并没有变得更聪明;改变的是项目基础设施。这正是AI工程领域的核心论点:模型是常量,而变量是您围绕它构建的一切。在长期运行的项目中,模型对会话质量的贡献大约只占30%,而累积的上下文则提供了另外70%:约定文档、决策记忆、交接工件、hooks、skills以及测试覆盖。差模型在丰富项目上的表现,往往优于好模型在贫瘠项目上的表现。

项目改变了。

错位的讨论

关于AI生产力的讨论几乎全部围绕模型能力展开。哪个模型最快。哪个模型写出的代码最好。哪个模型能处理最长的上下文。其隐含假设是:模型即变量,升级模型就能改善输出。

对于长期运行的项目而言,这个假设是错误的。在一个我已持续投入六个月、累计500多次智能体会话的项目中,模型对会话质量的贡献大概只有30%。另外70%来自累积的项目基础设施:约定文档、决策记忆、交接工件、行为hooks、编码成形的skills以及测试覆盖。

好模型在贫瘠项目上的输出优于差模型在贫瘠项目上的输出。而差模型在拥有500次会话累积上下文的项目上,其输出往往优于好模型在贫瘠项目上的输出。基础设施主导模型。这正是上下文即架构的原因——累积的项目知识不是补充信息,而是承重结构。

证据

市场页面性能修复的案例说明了这一点。一句话:”修复市场页面的性能问题。”智能体:

1. 读取了上一次会话中诊断瓶颈的交接文档
2. 识别出正确的代码路径(market_hub(),而非_fetch_market_data())
3. 使用聚合RPC实现了分页数据库查询
4. 编写了测试
5. 部署

Austin从14秒优化到108毫秒。单次提示带来了132倍的性能提升。¹

这并非因为模型聪明,而是因为交接文档存在。这份交接在四天内历经三次代码审查修正和两次优先级重排,最终沉淀出一份稳固的诊断结果。如果没有这份交接,智能体就只能从零开始。它会调查错误的代码路径(交接文档的初稿就是这样)。它会提出不必要的HTMX部分模板(最初的方案正是如此)。交接文档包含了此前已经犯过并纠正过的错误。智能体继承的是经过修正后的理解。

模型的贡献是阅读交接并实施修复。基础设施的贡献是让它有正确的交接可读。

什么在变,什么不变

在同一个项目从第1次会话到第500次会话之间,只有一样东西保持不变:模型。其他一切都在改变。

改变的是:

• CLAUDE.md从空白逐步趋于完整。约定层面的问题逐渐消失。AGENTS.md模式一文描述了让这类文件真正发挥作用的具体模式。
• 记忆文件不断累积。决策被缓存。权衡被记录。项目不再反复纠结已经敲定的问题。
• Hooks不断累积。每一个hook都在阻止某一类曾在以往会话中出现过的失败。84个hooks拦截着Claude Code暴露的26种生命周期事件中的15种,每一个都是过往事故留下的伤疤。
• Skills不断累积。重复性工作流变成一条命令即可完成的操作。当初需要整整一个会话才设计出的nightcheck,如今2分钟即可运行。
• 测试不断累积。智能体敢于做出更大胆的改动,因为它能立即验证这些改动。
• 交接文档不断累积。复杂的调查得以跨越会话边界持续下去。

保持不变的是:

• 模型。相同的权重。相同的能力。同样存在偏离任务的倾向、同样会幻觉式地声称测试已通过(详见证据门)、同样会提出不必要的抽象。

模型的失败模式是恒定的。基础设施捕捉这些失败模式的能力则随着每一次会话不断增长。第500次会话比第1次更好,并不是因为模型变强了,而是因为基础设施学会了弥补模型那些固有的薄弱之处。

投资视角

如果模型不是变量,那么模型选型就不是首要的投资决策。首要投资在于上下文基础设施。

一个团队每月花费200美元订阅Claude Max(默认运行Opus 4.7),并大力投资于CLAUDE.md文件、记忆系统、hooks、skills和测试覆盖,其表现将优于另一个同样每月花费200美元、却完全不做基础设施投资的团队。模型成本完全相同。输出质量之所以拉开差距,是因为基础设施拉开了差距。

这重新定义了生产力问题。问题不是”我们应该用哪个模型?”而是”我们围绕模型构建了什么,让每一次会话都比上一次更好?”

我看到在AI生产力方面陷入困境的组织,并不是因为用错了模型。它们每一次会话都是从零开始。没有约定文档。没有记忆系统。没有hooks。没有skills。没有累积的上下文。无论此前经历了多少次会话,每一次都是第1次会话。

模型会不断进步

模型会持续改进。Claude Opus 4.7优于Claude Opus 4.6,Opus 5还会更好。这种进步真实存在、价值显著。但这种进步是加法,而非乘法。

在代码生成上提升20%的模型,在贫瘠项目上产出的质量也相应提升20%。而同一个模型在拥有500次会话累积上下文的项目上产出的结果则是质的不同,而不仅仅是量的提升。上下文基础设施不是给模型能力加20%,它提供的是诊断、约束、验证标准和运维历史——这些是模型单凭自身能力(无论多强)都无法产出的东西。

任何模型,无论能力多强,都不可能知道market_hub()会加载所有company_markets行并在Python中分页——除非有东西告诉它。交接文档告诉了它。模型阅读并行动。智能分布在模型(阅读、推理、实现)和基础设施(知晓、约束、验证)之间。

第500次会话

第500次会话是这样的:我用一句话说明我想要什么。Ralph智能体架构正是让这一切成为可能的系统。智能体读取CLAUDE.md便知晓约定。它读取记忆文件便了解决策。它读取交接便掌握诊断。它撞上一个hook,那个hook正阻止着三个月前另一个智能体犯过的同样错误。它依据测试套件核对自己的工作。它在汇报完成时,为每一个声明都附上证据。

第1次会话是这样的:我解释数据库模式、路由约定、模板继承、缓存层、部署管道以及测试模式。智能体提出澄清问题。它提出一个违反了三条约定的方案。我纠正它。它实施修复。它在没有真正运行pytest的情况下汇报”测试已通过”。

两次会话中,模型是一样的。项目却不一样。

常见问题

模型质量难道不重要吗?

重要。更强的模型能更有效地阅读上下文、更准确地权衡取舍、更干净地实现解决方案。模型质量决定下限。基础设施抬升上限。在一个成熟的项目中,上限比下限更重要。

这是否只适用于编码智能体?

并非如此。任何跨会话反复出现同类任务域的AI工作流,都能从累积的上下文中受益。写作、研究、分析、客户支持。具体的基础设施形态各异(用风格指南代替CLAUDE.md,用知识库代替hooks),但动态规律是一致的:项目之所以越来越好,是因为围绕模型的上下文在不断累积。

多模态模型或推理模型呢?

原理相同。一个可以针对某个问题思考10分钟的推理模型,仍然需要知道该思考什么问题。交接文档、约定文件和记忆系统提供问题定义。模型负责推理。在定义清晰的问题上,更强的推理能产出更好的结果;但在未定义的问题上,更强的推理只会产出听起来更高级的混乱。

如果我完全没有上下文基础设施,该从何入手?

编写一份描述您项目约定的CLAUDE.md文件。这一个文件就是回报率最高的投资。其他一切都会从这里复利增长。²

来源