当创业公司VentureCrowd开始部署AI编程代理时，他们看到了与其他企业相同的收益：在某些项目中将前端开发周期缩短了90%。然而，这些成果并非轻松获得，而是经历了大量试错。首席产品官Diego Mogollon告诉VentureBeat：“代理基于它们在运行时能访问的任何数据进行推理，然后会因为仅基于给定上下文得出结论而自信地’犯错’。”

上下文膨胀：代理失败的真正原因

VentureCrowd的经历揭示了AI代理开发中一个更广泛的问题。模型并没有让代理失败，而是被过多的上下文和过多同时使用的工具压垮了。这种现象被称为“上下文膨胀”（Context Bloat）——当AI系统积累越来越多的数据、工具或指令时，工作流变得更加复杂。

问题的根源在于：代理需要上下文才能更好地工作，但过多的上下文会产生噪声。代理需要筛选的上下文越多，使用的token越多，工作变慢，成本增加。正如Mogollon所说：“挑战很少与编程代理本身有关；它们与代理周围的一切有关。这是一个伪装成AI问题的上下文问题，是我在代理实施中看到的头号失败模式。”

上下文工程：解决问题的关键

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

Salesforce最近将Agentforce Vibes更新到2.0版本，扩展了对ReAct等第三方框架的支持。最重要的是添加了Abilities和Skills功能，企业可以用它们来引导代理行为。Abilities定义代理想要完成什么，Skills是代理用来完成任务的工具。

不同平台的上下文管理策略

不同编程代理平台管理上下文的方式各不相同。Claude Code和OpenAI的Codex专注于自主执行，持续读取文件、运行命令，并随着任务演进扩展上下文。Claude Code有一个上下文指示器，当上下文过大时进行压缩。Salesforce的方法不是最小化代理使用的上下文，而是帮助企业确保上下文保持在其数据模型或代码库之内。

无论采用哪种方法，一致的模式是：大多数系统在管理增长的代理上下文，而不是限制它。上下文持续增长，特别是在工作流变得更加复杂时，使企业更难控制成本、延迟和可靠性。

给构建者的建议

解决上下文膨胀没有单一方案，但模式已经清晰：更多上下文并不总是意味着更好的结果。除了投资上下文工程外，企业还需要尝试最舒适的上下文约束方法。正如Mogollon总结的：“挑战很少与编程代理本身有关；它们与代理周围的一切有关。”

对于企业而言，这意味着挑战不仅仅是给代理更多信息——而是决定什么可以省略。在这个新兴领域，学会“做减法”可能比一味追求更多数据更为关键。