我在 AllClaws 项目里跟踪 30 个 AI agent 平台已经六个月了。我读过它们的源代码，比较过它们的架构，编目过它们的失败模式。但”读懂 agent 如何工作”和”看着 agent 工作”是两回事。于是我做了个不寻常的尝试：我组建了一个虚拟研究团队，让三个不同的 AI agent 平台在同样的研究任务上协作，然后跟踪它们产出的一切。

实验概念上很简单。我创建了三个团队成员，每个由一个来自完全不同架构范式的平台驱动：

成员 平台 语言 范式
goclaw-operator GoClaw Go 企业多租户网关
clawteam-lead ClawTeam Python 多代理群体协调
hermes-researcher Hermes-Agent Python 基于 profile 的个人 agent

我给了它们一个共享任务板，包含四个关于它们自己平台的研究问题——工作区隔离、多任务协调、安全和身份模型——然后是第五个需要阅读彼此产出的综合任务。每个成员调查自己平台的内部实现，并以 markdown 文件提交发现。

在一个 sprint 的时间里，团队产出了 13 个 markdown 文件：每人 4 个，加一份跨平台综合报告。以下是我学到的东西。

实验：结构与设置

任务板很直接。每个成员收到关于其平台四个维度的相同研究 prompt：

  1. S1-T1：工作区与项目隔离 — 平台如何组织工作？隔离边界是什么？
  2. S1-T2：多任务与多代理协调 — 如何处理并发任务？代理间通信？
  3. S1-T3：安全与凭据管理 — 如何处理密钥、沙箱、审计？
  4. S1-T4：Profile / 身份模型 — 用户和上下文如何分离？

第五个任务（S1-T5）是综合——比较三种方法，识别权衡，并为每个平台提出可以向其他平台借鉴什么。

每个成员基于相同的源材料工作：AllClaws 架构文档和实际的平台源代码（作为 git submodule 提供在父仓库中）。它们不能直接对话。协调通过引用其他成员工作的 commit message 完成。

整个实验活在一个 git 仓库里，使用结构化命名：virtual-team/<member>/S1-T<task#>-<short-name>.md。没有项目管理工具。没有 Slack 频道。没有站会。只有 git commit 和 markdown 文件。

发生了什么

三个范式，通过它们自己的眼睛

每个成员都产出了扎根于实际代码的详细技术分析——不是营销文案，不是文档摘要，而是从阅读源码中提炼的架构。

goclaw-operator 交出了配得上其平台的企业级分析。它的工作区隔离分析记录了 GoClaw 如何把 TenantID 传播到每一层——网关路由、agent 分发、数据库查询（store.WithTenantID）和审计日志。它的安全分析是所有成员中最详尽的，详述了五层防御：AES-256-GCM 加密、RBAC（admin/operator/viewer）、exec 审批白名单、通过 Go channel 的缓冲审计日志（容量 256），以及限流。这份分析读起来像一份安全审计——精确、落到具体实现、不留情面。

clawteam-lead 产出了聚焦协调原语的分析。它的工作区隔离文档解释了基于 git worktree 的架构——每个 worker agent 从父仓库获得自己的 worktree，消除了合并冲突。它的多任务协调分析是所有成员中最丰富的，记录了基于 TOML 的 blocked-by 依赖链与自动解除阻塞、双模式代理间通信（点对点 inbox 加广播），以及一个具体的性能声明：5 个并行 agent 在约 3 小时内完成一个全栈应用，对比串行的 8 小时以上——同等 token 成本下 2.7 倍加速。

hermes-researcher 交出了最内省的分析，基于一个实际运行的安装。它确认了两个活跃 profile（personal，1.9MB state.db；work，368KB WAL），记录了凭据池轮换（标记 401，轮换到下一个 key），并提供了 profile 隔离在实践中如何工作的最清晰解释。它的分析对局限性最坦诚：”agent 进程内部没有任何东西构成容器隔离”——直接引用自平台的 SECURITY.md。

综合：三个范式碰撞的地方

跨平台综合报告（S1-T5）是这次实验的收获。它在每个维度上比较了三个平台，产出了整个实验中最有用的输出：一个结构化的权衡矩阵。

以下浮现出来的发现：

在工作区隔离上，根本性的分叉显形了。 GoClaw 按身份隔离（你是谁——每个数据库查询里的 TenantID）。ClawTeam 按任务隔离（你在做什么——每个 agent 一个 git worktree）。Hermes 按上下文隔离（你在扮演什么角色——每个用例一个 profile 目录）。三者没有一个能同时做到另外两个。GoClaw 无法为同一用户分离上下文。ClawTeam 无法分离用户。Hermes 无法分离任务。

