选题由来：一周之内，"agent 团队"的栈被凑齐了
前两天我实测了 day-trader-skill：单体 agent 用 SKILL.md 契约 + fail-closed 编排把一件事做扎实。文章发出去的同一天，我在 GitHub 趋势数据里看到一个更值得警惕的信号：三个解决"一群 agent 怎么管"的项目，在同一周内集中冒头。
- reason-network（1192★，10-16 建仓）：coding agent 之间的 P2P 通信引擎
- harp（602★，10-20 建仓）：一个侧边栏同时盯多个 Claude Code / Codex agent
- Omnara（3235★，HN 在榜）：开源自托管的 managed agent 平台，对标 Claude Managed Agents
做过后端的人看到这个组合应该会心一笑。当年单体拆微服务，最先成熟的不是业务框架，而是三样基础设施：服务发现、RPC、容器编排——Netflix Eureka、Dubbo、Kubernetes。业务代码谁都会写，但"服务之间怎么找到对方、怎么说话、在哪里跑、挂了怎么办"才是决定能不能上生产的东西。
agent 正在走同一条路。这三件套恰好各占一个坑位：
| 微服务时代 | agent 时代 | 解决什么 |
|---|---|---|
| 监控面板/服务拓扑 | harp | 人怎么看住一群 agent |
| RPC + 服务发现 | reason-network | agent 之间怎么互相说话 |
| K8s/容器编排 | Omnara | agent 在哪里跑、持久化、被托管 |
所以我花了大半天，把三个项目全部拉到本机实测。跑完发现星数排序和可用性排序完全不一致：Omnara 我敢今天就放进团队流程，reason-network 只能当协议样本看，harp 对 Windows 用户来说等于只有源码。证据按这个顺序摆。
实测环境：Windows 11 + Docker Desktop 29.8.2 + Node 24.19.0，全程国内网络（GitHub API/npm/PyPI/ghcr.io 直连，Docker Hub 走国内 mirror，不需要代理）。
一、Omnara：唯一一个让我愿意称为"生产就绪"的
三件套里 Omnara 星数最高（3235★），我本来担心是 HN 热度泡沫，实测下来恰恰相反——它是三个里工程密度最高的，高到让我这个做了十几年支付平台的人有点意外。
1.1 部署：10个容器一次起齐
官方compose栈包含9个镜像：5个应用镜像（api 113MB / worker 121MB / maintenance 64MB / migrations 32MB / web 79MB）+ Valkey（Redis 兼容）+ Postgres 18 + RustFS（S3 兼容对象存储）+ nginx。一个容器扛完所有的玩具 demo 我见得太多了，这个栈的排布是正经的控制平面架构。
dockercompose-fcompose.yaml--profileapp up-d一个坑先说出来：仓库里有个compose.override.yaml，在源码检出时会自动加载并把 5个应用服务改成本地构建。我在起栈前先翻了目录，看到它就改用了-f compose.yaml；要是没翻，接下来就是几十分钟的 Rust 编译，而且大概率在中途报错。这个设计对贡献者友好，对只想跑起来的人是暗坑。
起栈后 migrate 一次性任务退出码 0，api 日志里第一行就让我停下来看了两眼：
{"message":"loaded mcp registry snapshot","servers":31450}内置了 31,450 个 MCP server 的注册表快照（2026-10-24 生成），直接打包在镜像里。这个数字的用处很具体：agent 编排时可以当场检索整个 MCP 生态，不必再去外面找工具目录。格局判断挺准——agent 平台的护城河不在模型，在工具供给。
1.2 注册与授权：console 邮件 + RFC 8628 设备流
自托管实例的邮件驱动默认是 console——注册后验证链接直接打在 api 容器日志里，抄出来浏览器打开即可。CLI/脚本接入走标准 OAuth 2.0 Device Authorization Grant（RFC 8628）：
curlhttp://localhost:8000/api/auth/device/code\--data-urlencode"client_id=omnara-cli"# 返回 user_code，用户在 dashboard 批准后轮询拿 PAT整个流程和我当年给开放平台做设备授权时的实现几乎一样。这种细节装不出来，团队里有人做过真实的开发者平台。顺手说一处：api 的结构化日志会记录每条 SQL 的查询名和耗时（CreateUser、AuthenticateBrowserSession……），还带auth.result/authorization.action字段。这是把可观测性当一等公民的团队才写得出来的日志。
1.3 接国产模型：建 provider 时实探 /models
自托管实例不带任何默认资源（hosted 版的omnara-openrouter和default-pool不自带），模型 provider 要自己配。我把 SiliconFlow 接了进去（OpenAI Chat Completions 格式）：
secret（凭据信封加密）→ model-provider-config → configured model → project grant创建 provider 的那一次 API 调用，服务端实时探测了 SiliconFlow 的 /models 端点并返回了 68 个模型的目录（DeepSeek-V4.1-Flash、GLM-5.3、Kimi-K2.7-Code……），status: ok。建 provider 的同时验证凭据可用性——这个细节很关键，它把"配错 key 到运行时才炸"提前到了配置时。
四层模型治理（provider → configured model → project grant → agent config 引用）看起来繁琐，但做过企业级平台的人应该认得出来：这就是当年我们做支付通道治理的同一套结构——通道、商户、项目权限、业务引用，每层独立授权独立回收。agent 平台做到这个粒度，说明它的目标用户是企业团队，不是个人玩家。
1.4 核心实测：一个 agent 的完整人机闭环
我写了个 11 行的agent.yaml：代码审查助手，列风险点 →ask_question问人类要深入哪条 → 给修复建议。模型用 DeepSeek-V4-Flash。
version:v1instruction:|你是 ai-lab 的代码审查助手。用户发来代码片段后： 1. 先列出最多 3 个风险点（每条一行，中文） 2. 然后用 ask_question 工具问用户想深入分析哪一条 3. 收到回答后给出该风险点的修复建议model:provider_config:siliconflowname:deepseek-v4-flashtools:ask_question:{}launch 时我发了一段有 TOCTOU 竞态的转账代码（get_balance→sleep(0.1)→set_balance，做过支付的都懂）。然后通过 SSE 事件流观察全过程：
Turn 1（3.35 秒）：模型准确识别出竞态条件、账号校验缺失、失败未回滚三个风险点，然后按指令调用ask_question——stop_reason: tool_use，事件里带结构化弹窗负载（prompt + 3 个选项 + multiple 标记）。用量 1788 输入 / 270 输出 token。
挂起 2 分 21 秒：agent 停在那里等我回答。注意，卡住的是对话，进程和资源早就释放了——状态落库，等唤醒事件再拉起来。
我通过 API 提交回答（选"并发/竞态条件"），resolve返回后——不到 8 毫秒，tool_result事件就进了时间线。
Turn 2（6.47 秒）：模型给出 CAS 条件更新、SELECT ... FOR UPDATE行锁、原子累加三套修复方案，stop_reason: end_turn。二次调用用量 2126 输入 / 610 输出，其中cache_read_input_tokens: 1536——提示缓存跨挂起命中了。
两轮总成本不到一分钱（3914 输入 + 880 输出 token，DeepSeek-V4-Flash 计价）。
1.5 真正的干货在 worker 日志里
事件流是"用户体验层"，worker 日志才是"工程实现层"。我扒了 turn 1 的完整 worker.loop 日志，几个关键证据：
runtime_lock.lease_expires_at: 90 秒租约 SQL: AcquireExecutionRuntime / FenceExecutionRuntime / ClaimNextAgentWakeup / OpenExecutionTurn / ResolveExecutionInput http.subrequests: POST api.siliconflow.cn/chat/completions 200 (911ms) 单 turn 68 条命名 SQL，db.queries.error_count: 0租约 + fencing + 唤醒队列——这套组合我太熟了。2018 年我们做支付工作流引擎，解决"worker 宕机后任务被重复执行还是丢失"用的就是同一套：运行时锁带租约防止双写，fence token 防止旧持有者复活后乱写，唤醒队列做解耦。Omnara 把这套东西为 agent 场景重做了一遍，而且做得不差。
这就是为什么我说它"生产就绪"：durable execution 不是一个 feature，是一套纪律。agent 等人回答问题可能要等几小时，等审批可能要等几天——这期间 worker 会重启、会扩容、会升级。没有租约和 fencing 的平台，这些都靠祈祷。
1.6 实话实说的边界
- BYO machine（omnarad daemon）和 machine pool 这次没测——本机 Windows 不是它的目标执行环境，sandbox 池需要额外基础设施。纯对话/审批类 agent 不受影响，但要跑
run_command类工具需要自己接机器。 - 文档质量高得反常（OpenAPI 3 万行、每个端点有语义描述），侧面反映项目在认真做 API 契约。
二、reason-network：想法锋利，但还只是协议演示
2.1 实测路径
Windows 二进制 v0.12.12（sha256 校验通过）。四步跑完：
reason-network doctor → 检测到本机 5 个 agent 全未接入 reason-network init → 建团队 ai-lab-test，拿到 team_id + endpoint （relay 在新加坡 relay-sin1.compute.reasonmachines.com） MCP 握手 → protocolVersion 2024-11-05，4 个工具签名 单机双 session 闭环 → alice 发消息，bob 的 listen 进程实时收到单机闭环的关键证据：alicesend返回"delivered: the session was waiting for messages"+ ULID，bob 端收到<reason-message from="alice/terminal" agent="cli">封装的消息，并附自动回复指引。
2.2 它做对了什么
MCP server 的 instructions 里有一句话值得引用：“message only when you need something / no small talk”。这是对 agent 间通信的纪律约束——没有这句，两个 LLM 会互相客气到天荒地老，token 烧光正事没干。
工具设计也收敛：只有 4 个工具（ask_user / check_inbox / list_team / send_message），附件上限 10 文件 × 256KB、总 512KB。约束写进协议层而不是靠提示词自觉，这是对的工程方向。
2.3 它为什么还不能上生产
- relay 在新加坡。国内团队用，消息要出海一圈。代码会出境吗？附件会出境吗？合规先把这个问题拍死。
- 底层是 iroh P2P，打洞失败走 relay——跨网络环境的到达率没有公开数据，我只验证了同机双 session。
- 没有持久化语义承诺。消息丢没丢、重不重，协议层没给答案。
所以现在的准确定位是**“协议演示”**：个人开发者玩多 Claude Code 互聊可以上，团队生产再等两个版本。
三、harp：好设计，但非macOS用户只能看源码
先诚实披露：harp 只支持 macOS，README 的安装节只给 dmg 和script/macos/run。我在 Windows 上跑不了，这部分是源码架构分析，不是运行实测。
3.1 它到底是什么
harp 是 Warp 终端的非官方 fork（AGPL-3.0），80 个 crates。核心改动一句话：把 tab bar 换成 agent 感知的侧边栏——每个 agent 会话有状态（working / waiting for you / done / inactive / background），人一眼扫过去知道哪个 agent 需要自己了。
3.2 两个值得抄的设计
limit-rings：侧边栏底部画每个 AI 供应商的额度环（5 小时窗 + 周额度双环）。数据源设计很聪明——Claude Code 的额度只在 status line 里出现，harp 就注入一个 statusLine 命令把数据落盘再读；更妙的是它开放了 JSON 格式（docs/limit-rings.md），任何外部工具都可以往这个文件写数据，harp 每 30 秒重读。读取超 15 分钟标记为 stale（虚线环），用到 80% 加粗。用文件做进程间契约，土但有效，而且零耦合。
multi_agent_client 只有 5.8KB：这个发现改变了我的判断。harp 里负责 multi-agent 通信的 crate 是个薄薄的 HTTP/SSE + protobuf 客户端——说明Warp 原版本来就有 multi-agent 通道，harp 的创新在 UI 层（状态聚合 + 注意力分配），不在协议层。这对评估它的长期价值很重要：UI 创新容易被上游吸收。
3.3 风险
非官方 fork 跟踪上游的成本是真实存在的；README 自己写着"Logging in through Harp is untested"。用它管理 agent 可以，拿它当主力终端要谨慎。
四、横向对比与生产落地判断
| 维度 | Omnara | reason-network | harp |
|---|---|---|---|
| 定位 | agent 运行时/托管 | agent 间通信协议 | 人看 agent 的面板 |
| 星数（10-25） | 3235 | 1192 | 602 |
| 本机可测性 | ✅ 完整部署 | ✅ 单机闭环 | ❌ macOS only |
| 工程成熟度 | 生产就绪（durable execution 完整）¹ | 协议演示 | UI 创新，协议靠上游 |
| 数据合规 | 全自托管，数据不出内网 | relay 在新加坡，消息出海 | 本地应用，无服务端 |
| 模型自由度 | 任意 OpenAI/Anthropic 兼容端点（含国产） | 不管模型 | 不管模型 |
| 上手成本 | 中（compose + 四层资源治理） | 低（单二进制） | 低（dmg 拖入） |
¹ 限对话/审批/人机协同类 agent；
run_command类工具需另接 BYO machine 或机器池，本次未测（见 1.6）。
什么团队该怎么选：
- 要在内网跑"持久 agent 员工"（代码审查、值班巡检、审批流）的，直接选 Omnara。三件套里只有它把"worker 挂了怎么办"当正经问题处理。四层资源治理刚上手确实啰嗦，但企业要的就是这份啰嗦。模型端点记得换成国产兼容端点，成本和合规一起省。
- 想让几个本地 coding agent 互聊的，reason-network 现在可以玩，但涉密代码别发——消息要绕新加坡。等它出自托管 relay 再谈生产。
- Mac 上同时开三个以上 Claude Code / Codex 的，harp 是目前唯一的现成面板。我只有源码层面的判断，装之前建议自己先试一周。Windows 用户短期内等不到，能替代的只有 tmux 加多窗口自己拼。
- 还有一种情况三件套都别上：需求本身是"一个 agent 干一件事、干完就退"。那是昨天 day-trader-skill 的场景，单体流水线就够。基建的价值随 agent 数量指数增长，也在 agent 少于两个时直接归零。
五、收尾：演进的三级火箭
把这周三篇文章连起来看，轨迹很清楚：
- 单体（day-trader-skill 实测：一个垂直 skill 的教科书式编排，10-24）：一个 agent 把一件事做对，靠 SKILL.md 契约和 fail-closed
- 流水线（从单体 Agent 到流水线：一个交易 skill 展示的编排范式
，10-24）：多个步骤编排起来，靠编排器 - 团队（本篇）：多个 agent 并行干活 + 互相通信 + 被托管，靠基建三件套
和微服务演进完全同构。当年我们先学会写一个服务，再学会用 MQ 串起来，最后才不得不上服务治理。agent 世界把这条路压缩到了一年。
我的判断：三件套里 Omnara 会最先进入企业视野，因为"durable execution + 自托管 + 国产模型兼容"这三个词的组合，正好命中国内团队的采购清单。而 harp 证明的"agent 感知 UI"这个方向，大概率会被 Claude Code / Cursor 这些上游直接吸收——就像当年 IDE 吸收了所有独立插件的好点子一样。
实测物料：本文全部命令、事件流原始 JSON、worker 日志摘录见 ai-lab 仓库（2026-10-25-agent-team-stack目录）。环境限制声明：harp 为源码架构分析（macOS only），reason-network 跨网络到达率未测，Omnara 的 BYO machine/pool 未测——以上均在对应章节标明，不影响已给出结论的证据链。
讨论问题：你们团队现在跑到哪一级了——单体、流水线，还是已经开始头疼"一群 agent 怎么管"？评论区聊聊，我优先实测呼声最高的方向。
