AI Agent 为什么看起来很忙，却做不好真实工作

很多 AI Agent 看起来已经很忙了。

它会搜索文件，会打开文档，会总结内容，会调用工具，会生成报告。屏幕上不断出现工具调用记录，文件一个个被读取，任务一步步推进。你甚至会有一种感觉：它已经像一个真的助手，正在替你干活。

但等最终结果出来，你又会发现不太对。

它漏掉了关键材料，用了过期版本，把背景文档当成了最终方案，把历史草稿当成了当前结论。它看了很多文件，却没有意识到哪份文件才是源头，哪份文件只是派生版本；它引用了很多内容，却没有分清哪些是约束，哪些只是参考；它输出了一份看似完整的结果，但里面最重要的上下文关系是错的。

这就是很多 AI Agent 的尴尬之处：

它看起来很忙，但不一定真的理解工作。

真实工作并不是“读一个文件，然后回答一个问题”。真实工作更像是进入一个长期演化的工作空间：里面有文档、表格、PPT、邮件、代码、会议纪要、历史版本、临时草稿、最终版、备份版，还有一堆没人来得及整理的上下文。

人类在这样的环境里工作，做的第一件事往往不是写，而是判断。

哪份材料是最新的？
哪个数据表是这次任务真正需要的？
哪个会议纪要推翻了之前的方案？
哪个 PPT 是对外版本，哪个只是内部草稿？
哪个文件只是背景材料，哪个文件会直接影响最终结论？

这些判断很少被写进任务描述里，却决定了工作质量。

所以，AI Agent 离真实工作还有多远，关键不在于它能不能读文件，而在于它能不能读懂工作空间。

现在很多 AI 产品给人的第一印象是：文件终于可以交给 AI 了。

上传一个 PDF，让它总结；丢一份表格，让它分析；给几份材料，让它生成报告。这些能力确实有价值，也已经覆盖了很多局部场景。

但如果把它放到真实工作里，很快就会遇到边界。

真实任务很少只依赖一个文件。你要更新一个客户方案，可能需要旧版方案、最新沟通记录、价格表、竞品材料、产品路线图和最近一次会议纪要。你要整理一个项目进展，可能需要需求文档、排期表、Issue、PR、测试报告、上线记录和数据看板。你要判断一个功能要不要改，可能还要回头看历史决策、用户反馈、事故复盘和当前系统约束。

这些材料不只是“相关文件”的集合。它们之间有关系。

有的是源头，有的是派生；有的是新版，有的是旧版；有的是背景，有的是证据；有的是约束，有的是结论；有的是被后续会议推翻的历史记录，有的是仍然有效的当前共识。

如果 Agent 只会把这些文件都读一遍，再做一个综合总结，它很容易看起来很努力，但实际上没有抓住工作本身。

因为真实工作的核心不是信息堆叠，而是关系判断。

《Workspace-Bench 1.0》这篇论文的价值，在于它没有继续把 Agent 放在一个干净题目里评估，而是把它放进一个更接近真实工作的 workspace 里。

论文构造了不同职业角色的工作空间，里面包含多种文件格式、大量文件、复杂目录结构和跨文件依赖。任务也不是简单问答，而是要求 Agent 在这些文件之间找到正确材料，理解文件关系，并完成真实工作任务。

根据论文介绍，Workspace-Bench 覆盖了 5 类 worker profiles、74 种文件类型、20476 个文件和 388 个任务，并设计了 7399 条评估 rubrics。它不是只看 Agent 最后有没有写出一段像样的回答，还会评估 Agent 是否找到了正确文件、是否理解了文件依赖、是否使用了正确版本，以及最终产物是否满足任务约束。

这和很多传统评测不一样。

传统评测更像是：这里有题目，这里有上下文，请回答。
Workspace-Bench 更像是：这里是一个人的工作空间，里面有大量材料，现在你要完成一件工作，请自己找到需要依赖的文件，并判断它们之间的关系。

这个差异非常重要。