在协调上，成熟度光谱悬殊得刺眼。 ClawTeam 拥有最精密的系统：显式依赖链、代理间 inbox、广播消息、kanban 监控。GoClaw 有数据库支撑的团队协调但没有直接消息传递。Hermes 只有 fire-and-forget 委派，完全没有代理间通信。ClawTeam 的”agent 交换中间结果”与 Hermes 的”agent 返回最终摘要”之间的差距不是渐进的——是架构性的。

在安全上，企业与个人的分野显而易见但并不简单。 GoClaw 决定性领先：加密凭据、RBAC、结构化审计日志、按租户隔离。但综合报告凸显了一个有趣的中间立场。Hermes 的自动凭据池轮换——耗尽一个 401 的 key 然后轮换到下一个——在运维成熟度上超过 GoClaw 的手动凭据管理。最好的安全模型应该结合 GoClaw 的治理与 Hermes 的运维自动化。

在身份上，每个平台回答的是不同的问题。 GoClaw：”你是谁？”（TenantID）。ClawTeam：”你在哪个团队？”（TOML 模板）。Hermes：”你现在戴的是哪顶帽子？”（profile 目录）。洞察在于：这些不是竞争的答案——它们在回答真实用户同时拥有的不同问题。

元教训：Agent 能做比较研究

在讨论平台含义之前，有一个元层面的发现：实验成功了。

三个 AI agent，各自访问相同的源材料，但运行在不同平台、使用不同 prompt 策略，产出了 13 个文件的有据可依的技术分析。综合文档跨成员交叉引用发现，识别出非显而易见的权衡，并为每个平台提出了可操作的改进——全程没有人类写下一个段落。

这很重要，因为比较性平台分析恰好是那种：

  • 劳动密集：阅读三个代码库的源代码是人类数小时的工作
  • 结构化：输出格式定义明确（markdown、表格、对比）
  • 有据可依：你可以对照实际代码验证声明
  • 无聊：没人想花一个周末比较 RBAC 实现

AI agent 擅长以上全部四点。关键在于提供结构化的任务定义、共享的证据基础和清晰的输出格式。agent 完成了剩下的一切。

但是——这一点至关重要——综合质量完全取决于个体分析的质量。当 clawteam-lead 对 TOML 依赖链足够具体时，综合才能精确比较它们。当 goclaw-operator 详述审计管道（EventEmitter -> Buffered Channel -> PostgreSQL）时，综合才能准确对比。模糊的分析只会产出模糊的综合。实验的结构与 agent 本身同样重要。

对 Agent 平台设计的启示

1. 分叉是真实的，而且正在固化

AllClaws 研究已经识别出一个决定性趋势：个人力量倍增器与企业自动化范式之间的分叉。这次实验以新的方式让分叉显形——不是通过阅读文档，而是通过观察来自每个范式的 agent 如何推理同样的问题。

GoClaw 的 goclaw-operator 用租户、策略和合规思考。ClawTeam 的 clawteam-lead 用 agent、任务和合并冲突思考。Hermes 的 hermes-researcher 用 profile、记忆和上下文切换思考。这些不是同一抽象的不同实现——它们是完全不同的抽象。

启示：我们不会收敛到单一的 agent 平台架构。我们正在分化为至少三种不同的架构，各自为不同的部署现实优化。GoClaw 的 PostgreSQL 承诺让它不可能零配置。ClawTeam 的 git worktree 模型让它不可能多租户。Hermes 的文件系统 profile 模型让它不可能做实时代理间协调。

2. 没有人做到三种分离

综合报告识别出一个没有任何被跟踪平台填补的缺口：同时做到用户分离、任务分离和上下文分离。

在真实世界里，开发者三者都需要。我需要工作 API key 与个人 API key 隔离（用户分离）。我需要并行 agent 在不同 feature 上工作而不冲突（任务分离）。我需要我的”代码审查”上下文拥有与”研究”上下文不同的工具和权限（上下文分离）。

GoClaw 分离用户。ClawTeam 分离任务。Hermes 分离上下文。同时做到三者——且不分别要求 PostgreSQL、git 专业知识和文件系统管理——的平台，将拥有真正的架构优势。

3. 协调是服务不足的中间地带

实验揭示了一个出人意料的非对称。GoClaw 有企业治理但没有群体协调。ClawTeam 有群体协调但没有企业治理。Hermes 两者皆无但擅长个体生产力。

服务不足的空间是面向小团队的结构化协调——不是 500 用户的企业部署（GoClaw 的地盘），不是并行 agent 的独立开发者（ClawTeam 的地盘），而是 3-10 人的团队，他们的 agent 需要跨组织边界协作并带一些治理。

