当创业公司VentureCrowd开始部署AI编码代理时，他们看到了与其他企业相同的收益：在某些项目中将前端开发周期缩短了90%。然而，这并非一帆风顺。他们遇到的最大挑战不是代理本身的能力，而是上下文管理——一个被包装成AI问题的上下文问题。

上下文膨胀：AI代理的隐形杀手

VentureCrowd首席产品官Diego Mogollon告诉VentureBeat：“代理根据它们在运行时可以访问的任何数据进行推理，然后会自信地’犯错’，因为它们只基于给定的上下文来形成知识。”他们的另一个障碍是混乱的数据和不清晰的流程。与上下文类似，编码代理会放大不良数据，因此公司必须先构建结构良好的代码库。

这引出了一个被称为“上下文膨胀”的现象：当AI系统积累越来越多的数据、工具或指令时，工作流变得更加复杂。问题在于代理需要上下文来更好地工作，但过多的上下文会产生噪音。代理需要筛选的上下文越多，消耗的token越多，工作变慢，成本增加。

Agentforce Vibes 2.0的解决方案

VentureCrowd最终选择Salesforce的Agentforce Vibes作为解决方案。这款编码平台内置于Salesforce生态系统中，从免费方案开始即可使用。Salesforce最近将Agentforce Vibes更新到2.0版本，扩展了对ReAct等第三方框架的支持。

对VentureCrowd等公司最重要的是，Agentforce Vibes 2.0新增了“能力”（Abilities）和“技能”（Skills）功能，可用于引导代理行为。能力定义代理想要完成什么，技能则是代理将用来实现目标的工具。

Mogollon表示：“我们的整个平台，前端和后端，都运行在Salesforce生态系统上。所以当Agentforce Vibes推出时，它自然地融入了我们已经熟悉的环境。”

Salesforce的方法不是最小化代理使用的上下文，而是帮助企业确保上下文保持在其数据模型或代码库范围内。这与Claude Code和OpenAI的Codex等其他编码代理平台形成对比——后者专注于自主执行，在任务演进时持续读取文件、运行命令和扩展上下文。

上下文工程：新的关键实践

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

随着工作流变得更加复杂，上下文持续增长，企业越来越难以控制成本、延迟和可靠性。Mogollon表示，他的公司选择Agentforce Vibes不仅因为大量数据已经存在于Salesforce上，更因为它允许公司控制更多提供给代理的上下文。

对于开发者来说，核心启示很明确：更多的上下文并不总是意味着更好的结果。企业在投资上下文工程的同时，必须实验自己最舒适的上下文约束方法。真正的挑战不仅仅是给代理更多信息，而是决定哪些信息应该被排除在外。