当创业众筹平台VentureCrowd开始部署AI编码代理时，他们看到了与其他企业相同的收益：某些项目的前端开发周期缩短了90%。然而，这一成果来之不易，伴随着大量试错。他们的核心发现是：“挑战很少在于编码代理本身，而在于围绕它们的一切。这是一个伪装成AI问题的上下文问题，也是我在代理实施中看到的头号失败模式。”

上下文膨胀：代理的隐形负担

这种现象被称为“上下文膨胀”（Context Bloat）——当AI系统在更复杂的工作流中积累越来越多的数据、工具或指令时，就会出现这种问题。

问题的根源在于代理需要上下文才能更好地工作，但过多的上下文会产生噪音。代理需要筛选的上下文越多，消耗的token就越多，工作速度就越慢，成本就越高。而且，代理推理所依据的是运行时可以访问的任何数据——如果给它的上下文是混乱的或过时的，它就会自信地“犯错”。

这不是模型能力的问题，而是信息管理的问题。正如VentureCrowd首席产品官Diego Mogollon所说：“代理会放大数据中的错误，因此公司必须先构建一个结构良好的代码库。”

不同平台的应对策略

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

Salesforce的Agentforce Vibes 2.0采取了一种独特的方法。它不最小化代理使用的上下文，而是帮助企业确保上下文保持在其数据模型或代码库范围内。新版本增加了Abilities和Skills功能——Abilities定义代理想要完成什么，Skills是它们将使用的工具。

Claude Code和OpenAI的Codex则采用了不同的策略，侧重于自主执行，随着任务演进不断读取文件、运行命令并扩展上下文。Claude Code有一个上下文指示器，在上下文过大时进行压缩。但这些系统大多是管理增长中的上下文，而非限制上下文。

给构建者的关键启示

没有单一的方法可以解决上下文膨胀，但模式已经清晰：更多的上下文并不总是意味着更好的结果。

策略一：上下文切片。将大型任务分解为更小的、上下文范围明确的子任务。每个代理只接收完成其特定子任务所需的最小上下文集。这减少了噪音，降低了token消耗，并使每个步骤的输出更容易验证。

策略二：上下文生命周期管理。为上下文设置过期时间。工作流步骤完成后，清除该步骤的临时上下文。保持长期记忆（如项目规范）和短期记忆（如当前迭代的代码变更）之间的明确分离。

策略三：工具权限最小化。不要一次性给代理所有可用工具。根据当前任务阶段，只授予必要的工具访问权限。这不仅减少了上下文噪音，还降低了代理执行意外操作的风险。

策略四：结构化上下文注入。用明确的结构（如JSON schema或带标签的文档段落）代替非结构化的文本块。结构化信息让代理更容易理解和正确使用所提供的上下文。

对于企业而言，挑战不仅仅是给代理更多信息——而是决定什么应该被排除在外。在AI代理日益普及的今天，学会“减法”可能比学会“加法”更为重要。