想象一下：ClawTeam 的依赖链和 inbox 系统，加上 GoClaw 的凭据隔离和审计日志，运行在 Hermes 的 profile 模型里，每个成员获得一致的上下文。这个产品不存在。最接近的近似需要用胶带把三个平台粘在一起。

4. 安全实践应该与架构解耦

GoClaw 的安全最完整，因为它烤进了 PostgreSQL——租户范围的加密、租户范围的审计日志、RPC 层的 RBAC 强制执行。但这意味着你需要 PostgreSQL 才能有安全。

综合报告表明，一些安全实践与架构无关：

  • 凭据池轮换（Hermes）适配任何存储后端
  • 通过指纹的密钥脱敏（Hermes）不需要加密
  • exec 审批白名单（GoClaw）不需要数据库
  • 结构化审计日志（GoClaw）可以用 SQLite 替代 PostgreSQL

启示：安全成熟度不应该要求特定的架构承诺。像 ClawTeam 那样把凭据以明文 TOML 存储的平台，可以采纳 Hermes 的池轮换和 GoClaw 的审计模式，而不改变核心架构。它们没有这样做的事实表明，安全在个人 agent 平台中被当作事后想起——随着这些 agent 处理越来越敏感的操作，这个习惯将变得不可持续。

5. Profile 即工作区，是个人 agent 的正确默认

Hermes 的 profile 模型——一个自包含目录，带配置、凭据、技能、记忆和会话状态——是我见过的个人用途下最干净的隔离原语。ClawTeam 的 worktree 模型对并行代码工作很出色，但不分离上下文。GoClaw 的租户模型对单用户是杀鸡用牛刀。

profile 方法有一个其他方法不具备的属性：零配置上下文切换。我可以有一个用便宜模型和只读工具的”research” profile，和一个用强大模型和完整终端访问的”coding” profile。切换它们就是换一个目录，不是开通基础设施。

这暗示了一个收敛点：个人平台应该采用基于 profile 的隔离作为默认，可选 worktree 隔离用于并行编程任务，可选租户隔离用于团队部署。Hermes 提供了地基；其他平台提供可选层。

每个平台应该偷什么

综合报告产出了一份具体、可操作的清单：

GoClaw 应该从 ClawTeam 偷：

  • 带自动解除阻塞的任务依赖链（比隐式团队协调更有表达力）
  • 带 circuit breaker 状态的 agent 级成本仪表盘

GoClaw 应该从 Hermes 偷：

  • 自动凭据池轮换（替代手动 key 管理）

ClawTeam 应该从 GoClaw 偷：

  • AES-256-GCM 凭据加密（明文 TOML 问题是任何共享系统的 showstopper）
  • 结构化审计日志（JSON 状态文件不是审计轨迹）

ClawTeam 应该从 Hermes 偷：

  • Profile / 上下文分离（让 agent 在不同任务下以不同配置运行）

Hermes 应该从 ClawTeam 偷：

  • 代理间通信（inbox 和广播，而不只是 fire-and-forget 委派）
  • 任务依赖跟踪（blocked-by 链，而不是扁平 todo 列表）
  • 多代理监控（所有运行中任务的 kanban 看板视图）

Hermes 应该从 GoClaw 偷：

  • 带权限范围的 RBAC（research 只读，development 完全访问）
  • 面向企业 profile 的结构化审计日志

真正的收获

我出发去通过让三个 AI agent 平台解决同一个问题来了解它们。我学到了预期中的东西——平台有不同的强项、不同的弱点、不同的架构承诺。对比矩阵确认了我已经手动做过的分析。

但我也学到了意料之外的东西：每个 agent 思考问题的方式，比任何功能对比都更能揭示平台的本质。

GoClaw 的 agent 写安全的方式，就像安全工程师写安全——分层防御、威胁模型、合规要求。ClawTeam 的 agent 写协调的方式，就像系统架构师写分布式系统——消息传递、隔离边界、故障恢复。Hermes 的 agent 写身份的方式，就像产品设计师写用户体验——用户上下文、心智模型、切换成本。

这些不是巧合。每个平台塑造了它的 agent 推理问题的方式。GoClaw 的数据库中心架构自然产出数据库中心的分析。ClawTeam 的 git 中心架构自然产出 git 中心的分析。Hermes 的 profile 中心架构自然产出 profile 中心的分析。

平台提供的不只是不同的工具——它们提供不同的透镜。这次实验最有价值的东西，不是学到每个平台做什么，而是学到每个平台看到什么。

全部 13 个分析文件可在 AllClaws 仓库的 virtual-team 目录获取。跨平台综合报告在 virtual-team/S1-T5-cross-platform-synthesis.md，包含完整的对比矩阵和权衡分析。

English version