Anthropic 2026-07-06 的研究讨论的是 Claude 内部的 J-space也就是一种不会直接出现在输出里的内部工作区这里要先划清边界它是可解释性研究不是 Claude 已经推出的新产品功能也不是多个 Claude 实例共享同一块外部空间。如果你正在把 Claude 放进一个 Agent 流程里最容易犯的错不是 prompt 写得不够好看更多时候是没有把“中间记录区”当成一个会出错的工程对象。Anthropic 这篇 global workspace 研究有意思的地方就在这里它不是简单说 Agent 流程越多越强而是把 Claude 在输出之外留下内部线索的过程拆开看。这对开发者很实用。很多团队现在做 Agent 编排时会让规划、检索、代码、审阅多个步骤互相传递信息。看起来只是多了一个上下文窗口实际上更像多了一张中间记录。白板上写什么、谁能改、旧信息什么时候清掉、错误线索如何标记都会影响最终结果。先把中间记录区当成接口而不是聊天记录CSDN 读者更该关心实现细节。一个智能体测试起码要记录四类字段任务输入、每个步骤写入中间记录区的内容、最终模型读取到的上下文、输出后的人工判定没有这些字段失败时只会得到一句“Claude 没答好”。Anthropic 的研究把 J-space 作为实验对象说明 Claude 内部可能存在不直接出现在输出里的线索。落到企业测试里更应该关注输入噪声会不会被最终回答吸收。落到工程里可以先做小样本重放同一批任务分别跑原始输入、人工标注冲突信息后的输入、删去干扰信息后的输入。开头别就接真实业务库。如果团队用 147AI 做第一轮多模型 API 测试可以记录同一任务在 Claude、GPT、Gemini 下处理干扰材料的敏感度尤其是错误线索是否被放大涉及接口配置时再查对应 API 接口文档核对 Base URL、Key 和兼容边界。测试别只看答对率这种测试最容易被一个指标带偏。答对率当然要看但更应该看失败来源。是检索步骤写错了信息还是规划步骤引用了过期内容是最终 Claude 过度相信中间记录区还是没有利用中间记录区这几个错误在上线后的处理方式完全不同。可以把测试表拆成几列中间记录区是否含噪声、噪声是否被最终回答采用、最终回答有没有引用来源、人工审阅能不能快速定位问题、重跑时是否复现这样才能判断架构该改哪一层。上线前留一个退回路径研究结果再新也不能直接变成生产结论企业系统里global workspace 这种思路适合先用于资料整理、代码审查、内部问答这类可复核场景。涉及合同、财务、医疗、合规判断时中间记录必须有权限、审计和人工核对。真要上线时别只问 Claude 能不能协作。要问中间记录区能不能被清理出错样本能不能回头查模型切换后记录还在不在。把这些问题答清楚智能体才不是一次演示而是一套可以管的流程。实现上还可以加一个最小验收脚本每次运行后导出 JSON包含 task_id、role、intermediate_note、source_url、used_by、final_answer、human_label。字段不用一开始很完美但要保证出错样本能被重新播放没有 replay后续优化只能靠感觉。如果接入 CI可以把十到二十条固定样本作为回归集。每次改中间记录区策略、换模型、改提示词都跑一次。只要错误类型变化就写进变更记录。