拆解 Agent Workspace 三条技术路线：WorkBuddy、Claude Tag 与 EragonAI（上）

• WorkBuddy、Claude Tag、EragonAI 是当前 Agent Workspace 领域三条比较有代表性的技术路线，本文对它们做一次技术拆解和比较。

• 三款产品分别代表 Workspace 的三种基础形态。WorkBuddy 将多人、多 Agent、项目上下文和任务接力放进同一工作空间，是原生协作型 Workspace，工程完成度最高；Claude Tag 以频道内共享 Agent 为核心，通过独立身份、权限继承和记忆隔离构建了目前最成熟的 Agent 治理体系；EragonAI 以常驻运行、多渠道接入、记忆、Skill 和自然语言运维为特征，更接近一个共享 Agent 运行平台。三者共同验证了任务执行、Agent 调度、上下文管理、连接器和 Skill 等基础能力已经趋于成熟，Agent Workspace 的底层技术不再构成研究级门槛。

• 三款产品在业务承载层留有相近的空白：都还没有作为正式节点接入企业审批流程，操作 CRM/ERP 等遗留系统的公开案例有限，用户/Agent/凭证/记忆/审计层面的统一治理也都还在完善。

• 从技术路线看，三者的能力大致落在三个层次：基础设施层（多 Agent 框架、Memory、Runtime、模型路由、MCP）已经有较多开源和商业方案可以参考；治理层（身份权限、记忆边界、审计）目前 Claude Tag 的架构提供了较多可借鉴的设计思路；业务承载层（流程对接、遗留系统集成、行业化）是三款产品公开证据都比较薄弱的部分。

• WorkBuddy 把 Agent 协作放进自有工作台，Claude Tag 把受治理的共享 Agent 放进既有协作频道，EragonAI 则进一步暴露了共享 Agent 背后的运行环境和运维控制面。三者分别侧重协作层、治理层和运行层，但都还没有提供完整的业务流程承载层。这三个方向不是相互替代关系，更像是 Agent Workspace 从协作、治理到运行基础设施逐步完善的不同切面。

三种路线的侧重点不同：WorkBuddy 把 Agent 协作放进自有工作台，Claude Tag 把受治理的共享 Agent 放进既有协作频道，EragonAI 则进一步暴露了共享 Agent 背后的运行环境和运维控制面。三者分别覆盖协作层、治理层和运行层，但都没有提供完整的业务流程承载层。从行业演进视角看，这三个方向并不是相互替代关系，而更像 Agent Workspace 从协作、治理到运行基础设施逐步完善的不同切面。未来企业级 Workspace 很可能同时具备这三层能力，并进一步向业务流程层延伸——这也是目前最明显的产业空白。

表1 WorkBuddy、Claude Tag 和 EragonAI 产品定位对比

2.1 主要技术门槛评估

WorkBuddy 架构选型（16 类 Agent 分工、四通道通信、双阈值上下文压缩、沙盒隔离+Skill 标准化）在业界都有公开可参考的对标方案，单点技术均可复现。真正的门槛集中在多 Agent 长时间协作下的工程稳定性，包括 Worker Agent 后台常驻的状态一致性、生命周期看门狗绑定、消息投递语义、100ms 沙箱冷启动背后的资源池化和快照复用，以及大规模异构生态的持续治理——7 万+ Skills 的版本管理、依赖冲突、权限继承和安全审核，100+ MCP 连接器在国内外市场的差异化配置。

腾讯采用的解法整体偏"轻量级约束+持续迭代打补丁"，例如 Teammate 纯文本输出对其他 Agent 不可见这条硬性约束，就是用工程规则规避上下文膨胀而不是重构架构；两个月 43 个版本的迭代节奏也印证了这一路径。这套解法与其自有工作台+国内 IM 生态的产品定位匹配，但也意味着这类问题很难通过一次性架构设计彻底解决，需要长期投入运维打磨和真实任务反馈才能收敛。

腾讯官方给出的硬指标是：100ms 沙箱冷启动、7 万+ Skills、100+ MCP。

2.2 SubAgent 交互机制：两模式 + 四通道 + 三上下文

WorkBuddy 定义了 16 种 Agent、4 条通信通道、3 种上下文模式（基于 v5.1.7 product.json 逆向分析）。

