OneCLI Team Agent Harness

wiki/ai/sources/onecli-team-agent-harness.md

分类：ai / sources · 更新：2026-08-27 09:09

OneCLI Team Agent Harness

核心结论

OneCLI v2 把“每个人一个 agent”产品化为团队级 harness：每个员工有自己的 sandboxed personal agent，通过统一 gateway 注入凭据并执行 policy；支持 IdP provisioning、deterministic human-in-the-loop approvals、team-level connections、agent memory/skills/schedule、Slack adapter、outbound-only runner、sandbox supervisor 和 short-lived SSH certificates。README 还明确提到 Hermes / OpenClaw / NanoClaw 等 autonomous agents 是其需求来源之一。^[raw/articles/onecli-team-agent-harness-2026-08-27.md]

为什么对用户重要

它把 Harness-Engineering 与 Loop-Engineering 的组织化形态讲得很清楚：当 agent 从个人工具变成团队基础设施，核心问题变成身份、凭据、审批、sandbox、runner、channel、memory/skills 的生命周期。对 Hermes 用户尤其相关，因为 Hermes cron / gateway / skills / memory / scheduled work 已经具备长期 agent 的雏形；OneCLI 提供了“团队化时需要补哪些控制面”的参考。

机制 / 一阶原理

OneCLI 的关键机制是把 agent 运行分成控制面和执行面：API Server 拥有 database、conversation plane 和 work queue；Runner outbound-only 轮询任务并启动/reap sandboxes；Rust Gateway 拦截 outbound requests 并按 host/path 注入凭据，agent 自身看不到 secret；Sandbox Supervisor 提供 vendor-neutral harness interface；Channel Adapter 让每个 agent 以独立 Slack app 出现。这样，agent 能行动，但凭据、审批和身份不由 agent 自己保管。

对 Hermes / llm-wiki 的启发

长期 cron 应逐步拥有 job identity：例如“llm-wiki radar”与“发布到 CVM”不应共享同一权限叙事。
高风险动作需要 deterministic approvals；无人 cron 默认只做发现、raw/source/wiki 写入，不应自动进入外部生产系统。
Memory / skills / schedule 是 agent 的持久能力，应配套可读、可编辑、可审计边界，避免长期漂移。

失败模式 / 边界

OneCLI 是高相关工具，但本轮只读取 README/官网 metadata，未部署验证 gateway MITM、sandbox supervisor 或 Slack adapter。因此今天适合晋升为架构样本，不适合给出可运行性背书。与 ToolHive 相比，它更关注“team agent platform”，不是单纯 MCP server gateway。

关联

Loop-Engineering：agent schedule、memory、runner 与长期唤醒。
Harness-Engineering：sandbox、approval、gateway 和 vendor-neutral harness interface。
MCP-Gateway-Runtime：gateway 注入凭据和执行 policy 的 action boundary。

写入记录

2026-08-27 09:00 CST：根据 OneCLI README 新增 source 页，提炼团队 agent harness 的身份、sandbox、凭据注入、approval 和 runner 架构。