当创业投资平台VentureCrowd开始部署AI编程代理时，他们看到了与其他企业相同的收益：在某些项目中将前端开发周期缩短了90%。但实现这一成果远非一帆风顺。首席产品官Diego Mogollon指出：“代理根据运行时能访问的任何数据进行推理，然后会自信地’犯错’，因为它们只基于给定的上下文做出判断。”

VentureCrowd的经历揭示了AI代理开发中的一个更广泛问题：模型并没有辜负代理，而是被过多的上下文和同时面对过多工具所淹没。

什么是上下文膨胀？

这一现象被称为“上下文膨胀”（Context Bloat）。当AI系统随着工作流变得越来越复杂而积累越来越多的数据、工具或指令时，问题就会出现。代理需要上下文才能更好地工作，但过多的上下文会产生噪声。代理需要筛选的上下文越多，消耗的token就越多，工作速度变慢，成本增加。

控制上下文膨胀的一种方法是上下文工程（Context Engineering）。上下文工程帮助代理理解代码变更或拉取请求，并使其与任务保持一致。然而，上下文工程往往变成一项外部任务，而非内建在企业用来构建代理的编程平台中。

不同平台的应对策略

VentureCrowd最终选择了Salesforce的Agentforce Vibes作为解决方案。这个编程平台运行在Salesforce生态中，最近更新到2.0版本，新增了Abilities和Skills功能。Abilities定义代理想要完成什么，Skills是代理将使用的工具。Salesforce的方法不是最小化代理使用的上下文，而是帮助企业确保上下文保持在其数据模型或代码库范围内。

相比之下，Claude Code和OpenAI的Codex专注于自主执行——持续读取文件、运行命令并随着任务演进扩展上下文。Claude Code有一个上下文指示器，当上下文过大时会自动压缩。这些平台的不同之处在于，大多数系统管理的是代理不断增长的上下文，而非限制上下文。

给构建者的建议

没有单一的方法来解决上下文膨胀问题，但模式已经清晰：更多上下文并不总是意味着更好的结果。企业必须在投资上下文工程的同时，实验最适合自己的上下文约束方法。

Mogollon的经验值得所有AI代理构建者借鉴：“挑战很少来自编程代理本身，它们来自代理周围的一切。这是一个伪装成AI问题的上下文问题，也是我在代理实施中看到的头号失败模式。”

这意味着企业技术团队在部署AI代理时，应该把更多精力放在数据治理、流程梳理和上下文架构设计上，而非仅仅关注模型能力的提升。代理的智能上限，往往取决于它所能看到的世界的质量而非数量。