两种通信范式动态切换

• 模式 A 是一次性子代理调用，函数调用语义，上下文完全隔离，单次返回后终止，结果以 XML 注入主 Agent，用于简单委派任务。

• 模式 B 是持久团队协作，组织协作语义，后台 detached 常驻，通过 SendMessage 双向通信 + TaskList 共享状态 + shutdown 协议优雅终止，用于复杂多步骤协同。Worker Agent 保留了自己的上下文（工作记忆、已完成任务、代码理解），下次接到新任务时不需要从零开始，对复杂项目非常关键。

One-shot 模式（模式 A）：

Team 模式（模式 B）：

四条通信通道

• SendMessage
  
  ：点对点或广播消息，必须指定收信人和 5–10 词的 summary

• TaskList
  
  ：共享任务看板，通过 owner和 blockedBy字段实现分布式任务分配，状态机为 pending → in_progress → completed

• Agent Notification
  
  ：把子 Agent 结果伪装成 user-role 消息注入主 Agent 上下文

• FileSystem
  
  ：隐式共享存储，跨会话传递记忆文件

一个关键工程约束：Teammate 的纯文本输出对其他 Agent 不可见，必须走 SendMessage。这是应对上下文膨胀、注意力稀释、耦合失控三个问题的直接对策，相当于给每次跨 Agent 信息传递加了一道门槛。

2.3 上下文压缩：预防 + 抢救双 Agent 机制

上下文窗口的分配、隔离与压缩，是所有多 Agent 系统必须回答的核心问题。WorkBuddy 没有走"堆更大 context 模型"的路线，而是通过多级阈值触发主动压缩，由两个专职 Agent 分工：

compact Agent：预防性压缩，40% Token 时触发，产出 结构化摘要，明确写入指令"所有任务已完成，不要重新执行"防止 Agent 重复动作

contextSummary Agent：抢救性压缩，90% Token 时触发，输出 9 段式结构

这套设计和 CodeBuddy 的两级"压缩 → 摘要"策略同源，本质是一种"有损但保结构"的 JPEG 式压缩，代价是丢失了"为什么这样做"的推理过程。

压缩后的上下文包含

• Primary Request and Intent —— 用户原始意图（压缩后仍保留）

• Key Technical Concepts —— 涉及的技术概念

• Files and Code Sections —— 关键文件和代码片段

• Errors and fixes —— 遇到的错误和修复方式

• Problem Solving —— 已解决和待解决的问题

• All user messages —— 所有用户消息（仅 contextSummary 模式）

• Pending Tasks —— 未完成的任务

• Current Work —— 当前正在进行的工作

• Optional Next Step —— 可选的下一步

2.4 安全执行与生态集成

WorkBuddy 企业版三大核心能力：7×24 专家数字员工、人与 AI 协作的"团队"模式、企业级管理后台。办公智能体套件把腾讯文档、腾讯网盘、腾讯乐享三大产品能力原生打通到工作台，覆盖"内容创作—知识沉淀—能力复用"全链路。安全机制上采用沙盒隔离+Skill 标准化+危险操作拦截三层防御，高危指令（删除系统文件、修改注册表）会被直接拦截并提示，所有操作默认本地执行不上传云端。工具连接层面国内版对接企微/飞书/钉钉/QQ，海外版新增 GitHub/GitLab/Jira/Confluence/Google Drive/Gmail/Notion/Slack 的 MCP 连接器矩阵。WorkBuddy 的连接器能力是市场分层配置的，同一套 Agent 内核，上层根据市场换连接器配置。生态扩展有 Skill 市场（SkillHub）和"专家中心"（官方宣传 100+ 专家）。

2.5 技术实现难点

分布式任务认领的状态一致性问题。TaskList 用 owner+blockedBy 字段实现黑板式协调，多个 Worker 并发认领任务时存在竞态风险，更新日志里明确记录过"团队队列一次性推送所有任务的问题"这类真实缺陷，说明这不是设计层面能一次性解决的问题，需要经过多轮线上迭代打磨。解决路径是持续通过状态机约束（pending→in_progress→completed 三态严格流转）加乐观锁式的字段更新收窄竞态窗口，而不是引入更重的分布式锁机制，这是在一致性和性能之间做的权衡取舍。

