Agent效率优化：Snowflake CoCo如何减少上下文膨胀

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 修复基准测试里，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 照样可能答错。

开始使用：