因为真实工作中的上下文，往往不是被整理好后交给 Agent 的。它散落在文件系统、历史版本、附件、邮件、表格、会议记录、项目文档和代码仓库里。Agent 必须先恢复上下文，才谈得上完成任务。

论文把这种能力称为 Workspace Learning。简单说，就是 Agent 能不能在工作空间里识别、推理、利用和更新不同文件之间显性或隐性的依赖关系。

这组评测结果也不轻松。论文里当前 Agent 的表现明显低于人类专家辅助完成任务的结果，尤其是在复杂任务、跨文件关系理解和版本谱系追踪上，Agent 会出现明显退化。

这个结果真正有价值的地方，不是又给 Agent 排了一个榜，而是把一个长期存在但不容易被看见的问题显性化了：

Agent 会读文件，不代表它理解工作空间。

Workspace-Bench 里有一个很关键的设计：每个任务都有自己的文件依赖图。

这意味着，完成任务不是只要找到几个关键词相关的文件就行，而是要理解这些文件之间的关系。

这件事对 Agent 很难。

找到文件，是一个检索问题。
理解关系，是一个工作理解问题。

比如两个文件都提到了同一个客户。一个是去年版本的方案，一个是今年最新的报价说明。Agent 如果只看关键词，会觉得它们都相关；但如果要完成当前任务，它必须知道哪个是历史参考，哪个是当前依据。

再比如一份会议纪要里改变了之前的产品方向，但旧 PRD 仍然保留在目录里。Agent 如果只是读取旧 PRD，很可能生成一个过时结论；如果它能理解会议纪要和 PRD 之间的关系，就会知道旧方案已经被修正。

还有很多真实工作中的关系更隐蔽。

文件名可能叫 final，但并不是最终版。
最新版可能不是按时间排序最晚的文件。
一份表格可能只是中间计算结果，不是最终口径。
一个文档可能不是答案来源，却决定了答案边界。
一段聊天记录可能没有正式归档，却推翻了之前的方案。

这些东西，人类在工作中会通过经验、语境和追问来判断。但 Agent 如果没有工作空间理解能力，就只能在文件之间机械穿梭。

这就是为什么它看起来很忙，却仍然做不好真实工作。

很多 Agent 的执行过程，会给人一种“它正在认真工作”的感觉。

它不断搜索、打开、总结、再搜索、再打开、再总结。工具调用越多，过程越长，似乎越像一个认真负责的员工。

但这可能只是昂贵的混乱。

如果 Agent 没有形成正确的文件依赖图，它读得越多，反而越容易被噪声带偏。它可能在旧材料里反复打转，也可能把支持性背景当成核心证据，还可能因为缺少状态管理，在多轮探索中忘掉前面已经确认过的判断。

真实工作不是把所有材料都读完，而是知道应该读什么、先读什么、哪些可以跳过、哪些必须交叉验证。

所以，衡量 Agent 不能只看它跑了多少步、用了多少 token、调用了多少工具。更重要的是看：

它是否找到了关键文件；
是否识别了文件之间的关系；
是否区分了旧版和新版；
是否知道哪些材料是背景，哪些材料是证据；
是否能解释最终结果依赖了哪些上下文；
是否能在发现冲突时回到正确位置修正判断。

这些能力，才决定 Agent 能不能从“看起来在工作”，走向“真的完成工作”。

如果把这篇论文放回 AI 研发自动化的语境里，它给我们的启发就更直接了。

上一篇我们讨论的是 AI Coding 为什么会在真实仓库里翻车。真实仓库已经很复杂了：有历史遗留、旧接口、重复实现、模块迁移、过期文档和测试差异。

但这还只是更大工作空间的一部分。

真实研发组织里的上下文，从来不只在 repo 里。它还包括需求文档、PRD、设计稿、接口文档、Issue、需求卡、Bug 单、测试报告、会议纪要、IM 讨论、埋点表、数据看板、灰度记录、故障复盘和历史决策。

也就是说，真实研发上下文更像是：

代码仓库 + 文档 + 任务单 + 沟通记录 + 数据指标 + 历史决策

