XiaoBaCLI to XiaoBaOS

我最初做 xiaobaCLI 时，并没有打算造一个“Agent OS”。目标很直接：参考成熟 Coding Agent 的形态，搭好 Agent Loop 和 Base Tools，让模型能在真实工作目录里完成任务。前半段演进直接来自企业 IM 与行业交付，后半段则是在复盘试点暴露的稳定性和发布风险后继续补齐；其中一些机制仍在验证，不能倒叙成一开始就想清楚的蓝图。

回头看，这条演进路径可以压缩成一句话：聊天 CLI → 能干活的 Agent Harness → IM 在线同事 → 可复用职业底座 → 可评测 Runtime → 可治理进化 OS。

起点：先让 Agent 真正完成任务

xiaobaCLI 的起点主要解决“能不能干活”。基础 CLI 出现后，Session、Context 压缩与第一个飞书入口几乎同时进入系统：Agent 既要持续调用文件、Shell 和搜索工具，也要在多轮消息中保存状态，而不是每一步都从头开始。微信是后续新增的入口，不是最初触发架构变化的原因。

在工程咨询场景里，我把已有的报告生成、资料检索、图表生成和图纸分析能力封装成 Skill；在生物信息场景里，则把企业已有的 Python、R 脚本参数化，让 Agent 能按固定流程调用。这里的关键并不是让模型重新发明业务算法，而是把已经存在、已经被专家使用的能力变成可组合的执行接口。

因此，项目并不存在一段“CLI 已经完全做好，才开始接 IM”的整齐阶段。更真实的过程是：一边补 Agent Harness，一边把它放进飞书使用；CLI 的默认假设也在这个过程中不断失效。

转折：Coding Agent 直接搬进 IM 为什么不成立

CLI 中合理的交互，在 IM 中未必合理。IM 不是远程终端，用户也不是在启动一次性 Job；他会在任务运行时继续追问、补充条件，甚至要求停止。一个像同事的 Agent，还不能把几十次工具调用连续刷进聊天窗口，最后再丢下一句“已完成”。

这让我重新定义了产品：IM Agent 不是套了消息入口的 Coding Agent，而是一个需要持续在线、能并行工作、并对交付负责的 Runtime。

第一次架构跃迁，以及一次真实返工

原来的执行链很简单，也很容易阻塞：

User → CLI Agent → long tool loop → final answer

第一步是加入异步 Subagent，把长任务移出主会话。但早期实现仍允许 Subagent 直接向飞书发送消息和文件。阻塞缓解了，新的问题却出现了：Main Agent 和多个 Subagent 都能对外说话，用户会收到多出口消息，交付权也变得模糊。

User → Main Agent → Subagent
          │              │
          └── reply ─────┴── send text / file → User

随后我才把架构收敛为 Main Agent 唯一用户出口：Subagent 负责后台执行，完成通知把最终结果和产出文件路径回注主会话，再由 Main Agent 组织交付。

User ↔ Main Agent
          │
          ├─ 直接处理短任务
          │
          └─ spawn → independent Subagent Session
                         ↓
                 tools / files / context
                         ↓
             resultSummary + outputFiles
                         ↓
Main Agent → send_text / send_file → User

在当前架构中，Main Agent 是唯一用户交互入口，也是任务编排器。短任务由它直接完成；长任务进入独立 Subagent Session。Subagent 与 Main Agent 复用同一套 Agent Loop 和工具边界，但拥有独立会话与执行上下文；后续证据系统又为 Subagent 补上了独立 Trace。主会话在后台任务运行时仍能响应用户，也可以查询或发出停止指令。

这里还有一个容易被忽略的区别：send_text 和 send_file 不是普通业务 Tool，而是用户可见消息的交付边界。默认情况下，模型生成 final text 不会自动外发；发送成功必须形成结构化 Delivery Evidence，平台能够返回消息或文件确认时，再补充 External Delivery Receipt。