压缩机制的信息保真度问题。40% 预防性压缩+90% 抢救性压缩的两级设计本身能解决上下文膨胀，但压缩过程中出现过"消息错误透传及动画挂起""/clear 后再压缩仍带入旧会话内容"这类具体 bug。"压缩什么、怎么压缩、压缩后如何保证不重复执行"这件事在工程实现上比设计层面复杂得多。解决路径是显式在压缩摘要里写入"所有任务已完成，不要重新执行"这类指令性文本，用提示词层面的约束弥补压缩本身丢失的执行状态信息，这是一种工程补丁式的解法，不是根本性解决方案。

多模型路由的状态管理问题。混元/DeepSeek/GLM/Kimi 等模型可以按任务类型切换，但更新日志记录过"模型切换后切换会话再切回模型记忆丢失"的问题。多模型路由不只是简单的 API 调用切换，还涉及跨模型的会话状态如何保持一致。解决路径目前看是持续的 bug 修复迭代，没有看到公开的系统性架构解法，这也说明"多模型异构适配"仍是一个需要持续投入的真实难点。

本地执行与安全拦截的用户体验权衡。本地优先架构+高危指令拦截能提升安全性，但更新日志显示"授权超时后会话卡住无法停止"这类问题曾经发生，说明安全策略越严格，越容易在边界条件下影响任务执行的连续性。解决路径是持续优化沙箱安全策略的超时和恢复逻辑，这类问题的解决更依赖大规模真实使用中暴露边界场景后针对性修复，很难在设计阶段一次性穷尽。

小结：WorkBuddy 面临的技术难点集中在多 Agent 协作的工程稳定性（状态一致性、生命周期绑定）和多模型异构支持的复杂度上，采用的解法总体偏"轻量级约束+持续迭代打补丁"，不是重型分布式系统的解法思路，这和它快速迭代（两个月 43 个版本）的产品节奏是匹配的，但也说明这类问题很难通过一次性架构设计彻底解决，需要长期投入运维打磨。

3.1 主要技术门槛评估

Claude Tag 的门槛更多在产品层面的架构选择——身份、记忆、行为边界这三条主线一旦在初始架构确定，后期较难通过补丁修正。具体来看：多身份并发下的权限一致性校验需要在高并发场景下保持低延迟，属于典型的高性能工程问题；记忆系统的强隔离与跨频道学习的取舍要求区分"可学习"与"可检索"两种粒度的权限，这是记忆架构的顶层设计问题；Ambient 主动介入行为的边界判断则依赖模型能力、上下文理解和噪音控制的综合平衡，Anthropic 自己都建议先关闭该模式再逐步启用，说明这条能力目前仍处于行业级早期阶段。

Anthropic 的解法路径是"先放宽 baseline + 审计驱动收紧"，通过结构化审计日志支撑管理员的增量授权决策，而不是一开始就穷举所有边界。规划中的"频道权限 ∩ 用户权限"实时求交、即时凭证授予等能力，进一步说明治理层的复杂度还在持续上升。

身份和权限治理的三层继承模型是 Claude Tag 比较有参考价值的部分；记忆边界和 Ambient 边界更多是产品哲学选择，需要结合具体场景重新定义，不完全是技术复用的问题。

根据 Anthropic 官方发布博客，Claude Tag 被明确定位为 Claude Code 演进的下一步：让模型更主动，也能与整个团队更好协作。官方对 Claude Tag 的四个核心特性做了明确表述：

• @Claude is multiplayer
  
  ：在一个 Slack 频道内，只有一个 Claude 与所有人交互，任何人都能看到它在做什么，也可以从上一个人停下的地方接着推进

• @Claude learns over time
  
  ：Claude 跟随频道积累工作上下文，用户不需要每次从头解释

• @Claude takes initiative
  
  ：ambient 模式启用后，Claude 会主动更新它认为用户需要知道的信息、跟进搁置的话题或任务

• @Claude works asynchronously
  
  ：任务可以跨越会话持续推进

