选题由来一周之内agent 团队的栈被凑齐了前两天我实测了 day-trader-skill单体 agent 用 SKILL.md 契约 fail-closed 编排把一件事做扎实。文章发出去的同一天我在 GitHub 趋势数据里看到一个更值得警惕的信号三个解决一群 agent 怎么管的项目在同一周内集中冒头。reason-network1192★10-16 建仓coding agent 之间的 P2P 通信引擎harp602★10-20 建仓一个侧边栏同时盯多个 Claude Code / Codex agentOmnara3235★HN 在榜开源自托管的 managed agent 平台对标 Claude Managed Agents做过后端的人看到这个组合应该会心一笑。当年单体拆微服务最先成熟的不是业务框架而是三样基础设施服务发现、RPC、容器编排——Netflix Eureka、Dubbo、Kubernetes。业务代码谁都会写但服务之间怎么找到对方、怎么说话、在哪里跑、挂了怎么办才是决定能不能上生产的东西。agent 正在走同一条路。这三件套恰好各占一个坑位微服务时代agent 时代解决什么监控面板/服务拓扑harp人怎么看住一群 agentRPC 服务发现reason-networkagent 之间怎么互相说话K8s/容器编排Omnaraagent 在哪里跑、持久化、被托管所以我花了大半天把三个项目全部拉到本机实测。跑完发现星数排序和可用性排序完全不一致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 ValkeyRedis 兼容 Postgres 18 RustFSS3 兼容对象存储 nginx。一个容器扛完所有的玩具 demo 我见得太多了这个栈的排布是正经的控制平面架构。dockercompose-fcompose.yaml--profileapp up-d一个坑先说出来仓库里有个compose.override.yaml在源码检出时会自动加载并把 5个应用服务改成本地构建。我在起栈前先翻了目录看到它就改用了-f compose.yaml要是没翻接下来就是几十分钟的 Rust 编译而且大概率在中途报错。这个设计对贡献者友好对只想跑起来的人是暗坑。起栈后 migrate 一次性任务退出码 0api 日志里第一行就让我停下来看了两眼{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 GrantRFC 8628curlhttp://localhost:8000/api/auth/device/code\--data-urlencodeclient_idomnara-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 13.35 秒模型准确识别出竞态条件、账号校验缺失、失败未回滚三个风险点然后按指令调用ask_question——stop_reason: tool_use事件里带结构化弹窗负载prompt 3 个选项 multiple 标记。用量 1788 输入 / 270 输出 token。挂起 2 分 21 秒agent 停在那里等我回答。注意卡住的是对话进程和资源早就释放了——状态落库等唤醒事件再拉起来。我通过 API 提交回答选并发/竞态条件resolve返回后——不到 8 毫秒tool_result事件就进了时间线。Turn 26.47 秒模型给出 CAS 条件更新、SELECT ... FOR UPDATE行锁、原子累加三套修复方案stop_reason: end_turn。二次调用用量 2126 输入 / 610 输出其中cache_read_input_tokens: 1536——提示缓存跨挂起命中了。两轮总成本不到一分钱3914 输入 880 输出 tokenDeepSeek-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 条命名 SQLdb.queries.error_count: 0租约 fencing 唤醒队列——这套组合我太熟了。2018 年我们做支付工作流引擎解决worker 宕机后任务被重复执行还是丢失用的就是同一套运行时锁带租约防止双写fence token 防止旧持有者复活后乱写唤醒队列做解耦。Omnara 把这套东西为 agent 场景重做了一遍而且做得不差。这就是为什么我说它生产就绪durable execution 不是一个 feature是一套纪律。agent 等人回答问题可能要等几小时等审批可能要等几天——这期间 worker 会重启、会扩容、会升级。没有租约和 fencing 的平台这些都靠祈祷。1.6 实话实说的边界BYO machineomnarad daemon和 machine pool 这次没测——本机 Windows 不是它的目标执行环境sandbox 池需要额外基础设施。纯对话/审批类 agent 不受影响但要跑run_command类工具需要自己接机器。文档质量高得反常OpenAPI 3 万行、每个端点有语义描述侧面反映项目在认真做 API 契约。二、reason-network想法锋利但还只是协议演示2.1 实测路径Windows 二进制 v0.12.12sha256 校验通过。四步跑完reason-network doctor → 检测到本机 5 个 agent 全未接入 reason-network init → 建团队 ai-lab-test拿到 team_id endpoint relay 在新加坡 relay-sin1.compute.reasonmachines.com MCP 握手 → protocolVersion 2024-11-054 个工具签名 单机双 session 闭环 → alice 发消息bob 的 listen 进程实时收到单机闭环的关键证据alicesend返回delivered: the session was waiting for messages ULIDbob 端收到reason-message fromalice/terminal agentcli封装的消息并附自动回复指引。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 只支持 macOSREADME 的安装节只给 dmg 和script/macos/run。我在 Windows 上跑不了这部分是源码架构分析不是运行实测。3.1 它到底是什么harp 是 Warp 终端的非官方 forkAGPL-3.080 个 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 可以拿它当主力终端要谨慎。四、横向对比与生产落地判断维度Omnarareason-networkharp定位agent 运行时/托管agent 间通信协议人看 agent 的面板星数10-2532351192602本机可测性✅ 完整部署✅ 单机闭环❌ macOS only工程成熟度生产就绪durable execution 完整¹协议演示UI 创新协议靠上游数据合规全自托管数据不出内网relay 在新加坡消息出海本地应用无服务端模型自由度任意 OpenAI/Anthropic 兼容端点含国产不管模型不管模型上手成本中compose 四层资源治理低单二进制低dmg 拖入¹ 限对话/审批/人机协同类 agentrun_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 onlyreason-network 跨网络到达率未测Omnara 的 BYO machine/pool 未测——以上均在对应章节标明不影响已给出结论的证据链。讨论问题你们团队现在跑到哪一级了——单体、流水线还是已经开始头疼一群 agent 怎么管评论区聊聊我优先实测呼声最高的方向。
选题由来一周之内agent 团队的栈被凑齐了前两天我实测了 day-trader-skill单体 agent 用 SKILL.md 契约 fail-closed 编排把一件事做扎实。文章发出去的同一天我在 GitHub 趋势数据里看到一个更值得警惕的信号三个解决一群 agent 怎么管的项目在同一周内集中冒头。reason-network1192★10-16 建仓coding agent 之间的 P2P 通信引擎harp602★10-20 建仓一个侧边栏同时盯多个 Claude Code / Codex agentOmnara3235★HN 在榜开源自托管的 managed agent 平台对标 Claude Managed Agents做过后端的人看到这个组合应该会心一笑。当年单体拆微服务最先成熟的不是业务框架而是三样基础设施服务发现、RPC、容器编排——Netflix Eureka、Dubbo、Kubernetes。业务代码谁都会写但服务之间怎么找到对方、怎么说话、在哪里跑、挂了怎么办才是决定能不能上生产的东西。agent 正在走同一条路。这三件套恰好各占一个坑位微服务时代agent 时代解决什么监控面板/服务拓扑harp人怎么看住一群 agentRPC 服务发现reason-networkagent 之间怎么互相说话K8s/容器编排Omnaraagent 在哪里跑、持久化、被托管所以我花了大半天把三个项目全部拉到本机实测。跑完发现星数排序和可用性排序完全不一致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 ValkeyRedis 兼容 Postgres 18 RustFSS3 兼容对象存储 nginx。一个容器扛完所有的玩具 demo 我见得太多了这个栈的排布是正经的控制平面架构。dockercompose-fcompose.yaml--profileapp up-d一个坑先说出来仓库里有个compose.override.yaml在源码检出时会自动加载并把 5个应用服务改成本地构建。我在起栈前先翻了目录看到它就改用了-f compose.yaml要是没翻接下来就是几十分钟的 Rust 编译而且大概率在中途报错。这个设计对贡献者友好对只想跑起来的人是暗坑。起栈后 migrate 一次性任务退出码 0api 日志里第一行就让我停下来看了两眼{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 GrantRFC 8628curlhttp://localhost:8000/api/auth/device/code\--data-urlencodeclient_idomnara-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 13.35 秒模型准确识别出竞态条件、账号校验缺失、失败未回滚三个风险点然后按指令调用ask_question——stop_reason: tool_use事件里带结构化弹窗负载prompt 3 个选项 multiple 标记。用量 1788 输入 / 270 输出 token。挂起 2 分 21 秒agent 停在那里等我回答。注意卡住的是对话进程和资源早就释放了——状态落库等唤醒事件再拉起来。我通过 API 提交回答选并发/竞态条件resolve返回后——不到 8 毫秒tool_result事件就进了时间线。Turn 26.47 秒模型给出 CAS 条件更新、SELECT ... FOR UPDATE行锁、原子累加三套修复方案stop_reason: end_turn。二次调用用量 2126 输入 / 610 输出其中cache_read_input_tokens: 1536——提示缓存跨挂起命中了。两轮总成本不到一分钱3914 输入 880 输出 tokenDeepSeek-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 条命名 SQLdb.queries.error_count: 0租约 fencing 唤醒队列——这套组合我太熟了。2018 年我们做支付工作流引擎解决worker 宕机后任务被重复执行还是丢失用的就是同一套运行时锁带租约防止双写fence token 防止旧持有者复活后乱写唤醒队列做解耦。Omnara 把这套东西为 agent 场景重做了一遍而且做得不差。这就是为什么我说它生产就绪durable execution 不是一个 feature是一套纪律。agent 等人回答问题可能要等几小时等审批可能要等几天——这期间 worker 会重启、会扩容、会升级。没有租约和 fencing 的平台这些都靠祈祷。1.6 实话实说的边界BYO machineomnarad daemon和 machine pool 这次没测——本机 Windows 不是它的目标执行环境sandbox 池需要额外基础设施。纯对话/审批类 agent 不受影响但要跑run_command类工具需要自己接机器。文档质量高得反常OpenAPI 3 万行、每个端点有语义描述侧面反映项目在认真做 API 契约。二、reason-network想法锋利但还只是协议演示2.1 实测路径Windows 二进制 v0.12.12sha256 校验通过。四步跑完reason-network doctor → 检测到本机 5 个 agent 全未接入 reason-network init → 建团队 ai-lab-test拿到 team_id endpoint relay 在新加坡 relay-sin1.compute.reasonmachines.com MCP 握手 → protocolVersion 2024-11-054 个工具签名 单机双 session 闭环 → alice 发消息bob 的 listen 进程实时收到单机闭环的关键证据alicesend返回delivered: the session was waiting for messages ULIDbob 端收到reason-message fromalice/terminal agentcli封装的消息并附自动回复指引。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 只支持 macOSREADME 的安装节只给 dmg 和script/macos/run。我在 Windows 上跑不了这部分是源码架构分析不是运行实测。3.1 它到底是什么harp 是 Warp 终端的非官方 forkAGPL-3.080 个 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 可以拿它当主力终端要谨慎。四、横向对比与生产落地判断维度Omnarareason-networkharp定位agent 运行时/托管agent 间通信协议人看 agent 的面板星数10-2532351192602本机可测性✅ 完整部署✅ 单机闭环❌ macOS only工程成熟度生产就绪durable execution 完整¹协议演示UI 创新协议靠上游数据合规全自托管数据不出内网relay 在新加坡消息出海本地应用无服务端模型自由度任意 OpenAI/Anthropic 兼容端点含国产不管模型不管模型上手成本中compose 四层资源治理低单二进制低dmg 拖入¹ 限对话/审批/人机协同类 agentrun_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 onlyreason-network 跨网络到达率未测Omnara 的 BYO machine/pool 未测——以上均在对应章节标明不影响已给出结论的证据链。讨论问题你们团队现在跑到哪一级了——单体、流水线还是已经开始头疼一群 agent 怎么管评论区聊聊我优先实测呼声最高的方向。
