进阶 📋 6 个步骤 第 223 / 446 篇

用 CodexLoom 把 Codex 织成「长期在岗」Agent 团队:前 Manus 成员开源的协作范式

2026 年 8 月前 Manus 成员开源 CodexLoom,不重造 runtime,只给 Codex 加上身份、治理证据与协作机制,把零散的 Codex 会话织成能长期在岗、自主协作的 Agent 团队。本教程手把手教你跑通第一个多 Agent 协作任务。

2026.08.03· 20 分钟阅读· 约 1298 字· 🧵 CodexLoom / 🤖 Codex

你手头可能有一堆用完即弃的 Codex 会话:这个写了个脚本、那个修了个 bug,彼此毫无关联,下次还得重新交代背景。2026 年 8 月,前 Manus 成员开源了 CodexLoom——它不重造 runtime,只给 Codex 加上「身份、治理证据与协作机制」,把零散的会话织成能长期在岗、自主协作的 Agent 团队。本教程手把手教你跑通第一个多 Agent 协作任务。

🧵 本教程适合:已经在用 Codex / Codex CLI 写代码、但苦于「会话之间不连续、无法协作」的开发者。你需要 Node 环境和一个 Codex API Key。

先搞懂:CodexLoom 和单机 Codex 差在哪?

用一句话理解:单机 Codex 是「临时工」,CodexLoom 把它织成「长期在岗、有工牌、有交接记录」的团队成员。

维度单机 Codex 会话CodexLoom 团队
身份无,每次都是陌生人每个 Agent 有固定角色与工牌
记忆会话结束即失忆跨会话保留上下文与产出
协作无法互相调用Agent 间可派活、交成果
治理无审计每次行动留治理证据(可追溯)

它的设计哲学:Owner 指南把「产品原则、已验证实践、假设」分开标注。它明确「不重实现 runtime、只加身份与治理证据」——所以你现有的 Codex 能力全保留,只是被组织起来了。

Step 1:安装与初始化

1 克隆并启动

项目早期(约 64 star),直接从 GitHub 拉取运行:

git clone https://github.com/yan5xu/codexloom.git
cd codexloom
npm install
export CODEX_API_KEY="你的Key"

# 初始化一个团队工作区
npx codexloom init my-team
💡 新手提示:如果 npm install 报 Node 版本问题,确认本地是 Node 18+。初始化后会在当前目录生成 my-team/ 工作区。

Step 2:用 Owner 指南声明团队原则

2 先把「规矩」写清楚

CodexLoom 的核心是 OWNER.md——你作为团队 Owner 写下的原则。把三类内容分开放:

# OWNER.md
## 产品原则(不可动摇)
- 所有产出必须可复现
- 不泄露密钥到日志

## 已验证实践(照做即可)
- 数据库迁移走 migrate 脚本
- 接口测试用 vitest

## 假设(待验证,需标注)
- 用户量 < 1 万时单实例够用

为什么要分三类:「假设」和「已验证」混淆,是 Agent 团队跑飞的主因。明确标注,Agent 在不确定时就知道「这是假设,得先验证」。

Step 3:织入第一个 Codex 会话

3 把已有会话变成「在岗成员」

把你之前跑过的 Codex 会话导入,赋予它身份,让它后续可被调用:

# 把一个 Codex 会话织入团队,并命名角色
npx codexloom weave \
  --session ./sessions/fix-auth.json \
  --role "auth-specialist" \
  --desc "负责登录鉴权相关改动"

# 查看当前团队成员
npx codexloom team list
# → auth-specialist (在岗) · data-pipeline (在岗)
🚀 这一步是「织」的精髓:你不是从头造 Agent,而是把过去有价值的 Codex 产出,重新组织成可持续调用的成员。

Step 4:让多个 Agent 协作(身份 + 治理证据)

4 派一个需要协作的任务

给团队派活,CodexLoom 会把任务拆给对应成员,并留下治理证据:

npx codexloom run \
  "给 checkout 模块加幂等保护,并补集成测试" \
  --assign auth-specialist,test-engineer

# 运行后查看治理日志(谁做了什么、依据哪条原则)
npx codexloom audit last
# → auth-specialist: 改动基于 OWNER.md「接口测试用 vitest」
# → test-engineer: 新增 3 个用例,覆盖并发重复提交
💡 治理证据让每个 Agent 的行动都可解释、可追责——这正是它相对「黑盒多 Agent」最大的不同。

Step 5:验证「已验证实践」与「假设」

5 别让假设悄悄变成结论

定期审视 OWNER.md 里的假设,验证后转正或推翻:

# 列出所有待验证假设
npx codexloom assumptions

# 验证通过后,把假设升级为已验证实践
npx codexloom confirm "单实例够用" --evidence "压测 1.2 万 QPS 无异常"
# → 该条从「假设」移到「已验证实践」

关键纪律:假设没验证前,Agent 不能把它当事实用。这条红线守住了,团队才不会「自信地犯同一个错」。

Step 6:持续在岗与交接

6 让团队跨会话、跨天持续工作

CodexLoom 的价值在于「长期在岗」。下班前派个长任务,第二天来收工:

# 派一个跨夜的长任务
npx codexloom run "重构 utils 模块,分步提交" --async

# 第二天查看进度与交接记录
npx codexloom status
npx codexloom handoff print   # 生成给人类/新 Agent 的交接摘要
🎉 恭喜!你已把一个「用完即弃」的 Codex 会话群,升级成有身份、有治理、能长期协作的 Agent 团队。核心不是新 runtime,而是组织和纪律。

常见问题速查

现象原因 & 解决
weave 导入会话报错会话格式不对,确认是 Codex CLI 导出的 JSON,而非截图
Agent 擅自违反原则OWNER.md 原则写得模糊,改成可执行的硬规则
假设被当事实用没跑 confirm,在提示里强调「假设未验证前不得作为前提」
audit 日志为空该任务没走 run 入口,直接调 Codex 不经过 Loom 治理层
← 返回教程中心