Anthropic 也披露了内部使用数据：其产品团队 65% 的代码由内部版 Claude Tag 产生，同样的 tagging 模式已扩展到追踪产品指标、处理 support ticket、排查复杂 bug。

产品页给出了更完整的企业客户实证。CTO Aabhas Sharma 描述，Claude Tag 是其团队内部 bug 的第一响应者，能读取报告、看失败截图，用 Datadog、Linear、GitHub 的访问权限排除用户错误、追溯根因，通常还能起草修复 PR，工程师的第一反应是很惊讶。另一位 AI Engineering Director Simon Mansfield 则强调，Claude Tag 不只是干活，还会挑战团队的思考、提出更好的问题，团队全程感到很受控。

3.2 Agent Identity：独立身份 + 分层继承

传统"代替用户行事"模型（Agent 借用发起任务用户的个人凭证）在多人协作场景下失效，原因有二。第一，Agent 自主性持续增长（Anthropic 引用的判断是 Agent 可靠完成任务的时长大约每四个月翻一倍），用户下线后 Agent 仍在持续行动，权限主体失去明确归属。第二，多人协作场景下权限主体本身不唯一，多名工程师联合调试时选择任一用户的权限作为执行依据都不合理。

解法是让 Claude 在每个系统里拥有自己的账号，而非借用任何个人凭证：以 Claude App 身份发 Slack 消息，以 Claude GitHub App 身份提交 PR，以 service account 身份查数据仓库。权限分配是分层继承：管理员在 workspace 层定义 baseline 身份，频道默认继承，可按需覆写（例如工程频道加 GitHub 和数据仓库权限，CRM 权限限制在销售私有频道）。管理员可配置的范围覆盖仓库访问、连接器、技能插件、频道级 standing instructions 四类要素。

3.3 身份边界与隔离

每个私有频道拥有独立身份，公开频道共享 workspace 级别的统一身份。这带来的边界效果是：法务频道中的 Claude 身份无法访问未经授权的工程代码，工程频道中的身份也无法读取未被授予权限的法务文档。记忆同样遵循边界规则，Claude 在私有频道中学到的信息不会流向更广泛的 workspace。

频道身份默认对频道内所有成员开放，即频道成员均可 @Claude 触发任务。在 Enterprise 方案上，管理员可以叠加基于角色的访问控制（RBAC），进一步限定哪些成员有权调用 Claude，形成"频道决定 Agent 能触达什么，RBAC 决定谁能发起请求"的双重约束结构。

需要指出的是私信（DM）场景走的是另一套逻辑：DM 运行在用户个人的 claude.ai 账号之上，使用的是用户本人的连接器、凭证和身份标识。这一区分背后的推理是，个人化任务（如起草邮件、使用仅本人持有许可证的软件）不应该继承频道级的公共身份，DM 恰好提供了这类任务应有的私有权限边界。

3.4 安全审计实现

当管理员为某个频道的 profile 添加一条连接配置时，对应凭证被独立存储并映射到该频道的身份，在请求发生时于网络边界处注入，管理员未列入白名单的目标主机会被直接拦截出站流量。审计层面，每一次 routine 执行、memory 写入、网络调用都会被记录在案，并且由于 Claude 是以自己的 service account 行动，这些操作同时会出现在被连接系统自身的日志中，形成双重留痕。

3.5 技术实现难点

多身份并发下的权限一致性校验。一个组织内可能同时存在数十甚至上百个频道身份，每个身份的工具集、凭证范围、技能加载都可能不同。系统需要在每次工具调用发生时实时校验当前身份是否被授权执行该操作，且不能因身份数量增长而引入明显的调用延迟，这对权限校验层的架构设计提出了较高要求。

记忆系统的强隔离与跨频道学习的取舍。Claude 在私有频道学到的信息不能泄露到 workspace 其他位置，但产品同时允许 Claude 在被授权的前提下从其他 Slack 频道和数据源自动学习。这意味着记忆系统必须支持细粒度的来源标记和访问范围控制，而不是简单的全局记忆库，工程实现上需要区分"可学习"与"可检索"两种不同粒度的权限。