一个 Agent 如果只懂代码仓库，它只能做局部开发。
一个 Agent 如果能理解整个研发工作空间，它才可能参与更完整的研发链路。

这也是为什么端到端研发自动化不能只围绕 Coding Agent 展开。Coding Agent 只是执行层的一部分，真正困难的是把需求、上下文、约束、方案、代码、验证和交付连接起来。

从这个角度看，Workspace-Bench 讨论的不只是“办公 Agent”问题。它也在提醒我们：未来的 AI 研发自动化，需要从代码仓库理解，继续走向研发工作空间理解。

过去我们经常用 RAG 来解决知识访问问题。

先把文档切块，建立索引，用户提问时召回相关片段，再让模型基于片段生成答案。这个思路在很多问答场景里有效，也仍然是 Agent 获取外部知识的重要基础。

但放到真实工作空间里，传统 RAG 很快会遇到边界。

问题不是 RAG 没有价值，而是如果检索结果只是一些扁平片段，Agent 仍然很难回答更关键的问题：这些片段之间是什么关系？

哪个文件是源头，哪个文件是派生；
哪个版本有效，哪个版本已经过期；
哪个文档提供背景，哪个文档提供结论；
哪个表格是中间计算，哪个表格是最终口径；
哪个会议纪要改变了之前的计划；
哪个代码模块受某个需求影响。

这些关系如果没有被表示出来，Agent 就只能在一堆片段里拼答案。

所以，这篇论文更准确的启发不是“RAG 过时了”，而是 RAG 正在从一次性检索，走向更 Agentic 的形态：先拆解问题，再迭代搜索，再判断上下文是否足够，最后把检索到的信息组织成可被任务使用的关系结构。

Google 之前关于 Agentic RAG 的文章也在讲类似方向：面对复杂企业问题，系统不能只做一次检索，而要通过规划、查询改写、跨数据源搜索和“上下文是否充分”的判断，持续寻找足够的信息。

Workspace-Bench 则把这个问题进一步推到工作空间层面：Agent 不只要找片段，还要理解文件、版本、任务和结果之间的依赖关系。

所以，我更愿意把这个方向称为从 RAG 到 Workspace-aware RAG，或者更进一步，走向 Workspace Dependency Graph。

未来很多 Agent 产品的核心差异，可能不在于接入了多少文档，也不在于支持多少工具，而在于它能不能把一个人的工作空间建模成有关系、有版本、有依赖、有状态的上下文网络。

AI Agent 看起来越来越强了。

它会写代码，会读文件，会生成文档，会调用工具，会在屏幕上跑很长的执行链路。很多时候，它已经足够像一个正在工作的助手。

但真实工作不是动作的集合。

真实工作是上下文、关系、判断和取舍。

一个 Agent 可以很忙，但如果它没有理解工作空间，它的忙碌就只是文件遍历、工具调用和文本生成。它可能消耗了很多 token，打开了很多材料，输出了一份很完整的结果，却仍然错过了真正重要的上下文。

所以，AI Agent 的下一阶段，不是只让它能读更多文件、接更多工具、跑更多步骤，而是让它能理解工作空间里的关系。

它要知道哪些材料有效，哪些材料过期；哪些文件是源头，哪些文件是派生；哪些内容是背景，哪些内容是证据；哪些上下文必须被验证，哪些结论需要回到真实环境里确认。

对研发组织来说，这意味着 AI 研发自动化不能停留在“让 Agent 写代码”。它必须进一步理解整个研发工作空间：代码、文档、任务、沟通、数据和历史。

真正可靠的 Agent，不是看起来很忙的 Agent，而是能在复杂工作空间里找到关键上下文、理解依赖关系，并把工作推进到可交付结果的 Agent。

Zirui Tang et al. Workspace-Bench 1.0: Benchmarking AI Agents on Workspace Tasks with Large-Scale File Dependencies. arXiv:2605.03596, 2026.
https://arxiv.org/abs/2605.03596

Google Research. Unlocking Dependable Responses with Gemini Enterprise Agent Platform’s Agentic RAG.
https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/