@tonygentilcore: https://x.com/tonygentilcore/status/2075234683202531403
摘要
Glean 的工程博客详细介绍了他们的新代理框架,该框架通过代码执行实现 100% 程序化工具调用,与标准工具调用相比,减少 24% 的 Token 使用量。该框架通过工具截断和沙箱文件系统管理上下文,适用于长时间运行的复杂工作流。
查看缓存全文
缓存时间: 2026/07/10 14:11
为高级企业工作构建高效的工具编排框架
智能体编排框架常被讨论为帮助智能体处理更长时间、更复杂工作的一种方式。@Glean 的智能体编排框架通过多种方式实现这一目标,主要依靠上下文管理,让智能体能够跨工具、数据和工作流进行有效推理。该编排框架还支持轨迹学习,帮助智能体系统基于过往会话进行自我改进。路由机制允许专业模型承担它们最擅长的工作,从而使智能体以更低成本实现高质量结果。
但编排框架的设计不仅仅是为了增强智能体的能力。它对 Token 效率也至关重要。在本文中,我们将详细介绍如何将我们的编排框架转向通过代码为每个查询编排工具,以及这种方法即使对简单查询也更为高效的原因。与我们之前的方法相比,Token 使用量减少了 24%。我们还将探讨过程中那些使这些成果成为可能的关键设计决策。
智能体编排框架通过 100% 程序化工具调用实现最佳扩展
Glean 智能体编排框架的标志性特征是 100% 程序化工具调用。模型不直接发出标准工具调用,而是在智能体沙箱中编写代码,通过 Python 运行时和工具 SDK 调用 Glean 的能力。代码是比标准工具调用更好的执行原语,因为编排、过滤、循环和分支都可以在单个脚本执行内完成,而无需分散在多个 LLM 往返中。
在标准的工具调用循环中,每个工具的输入和输出都会被序列化并反序列化回上下文窗口。模型调用一个工具,结果进入上下文,模型读取它并调用下一个工具。对于涉及跨多个系统数十个文档的工作流,这种模式会增加 Token 浪费、延迟和与实际任务逻辑无关的推理开销。
我们第一次尝试程序化工具调用时采用了一种混合方法。标准工具调用处理简单的单步操作,而程序化工具调用处理多工具工作。但要求模型在每次交互时决定使用哪种模式,这引入了自身的开销,蚕食了我们试图实现的效率增益。事实证明,模型在为单个工具调用编写简短脚本方面,与进行标准工具调用同样出色。
因此,我们完全移除了标准工具调用。Shell 现在是直接暴露给模型的唯一工具,让智能体在沙箱中为任何需要调用的内容编写并运行脚本。所有其他能力,包括搜索、写入工具、技能,都通过 Glean 的工具 SDK 暴露。
工具截断将上下文与沙箱文件系统关联起来
像这样的编码编排框架需要一个沙箱文件系统来保存工具输出、中间步骤、数据和推理。这些输出在交互之间保留在磁盘上,而不是淹没模型上下文,上下文则留给高信号推理、决策和截断的工具结果。仅将一个工作流中最具信息量的部分保留在上下文窗口中,有助于编排框架避免上下文腐化,并在需要基于大量数据进行复杂推理的长时间运行工作中保持可靠。
每个编排框架都必须决定模型实际能看到多少工具输出。如果所有内容都留在上下文中,随着上下文积累且模型注意力下降,性能会降低。如果所有内容都被摘要化,模型可能会丢失所需的关键信息。过度摘要化还有一个隐藏成本:由于模型事先不知道特定工具输出的结构,它可能会消耗 Token 来弄清楚如何从文件系统中读取数据。
在 Glean 的编码编排框架中,每个工具调用返回一个截断预览,将完整输出写入文件,并准确告知模型磁盘上有多少内容。模型在需要更多细节时直接读取该文件,不需要时就跳过这一成本。这是可行的,因为一旦模型看到结果的结构以及几个有代表性的行或条目,它就能推断出其余内容,而无需将整个负载放在上下文中。模型只需要知道有用的输出在哪里以及如何获取它。
搜索与渐进式披露保持上下文精简
编码编排框架可以通过工具大规模执行复杂工作流,但将数百个企业技能和工具预加载到上下文窗口中会稀释注意力、降低可靠性并增加成本。因此,我们基于搜索和渐进式披露的组合构建了编排框架。
编排框架从系统指令中一组最小的核心工具开始。这仅包括两个搜索工具:一个用于企业上下文,另一个用于工具和技能。这些核心工具让智能体找到它需要的所有其他资源。当智能体通过搜索找到工具或技能时,它不会立即看到完整内容。它只看到一个轻量级的名称和描述,然后仅在任务实际需要时,通过渐进式披露读取完整的模式或完整的参考集合。
搜索和渐进式披露都是必要的,因为它们解决不同的问题。渐进式披露允许智能体通过只读取与当前任务相关的技能或模式部分来有效使用复杂资源,而不是被其余部分分散注意力。但渐进式披露只在智能体知道要使用哪个资源时才有帮助。搜索则将智能体指向正确的工具或技能,这样当它深入探索时,可以确信自己找对了地方。
围绕一组核心搜索工具重新架构编排框架带来了自身的挑战。每次搜索都会浮现模型需要考虑的新工具和技能,这意味着模型正在推理的指令集可以在每次交互中增长。如果这些上下文被插入到早期的交互中,会使前缀缓存失效——前缀缓存是对话的初始部分,LLM 可以重用其注意力状态而无需重新计算。为避免这种情况,Glean 将搜索结果附加到对话的末尾。这让模型能够对新浮现的工具和技能进行操作,同时不会使前缀缓存失效,从而使响应更快、成本效益更高。
为什么编码编排框架适合长期运行的企业工作
转向编码编排框架反映了企业 AI 领域的一个更大转变。工作越来越多地意味着跨数十个 SaaS 系统的编排和自动化,而不仅仅是基于文本的对话。跨系统工作流需要精确的逻辑和状态管理,而代码比基于自然语言的工具调用更直接地满足这些要求。
编码编排框架也正成为执行智能体任务时最有效的模型无关选项。来自每个领先实验室的前沿模型已经擅长于智能体编码,而开放模型也在迅速追赶。由于广泛的模型都可以驱动 Glean 的编排框架,LLM 编码能力的改进直接转化为更好的智能体执行效果,而无需重新设计。智能体构建者可以根据需求和要求的改变自由地更换模型。
编码编排框架不仅让智能体能调用更多工具。它让智能体能够以更高的效率和可靠性使用工具、上下文和技能,即使是在自动化整个企业所需的 1000 多个工具的规模下。结合一组高精度的核心搜索工具,Glean 的编码编排框架成为了强大工作智能体的基础,这些智能体能够以减少 24% 的 Token 完成高级企业工作流。
相似文章
@trq212: https://x.com/trq212/status/2061907337154367865
Claude Code 发布了动态工作流功能,使得Claude能够为研究、安全分析、代理团队和代码审查等任务创建自定义框架,所有这些都在工具内原生实现。
@mfpiccolo: https://x.com/mfpiccolo/status/2060069083878408689
文章认为,当前像 LangChain 和 CrewAI 这样的智能体编排框架将独立关注点捆绑成一个整体模块,导致缺乏灵活性。文章介绍了 iii 引擎,其中每个职责都是一个独立的、可替换的工作单元,通过共享总线和单一触发原语连接,使开发者能够通过替换工作单元而非分叉框架来组合自己的编排方案。
@akshay_pachaar: https://x.com/akshay_pachaar/status/2053166970166772052
The article discusses a shift in AI agent tool usage from the 'MCP vs CLI' debate to 'Code Mode,' where agents write code to dynamically import tools, significantly reducing context window usage. It highlights Anthropic's approach and Cloudflare's implementation, demonstrating a 98.7% reduction in token consumption for specific tasks.
@sethkarten: https://x.com/sethkarten/status/2072034978112889328
Continual Harness 是一种无需重置、自我改进的智能体框架,通过存储记忆、复用技能和优化提示,在 ARC-AGI-3 上以 774 美元的成本达到了 20.54% 的准确率,以更高的效率超越了 Hermes 和 OpenClaw 等先前基准。
@jasonzhou1993: 我给我的编码代理一张跨3个仓库的地图: - 减少约50%令牌 - 一个grep钩子,使每次grep调用信息更丰富…
Jason Zhou分享了一种技术,为编码代理提供跨仓库的地图,减少约50%的令牌使用,并实现更丰富的grep和调用链追踪。他还发布了一个名为AI Builder Club Skills的Claude Code插件市场,用于设置代码库工具和复合代理循环。