这个设计没有消灭所有分布式系统问题。外部副作用发生后无法靠停止 Subagent 回滚，运行中任务的跨进程恢复也仍未完全收口。当前停止语义可以关闭 Runtime 会话并阻止迟到结果继续回注，但 Provider、Shell 或脱管子进程能否立即物理终止，仍取决于对应 Adapter 是否正确传播 AbortSignal。它先解决的是 IM 场景最核心的矛盾：后台工作可以很长，用户交互不能因此停住。

从硬编码 Agent 到 Role / Skill 分层

早期版本已经有 Plan Agent、Explore Agent、Bash Agent、Code Reviewer 等硬编码类型，同时 Skills 也在不断增长。它们能工作，但每增加一种职责，都可能复制一组类、Prompt 和工具配置。随着工程咨询、生物信息、浏览器操作和办公协同能力继续增加，我才把它收敛成“共享一个 Runtime、用声明式 Role 定义职责、用 Skill 挂载领域流程”的结构：

例如，我在长期论文工作中积累了检索文献、设计实验、保存结果、编写 LaTeX、生成 PDF 和制作汇报材料的一整套工作流，最后把它人工沉淀为 Researcher Role。这个例子能证明 Role 可以从真实使用中长出来，但不能倒过来说它是自进化系统自动生成的：当时完整的候选验收链还没有建立。

Role / Skill 分层解决的是能力如何组织与复用；它还没有回答另一个更难的问题：这次能跑通，换一个模型、Prompt、Skill 或 Runtime 版本后，还能不能跑通？

跑成功之后，为什么还需要 Trace 与 Replay

企业试点之后，我开始意识到，一次成功只能证明“这次没有失败”，不能证明系统稳定。Agent 的结果同时受模型采样、上下文、工具响应和环境状态影响，普通单元测试只能覆盖确定性代码，不能替代行为评测。

当前架构合同把状态区分成四层：用户可见的 Conversation Journal、可恢复的 Durable Session、发给模型的 Provider Transcript，以及记录本轮输入、Subagent、Tool、Artifact、异常和交付的 Trace。Conversation Journal 是后续补上的用户事实层，四层在部分历史与兼容路径上的严格物理分离仍在推进；但概念上不能再把它们混成一份“万能历史”，因为恢复、模型上下文和评测证据回答的是不同问题。

在此基础上，回归链路收敛为：

Case + Oracle
      ↓
Replay current Runtime
      ↓
fresh Trace
      ↓
deterministic Verifier
      ↓
ReviewerCat semantic judge
      ↓
Outcome: pass / fail / blocked

Replay 的职责只是重新执行 Case 并产生 fresh Trace，不负责宣布成功。Verifier 按 Case 声明检查 Registry 已支持的硬事实；当前默认覆盖 Trace 是否存在、Tool 是否失败和只读边界，Artifact 或 Delivery 检查需要由具体 Case 显式配置。硬检查通过后，ReviewerCat 才判断语义质量。确定性规则负责事实，语义评审负责开放式质量，两者不能互相越权。

固定 Case 看不到真实用户

Case 仍然有一个天然缺点：它通常由开发者编写，只能覆盖开发者已经想到的问题。真实用户的表达会更模糊，会遗漏背景，也会在多轮对话中改变要求。因此 xiaobaOS 又增加了 Arena，让 UserCat 按 Scenario 与被测 Agent 自然互动，再由 InspectorCat 从普通 Trace 中提取可复现的 Finding 和 Case。

Scenario
   ↓
UserCat ↔ Subject Agent
   ↓
standard Trace
   ↓
InspectorCat → Finding + Case
                    ↓
              shared Evaluation

