Snowflake研究：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 里搜索相关讨论，再定位对应的代码负责人。为了完成调查，它可能需要查询 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 修复基准测试里，CoCo 搭配 Sonnet 5 三次重复试验的通过率达到 86%，Claude Code 搭配 Opus 5 则是 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 回答反复出现的问题时，不用每次都重新摸索相同的数据关联和业务规则。

总结

高效的 Agent 不光要有能力强大的模型和丰富的工具，还需要能智能管理上下文的 Harness，以及可靠的数据业务语义定义。减少不必要的工具定义和原始输出，有助于控制上下文开销；给出清晰的业务定义，则有助于 Agent 生成更贴合企业实际需求的答案。

两者缺一不可：工作流程再精简，缺少必要的业务逻辑，Agent 照样可能给出错误答案。

开始使用：