Box 管理着超过十万家企业的非结构化内容。它面对的 Agent 问题不是“如何回答一份 PDF”，而是如何在既有权限体系内搜索成千上万份文件、识别重复和过期信息、并行分析多个来源，并生成带引用的报告。
Box AI 最初也是从单文档问答开始，随后加入 Knowledge Hubs，让用户通过 RAG 查询一个定义好的知识源。但当生命科学团队开始要求综合已有研究、法律团队开始要求筛选过去十年的合同并按风险标准评估时，传统问答架构不再够用。
Box 最终基于 LangChain 的 Deep Agents 构建 Box Agent。真正值得研究的不是框架名称，而是团队在生产环境中做出的几项反直觉选择：不预先固定所有子 Agent、不为每个请求缩减工具列表，并把引用、缓存和上下文管理放到统一中间件里。
#从问答系统到任务执行系统
单文档问答的基本流程很清晰：检索相关段落，把它们交给模型，再生成答案。Knowledge Hub 把检索范围扩大到一组文件，但系统仍然围绕一次“查找并回答”设计。
企业用户提出的复杂请求却包含多个相互依赖的步骤。例如：找出过去十年金额超过某个阈值的全部合同，找到适用的风险评估标准，然后逐份分析并汇总结果。
这类任务同时涉及：
- 多种检索方式；
- 跨文件去重与时效判断；
- 结构化和非结构化数据处理；
- 并行执行与依赖协调；
- 来源引用与权限继承；
- 长上下文和中间产物管理。
如果继续把所有步骤塞进一次模型调用，任务规模越大，可靠性越差。Box 需要的不是更大的问答窗口，而是一个能规划、拆分、执行和汇总的运行系统。
#为什么选择 Deep Agents
Box 在评估 Agent 框架时有两个硬要求。
第一是完全的模型无关性。Box 向企业客户提供 OpenAI、Anthropic、Google 等多家模型供应商的选择，因此 Agent 平台不能把产品逻辑锁死在单一模型上。
第二是迭代速度。Box 团队希望把工程时间投入权限、企业搜索、引用和内容治理等自身差异化问题，而不是重复搭建通用 Agent 基础设施。
Deep Agents 的模型抽象层保留了供应商路由能力，开放式 Agent Harness 则让 Box 可以控制各个组件。按照案例中的团队数据，这套基础设施将迭代速度提高到原来的 3 倍。
这个数字来自 Box 自身产品和开发流程，并不是所有 Deep Agents 项目的通用性能承诺。它更适合被理解为“复用 Harness 后省下了多少基础设施开发时间”。
#Global Agent：简单任务直接做，复杂任务再拆分
Box Agent 使用递归的父子架构。父 Agent 被称为 Global Agent，它接收请求、判断意图，然后决定直接处理，还是动态创建子 Agent。
这是对早期设计的一次重要修正。旧架构预先定义了搜索 Agent、问答 Agent 和写作 Agent。无论任务复杂与否，请求都要经过固定角色，增加了不必要的规划和通信延迟。
新架构不把“多 Agent”当成默认答案：
- 简单查询由 Global Agent 直接调用工具完成；
- 复杂任务才生成计划并拆出多个子 Agent；
- 子 Agent 以工具形式暴露给父 Agent，调用方式与普通搜索工具保持一致；
- 子 Agent 数量与职责由运行时任务决定，而不是产品团队预先穷举。
这样一来，简单任务不会为架构复杂度付费，复杂任务又能获得并行执行和上下文隔离的好处。
#动态子 Agent 如何处理复杂合同分析
以合同风险分析为例，Global Agent 可以生成如下执行图：
- 一个子 Agent 搜索满足年份和金额条件的合同；
- 另一个子 Agent 并行查找风险评估标准；
- 前两项完成后，第三个子 Agent 综合合同与标准并执行分析；
- Global Agent 汇总结果，生成最终报告。
每个子 Agent 都有隔离的上下文窗口，只接收完成自身任务所需的信息。它们通过中间件报告结果，不必把所有搜索过程、原始文件和推理痕迹同时塞进父 Agent 的上下文。
动态生成还有一个产品层面的好处：系统能够处理团队没有提前设计专用流程的新任务。Global Agent 在运行时决定需要哪些子 Agent，以及把什么目标交给它们。
#为什么所有 Agent 都看到完整工具注册表
Box 的父 Agent 和子 Agent 可以访问同一套完整工具，包括 BM25 关键词搜索、向量搜索、电子表格结构化问答、文件操作等。
常见做法是在每个请求前先预测需要哪些工具，只把一个小子集暴露给模型。这能缩短工具描述，却引入了一个新的静态路由器：如果前置判断漏掉关键工具，后续 Agent 再聪明也无法完成任务。
Box 的经验是，随着用例增多，模型自己选择工具比静态选择逻辑更可靠。因此团队保留完整注册表，让父子 Agent 根据当前任务决定调用什么。
这并不意味着任何工具都应无条件开放。工具可见性与执行权限是两个问题：模型可以知道某项能力存在，但敏感操作仍应受用户身份、Box 权限、审批规则和运行时策略约束。Box Agent 的检索与分析建立在现有安全和权限模型之上。
#中间件不是装饰，而是 Agent 的系统总线
Box 使用 Deep Agents 中间件拦截模型调用和工具调用。它既可以注入护栏、审批和动态上下文，也承担四项关键生产职责。
#引用生成与答案流式输出并行
多文档回答需要把结论映射回来源。Box 没有等正文生成完再串行计算引用，而是在流式输出答案的同时启动引用生成。嵌入匹配负责建立内容和来源之间的对应关系，并通过额外逻辑让引用合理分布在多个文档之间。
当正文流式输出结束时，引用也已准备好，因此用户不会为了来源标注再等待一轮完整处理。
#Prompt Cache 控制多轮对话成本
随着对话历史增长，重复发送相同上下文会同时增加延迟和费用。中间件在多轮会话中注入 Prompt Cache，让稳定前缀可以复用，而不需要修改核心 Agent 逻辑。
缓存被放在中间件层也意味着它可以统一覆盖父子 Agent，而不是散落在各个工具或业务流程里。
#超长上下文自动压缩
当会话历史超过 170,000 Token 时，中间件自动执行摘要，防止上下文溢出。Agent 本身不需要为每个模型单独实现长度检查和压缩逻辑。
这个阈值是 Box 当前实现里的策略参数，不是普遍适用的固定答案。真正重要的是把上下文治理做成独立、可替换的运行层。
#父子 Agent 通过中间产物通信
子 Agent 完成搜索后，把结果写入中间件；父 Agent 和其他子 Agent 可以读取并继续处理。中间件因此成为一次执行内部的产物通道，而不只是模型调用前后的钩子。
这种设计避免依赖自然语言消息传递全部状态。搜索结果、引用映射和结构化分析可以作为明确的中间产物流转，降低多 Agent 协作中的信息损失。
#从三个月到数周，速度来自删除固定结构
Box 最早采用硬编码专业子 Agent 的架构，开发和上线大约用了三个月。后续递归父子架构的交付速度提高了 4 倍；使用当前技术栈后，团队能够在几周内推出一个新 Agent。
3 倍迭代速度和 4 倍架构交付速度描述的是案例中的不同观察口径，不能简单相乘。它们共同说明的不是“多 Agent 一定更快”，而是减少自建 Harness 和删除不必要的固定角色后，团队可以更快改变系统行为。
这也是 Box 架构演进最值得借鉴的地方：第一次设计关注如何把职责分给不同 Agent，第二次设计关注任务究竟需不需要拆分。后者把复杂度变成按需成本。
#企业 Agent 的长期方向是机构知识
Box 当前已经支持企业级搜索、多文档综合和结构化报告生成。下一阶段目标是让 Agent 拥有类似资深员工的机构知识：知道信息如何关联、哪些内容已经过时，以及不同团队如何使用同一份材料。
路线图包括更丰富的记忆与知识组合、后台离线运行，以及与内部团队和外部系统进行更深的通信。
这里的挑战不会只靠扩大上下文窗口解决。机构知识需要权限感知、时间信息、来源追踪、记忆更新和冲突处理。Box 现有的中间件与动态 Agent 架构，正是在为这些能力准备运行基础。
#Box 案例给 Agent 工程的五条启示
第一，不要把多 Agent 当成默认架构。让父 Agent 直接处理简单任务，只在工作可以并行或需要隔离上下文时创建子 Agent。
第二，子 Agent 应该是运行时资源，而不是静态组织结构。任务决定角色，角色不应反过来限制任务。
第三，工具路由器本身也会制造失败点。当模型已经具备足够的工具选择能力时，完整注册表可能比静态裁剪更稳，但执行权限仍要单独控制。
第四，把引用、缓存、上下文压缩和中间产物通信放进中间件。它们属于运行系统，不应该污染每个业务 Agent 的提示词。
第五，评估架构时要看迭代速度和端到端延迟，而不只看单次回答质量。一个需要三个月才能增加新工作流的 Agent 平台，很难跟上企业需求变化。
Box AI 的演进最终说明：企业内容 Agent 的核心并不是让模型读更多文件，而是建立一个能根据任务动态组织计算、继承既有权限、管理长上下文，并把结论可靠映射回来源的系统。