Ambient（主动介入）行为的边界控制。当 ambient 模式开启后，Claude 会主动追踪信息、提醒团队、跟进停滞的讨论，这类行为没有显式的用户触发指令，如何判断"该不该主动介入"本身就是一个需要模型具备较强上下文判断能力的问题。行业报道显示，Anthropic 官方建议团队在充分理解失败模式之前先保持 ambient 模式关闭，这从侧面说明该能力的边界控制目前仍处于早期阶段，尚未形成成熟的默认策略。

凭证的最小权限起始与动态扩展。Anthropic 在博客中给出的建议路径是先给一个较为宽松的 baseline 权限，观察审计日志，再逐步收紧或扩展，而不是一开始就穷举所有边界情况。这一路径背后隐含的技术要求是审计日志必须足够结构化和可读，能够支撑管理员做出增量授权判断，否则"先宽松后收紧"的策略会退化为无法追溯的权限黑箱。

未来方向指向的门槛更高。Anthropic 披露的下一步规划包括即时凭证授予（用户可对单次敏感操作临时批准，而不永久扩大 Agent 权限范围）和身份感知的叠加校验层（同时校验频道 profile 权限与发起用户个人权限）。这两项能力要求系统在运行时支持"频道权限∩用户权限"的实时求交运算，比当前版本更复杂一层。

4.1 主要技术门槛评估

EragonAI 的核心工程价值来自 Agent 基础设施的一体化整合。它把常驻 Gateway、Linux Workspace、多渠道接入、分层记忆、Skill、Cron/Heartbeat 定时任务、模型路由和自然语言运维等能力放在同一底座中。经过分析，EragonAI 的多数基础机制已有开源项目或开放标准可以参考：

• OpenClaw 已经覆盖常驻 Gateway、渠道插件、会话管理、文件化记忆、Skill、Cron、Heartbeat 和浏览器控制；

• CocoIndex 提供面向长期运行 Agent 的增量索引与持续数据更新；

• LangGraph 和 Temporal 分别提供有状态 Agent 编排、状态持久化、人工中断，以及长任务的失败恢复与持续执行；

• Agent Client Protocol（ACP）提供宿主程序与外部编码 Agent 之间基于 JSON-RPC 的通信接口。

门槛主要来自多组件联动后的状态一致性、身份隔离和运行治理。

但试用中也暴露了明显的成熟度短板：单账号多外部用户场景下发生跨用户 DM 内容泄露，说明身份映射和记忆隔离仍处于早期；Slack 新用户配对需要重启 Gateway，反映运行时状态同步机制不完善；渠道内设置的定时任务未在控制台显示，说明控制面与运行时状态一致性尚未打通；模型直接参与配置修改和故障处理带来了效率，但也让"任务执行、配置修改、系统管理"共用同一入口，对权限分级、变更审批和版本回滚提出了远超传统 SaaS 的要求。

EragonAI 采用的解法路径是"开放运行环境+自然语言运维覆盖控制面"，用模型能力弥补产品化不足。这条路径短期能快速覆盖多种场景，长期则依赖治理层的持续加固，否则会在企业级部署中反复暴露一致性和隔离问题。

4.2 产品定位与运行架构

EragonAI 的技术路线以共享 Agent 的常驻运行和管理为中心。官方将其描述为"Agent Native Work 的操作系统"，在模型外建设 Gateway、索引、记忆、多 Agent 编排、凭证管理、文件系统、多渠道接入、Skill、模型路由、浏览器自动化和定时任务等 14 层能力。

Gateway 负责认证、会话、路由和任务调度，使 Slack、飞书等入口连接到同一个长期运行的 Agent 实例。与主要提供对话界面的产品相比，EragonAI 将 Agent 背后的运行环境直接开放给用户：Web 界面之外，实例还提供 Ubuntu Remote Desktop，用户可以执行命令、修改配置，也可以通过对话让模型完成配置查找、修改和故障处理。

这种设计降低了 Agent 系统的部署和维护门槛，也使任务执行、Agent 配置与系统管理共用同一套模型入口。模型在运行环境中的权限范围、配置修改的生效范围，以及失败后的恢复方式，需要由独立的治理机制约束。

4.3 记忆、Skill 与多渠道使用

