上下文也是成本：Agent 效率优化的新思路 ｜ 技术趋势

2026 年，智能体将在企业级应用中取得哪些实质性突破？ 点击下载 "《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！ 你的 Agent 并不缺信息，它只是被信息淹没了。 每一项工具定义、每一次查询结果、每一轮对话，都会增加 Agent 工作时需要处理的上下文。在一项持续时间较长的调查任务中，这些额外开销会不断累积。即使早期步骤中的信息已经不再相关，Agent 仍可能在后续每一轮交互中反复携带这些内容。 这就是上下文膨胀（Context Bloat）。它不仅会增加 token 消耗，还可能让 Agent 更难聚焦于真正重要的信息。 单纯扩大上下文窗口，并不能从根本上解决这一问题。更有效的方法是管理哪些信息进入上下文、哪些信息需要保留，以及 Agent 在开始执行任务之前需要掌握哪些知识。 Snowflake AI Research 在 Snowflake CoCo 和 Snowflake CoWork 中探索了这一问题。相关研究提出了两条相辅相成的 Agent 效率优化路径：一是构建能够智能管理上下文的运行框架（Harness），二是提前为 Agent 提供业务上下文，减少其自行探索和理解业务信息的成本。 问题所在：每一轮交互都有成本 假设某条数据管道在夜间运行时发生故障。Agent 需要找出最常见的错误，在 Slack 和 Jira 中搜索相关讨论，并定位对应的代码负责人。 为了完成调查，Agent 可能需要查询 Snowflake、搜索 Slack、查找 Jira 问题记录，以及检查代码。传统的 Agent 架构可能会在调查开始前，就将所有可用工具的定义加载到上下文中，尽管实际只会用到其中少数工具。 随后，各种查询结果开始陆续返回。一次数据库查询可能返回数千行数据，一次 Slack 搜索可能返回冗长的讨论记录。每一轮交互都会向对话中添加更多信息，而模型必须对这些信息进行处理。 问题并不在于 Agent 拥有太多能力，而在于它需要同时携带和处理的信息过多。 Snowflake CoCo 如何减少上下文膨胀 Snowflake AI Research 团队从 Agent Harness 入手解决这一问题。Harness 是负责协调工具调用、管理上下文，以及连接模型与外部系统的软件层。 CoCo 的 Harness 不再让模型自行处理整个过程中的所有环节，而是负责管理工具的发现方式、独立操作的执行方式，以及工具结果进入上下文的方式。 其中，三项技术发挥了关键作用。 按需加载工具 即使 Agent 可以访问数十种工具，也没有必要从一开始就将所有工具定义加载到上下文中。 CoCo 可以根据任务需要动态发现相关工具，并在实际使用时将其定义引入工作流程。这样既能保留完整的工具调用能力，又不必让所有工具定义占据初始上下文空间。 这一机制对需要处理多种不同任务的通用 Agent 尤为重要。例如，在调查数据管道故障时，Agent 可能需要 Snowflake 查询工具和 Slack 搜索工具，却不需要加载与当前工作无关的其他工具。 并行执行相互独立的工具调用 假设 Agent 需要搜索 Slack、查找 Jira 问题记录，并查询数据仓库中的遥测数据。如果这些操作之间不存在依赖关系，那么将它们拆分到多个模型交互轮次中依次执行，就会产生不必要的开销。 CoCo 可以将相互独立的工具调用合并为一次统一调度，收集执行结果后，再一并返回给模型处理。 当然，工具调用之间的依赖关系仍然需要得到保证。如果某项操作依赖另一项操作的输出，就必须保留正确的执行顺序。优化的关键在于：对于能够并行完成的工作，尽量避免额外的交互轮次。 尽可能避免将大量结果直接放入上下文 一次查询返回数万行数据，并不意味着模型需要在后续每一轮交互中反复处理所有数据。 CoCo 的方法包括压缩工具输出，并对大规模结果进行管理，让 Agent 能够利用相关信息完成任务，同时避免在整个对话过程中反复携带完整的原始输出。 以数据管道故障调查为例，Agent 可以优先处理按类别汇总的错误信息、错误次数、时间戳和具有代表性的案例，并在需要时继续访问底层原始数据。 这些技术相结合，可以减少不必要的上下文负担，避免多余的工具调用往返，并帮助模型将注意力集中在完成当前任务所需的信息上。 实际测试结果如何？ 在 Snowflake AI Research 的内部 SQL 修复基准测试中，使用 Sonnet 5 的 CoCo 在三次重复试验中取得了 86% 的通过率，而使用 Opus 5 的 Claude Code 通过率为 72%。 同时，CoCo 每次试验的报告成本降低了 33%，从 0.446 美元降至 0.298 美元。 这些结果仅适用于测试所采用的特定配置和工作负载，并不意味着所有 Agent 都能获得相同的性能提升。不过，它们说明了一个重要问题：衡量 Agent 效率时，除了关注 token 使用量，还应结合任务完成情况进行评估。 问题的另一面：你的 Agent 真正理解数据的含义吗？ 设计良好的 Harness 可以帮助 Agent 更高效地工作，但效率提升并不意味着一定能够得到正确答案。 回到前面的数据管道故障调查。Agent 已经找到了失败的任务，并计算出了错误率。但它是否知道哪些工作负载属于生产环境？是否清楚哪些测试任务应该被排除？又是否理解企业内部对错误率的具体定义？ 这些业务规则未必能够直接从表名和列名中看出来。如果缺少相关信息，Agent 可能生成语法正确、能够正常执行的 SQL，并返回一个看似合理的数值，但这个结果未必符合实际的业务定义。 这正是语义视图（Semantic Views）发挥作用的地方。 语义视图用于描述数据在业务层面的含义，包括指标、维度、关系以及相关业务逻辑。通过提供经过治理、可重复使用的定义，Agent 就不必自行推断数据表之间的关联，也不需要反复探索某项指标的计算方式。 这里有一个重要区别：Harness 解决的是 Agent 如何高效利用上下文的问题；语义视图则帮助确保 Agent 拥有回答问题所需的正确上下文。 构建 Agent 真正需要的上下文 传统上，语义建模需要数据团队手动定义指标及其关联关系。Snowflake Semantic View Autopilot 可以利用现有数据、查询历史、SQL 示例以及受支持的 BI 资产自动生成语义视图，从而加快这一过程。随后，团队可以在 Semantic Studio 中审核和完善相关定义。 你不必一开始就为整个企业的数据资产建立语义模型。可以先选择一个经常因指标定义不一致而产生理解偏差的业务领域，例如数据管道运行状况、客户活动、营收或客户支持表现。 首先梳理业务人员最常提出的问题、用于回答这些问题的 SQL，以及相关指标背后的业务规则。以此为基础构建语义视图，再对生成的关系和定义进行审核，确认无误后投入使用。 这样就能形成可复用的业务上下文，帮助 Agent 回答反复出现的问题，而无须每次都重新探索相同的数据关联和业务规则。 了解 Snowflake 如何为 AI Agent 构建语义上下文 " 总结 高效的 Agent 需要的不