这也不是 Arena 一开始就拥有的边界。初版同时承担 Scenario、Scorecard、Candidate 验收和可选发布，结果与 Evaluation、自进化控制层重复。后来我删除独立 Scorecard Worker、人工 Promotion 和重复 Replay 路径，才把它收敛成当前职责：Arena 负责发现未知问题，不拥有另一套评审器，也不负责发布 Candidate。所有新 Case 最终仍进入同一条 Evaluation 链，避免系统同时维护两份互相冲突的“成功真相”。

从“会生成 Skill”到可治理进化

xiaobaCLI 很早就出现过名为 self-evolution 的 Skill：它可以生成新的 Skill 和 Python Tool，但会直接写入生产目录。那时的“进化”只证明系统会生成能力，没有回答生成物是否正确、是否优于当前版本、失败后如何保持生产版本不变。

后来我才把“生成”与“发布”拆开，并把当前 xiaobaOS 收敛为一条轻量控制链：Trace 先由 InspectorCat 形成 Finding 和可执行 Case；已经存在的失败 Case 则直接进入 Candidate 生成，不再重复检查，也不会把 Replay Trace 递归送回 Inspector。

Trace → InspectorCat → Finding + executable Case ─┐
Existing failed Case ─────────────────────────────┤
                                                  ↓
                                           Candidate owner
                                      ├─ EngineerCat: code
                                      └─ EvolutionCat: Role / Skill
                                                  ↓
                                             shared Test
                                                  ↓
                                             shared Eval
                                                  ↓
                                          atomic activation

Test 负责代码和契约，Eval 负责 Agent 行为。两者全部通过后，Role / Skill Candidate 只对新 Session 生效，代码 Candidate 只由下一进程加载；失败、blocked 或激活异常都保持当前版本不变。运行中的 Session 不热更新能力版本，因为同一条 Trace 前后使用两套行为，会让问题无法解释，也让 Replay 失去版本依据。

这套机制证明的是“变化受到治理”，不是“系统已经越用越好”。真正的长期收益仍需要更多线上 Trace、独立 Case 和跨版本数据验证。对我而言，先建立发布权和证据边界，再讨论自动增长，比先画一张宏大的自进化 DAG 更重要。

为什么最终改名为 xiaobaOS

当项目开始统一管理入口、会话、后台任务、角色、技能、工具、交付证据与评测时，它已经不再只是一个 CLI，我也因此把它正式改名为 xiaobaOS。改名并不代表架构已经完成：Arena 的职责收缩、共享 Test / Eval 和更严格的状态边界，都是此后继续发生的纠偏。“模型是 CPU，Runtime 像操作系统”更像一条工作约束，而不是项目一开始的宣言。

这个类比也有清晰边界：xiaobaOS 不是通用操作系统，不提供内核级进程隔离，也不是分布式任务平台。更准确地说，它是一套本地优先、面向消息场景的 Agent Harness Runtime 与控制面。

还没有解决的问题

一篇工程复盘如果只写已经成立的部分，很容易再次变成架构宣传。当前维护中的真实 Agent CaseSet 只有 3 条只读 Case，它证明共享评测链能够运行，不证明系统已经覆盖广泛能力；需要写工作区的 Replay 和 Source Candidate 原生沙箱目前只在 macOS 可用，其他平台会 fail closed。

运行中的 Subagent 尚未完成完整的跨进程恢复；外部写操作的幂等与完成态仍依赖具体 Tool Server 的能力；Arena 和 Reviewer 的价值也取决于 Scenario、Case 与 Judge 本身是否可信。这些都是当前边界，而不是一句“可治理自进化”可以省略的工程问题。

这些问题不会因为项目改名为 OS 自动消失。相反，OS 这个名字真正带来的约束，是每增加一种能力，都要继续回答：状态由谁保存，副作用由谁确认，失败如何恢复，变化凭什么发布。

xiaobaOS 不是因为组件足够多才叫 OS，而是因为它开始统一管理入口、会话、任务、能力、交付证据与版本变化。前半段由真实工作逼出，后半段在一次次过度设计和边界纠偏中收敛；真正的长期效果，还要继续用运行证据证明。