EragonAI 将记忆分为完整会话与工具轨迹、持续追加的事件记录、由反思 Agent 提炼的长期记忆三层，并提出压缩前写出、向量与全文混合检索、RLM 访问超长记忆等机制。实际试用中，可以在 Slack 群聊里要求 Agent 将既有工作沉淀为 Skill，随后可在 EragonAI 界面中查看。Skill Graph 的加载、版本和权限机制尚未验证。

持续任务采用 Cron 和 Heartbeat 两类机制。试用中可以在 Slack 内设置定时任务，但控制台未显示对应记录，任务是否持久化及其实际状态无法核验。多渠道方面，本次只使用一个 EragonAI 账号，Slack 和飞书均连接到同一实例。群聊中多人可以通过 @ 共享 Agent，整体体验仍以机器人问答为主，尚未观察到持续跟随讨论、主动协调成员或维护共同任务状态的能力。

4.4 权限风险与技术能力验证

本次试用采用单后台账号、多个外部用户共享同一实例的配置。Slack 新用户私聊需要先通过 Pairing Code 完成配对，配对后还需要重启 Gateway。这个过程表明外部用户身份与运行时会话之间已经存在映射机制，但身份变更尚未实现实时同步。一名用户在飞书私聊中询问其他用户与机器人的私信内容时，Agent 返回了相关信息；明确禁止后，模型才改变回答行为。

官方材料还提出凭证代理、Single Writer 多 Agent 编排、外部编码 Agent 调度和两级模型路由。模型方面，产品内回答称使用 Claude Sonnet 4.6、Haiku 4.5 和 Opus 4.7，并根据任务复杂度进行分配。实际试用能够感受到较好的任务完成质量，但多 Agent 分工、凭证隔离、具体路由决策及成本下降幅度均未得到独立验证。这些能力目前应区分为已试用功能、厂商技术说明和长期研发方向。

4.5 技术成熟度与 Workspace 边界

EragonAI 已经形成了较完整的共享 Agent 运行底座，常驻 Gateway、Linux Workspace、多渠道入口、记忆、Skill、定时任务、模型路由和自然语言运维都具备一定产品形态。其工程价值主要来自多项 Agent 基础设施的一体化整合，以及模型直接参与配置和故障处理带来的维护效率。

从 Workspace 角度看，EragonAI 当前提供的是 Agent 的运行与管理空间。普通成员主要通过群聊机器人和 DM 发起零散任务，产品中缺少统一的业务事项、流程阶段、责任人、材料、审批节点和完成标准。它具备承载流程的部分技术基础，尚未证明这些能力能够直接形成多人协作或重塑企业流程。

本次试用的亮点感知有限，也与场景选择有关。缺少多人长期参与、跨系统获取信息、持续跟踪状态并沉淀 Skill 的真实任务时，用户看到的主要仍是一个能力较强的共享机器人。Agentic Workspace 的价值需要在具体业务流程中进一步验证。

4.6 技术实现难点与解决路径

EragonAI 已经形成了较完整的共享 Agent 运行底座。当前需要继续补齐的能力主要集中在四个方面。

• 运行时状态一致性。
  
  渠道连接、用户会话、定时任务和长时间运行的 Agent 需要使用统一的任务状态。服务重启、模型调用失败或工具执行中断后，系统还要支持恢复、去重和失败追踪。

• 身份与记忆访问控制。
  
  系统需要统一映射不同渠道中的用户和组织身份，并在记忆写入、检索和工具调用时执行强制过滤。个人、频道、项目和组织记忆应具备明确的访问边界。

• 自然语言运维治理。
  
  模型修改配置、安装依赖或处理故障时，需要提供变更范围限制、差异预览、人工审批、自动测试、版本管理和回滚。高权限操作不能与普通任务使用相同的授权方式。

• 统一可观测性。
  
  系统需要记录任务来源、发起身份、模型选择、工具调用、配置变化、运行状态和失败原因，并保证控制台与外部渠道展示同一份任务状态。

小结：EragonAI 底层运行环境和通用 Agent 能力已经比较完整，是自建团队短期内难以复现的一体化基础设施；但身份权限、记忆边界、配置变更和审计体系的成熟度还不够。它当前更接近 Agent 的运行与管理空间，距离承载正式业务流程，还需要补充业务事项、流程阶段、责任人、审批节点和完成标准等上层能力。