yan5xu 打算给他做了一个多月的项目上线 Landing Page，本想先放上去再慢慢打磨。他把上线指令丢给了负责 Web 的 Agent，然后转头忙别的去了。等他再看消息时，公告已经发到飞书群里了——负责 Web 的 Agent 在完成上线后，按照之前声明过的协作关系，通知了负责对外沟通的 Community Agent；后者判断这是条大新闻，自己整理素材发了出去。
他没有站在几个 Agent 中间，来回判断该找谁、搬运上下文、转交结果。工作沿着已有的责任和授权边界，自己走完了。这件事听起来像事故，但恰恰是他想要的结果。
这就是 CodexLoom 想做的事：把一条条独立的 Codex 会话，织成一支长期在岗、能自己协作、由人来治理的 Agent 团队。项目 7 月初开源，Go 写的，作者 yan5xu 自己用它维护着 33 个 Agent。
你的 Agent 越多，你可能越忙
先说清它要解决什么问题——任何同时使用多个 Agent 的人早晚都会撞上。
大部分人用 Agent 是从一次性任务开始的：开个新会话，说清这次要干什么，拿到结果，结束。这没什么毛病，一次性任务本来就不需要一个 Agent 长期存在。
但真实工作里，任务会结束，责任不会。文章写完了还要改，页面上线了还要迭代，这个月研究过的公司下个月出了新融资又得再看一遍。每次回来都不是简单重复——上次的判断、你给出的纠正和偏好，本应继续起作用。每开一个新会话，你付的不只是 token，是重新建立一次合作关系。
于是自然的选择是让 Agent 留在同一条会话里，从上次接着干。它就从一个任务型工具变成了一个长期在岗的数字员工。
接着第二件事会发生：它越好用，你交给它的活越多。一开始让它写文章，后来找资料、做研究、管内容，再后来页面、SEO、对外分发也一并给它。直到不同工作的上下文和判断标准挤在一起，它开始变慢、质量下滑、反复要你纠正。这时候你就得拆——研究交给 Research Agent，页面交给 Web Agent，对外沟通交给 Community Agent。
拆完，问题看似解决了。但作者点出了最要命的那一步：多个 Agent，并不会自动成为一支 Agent Team。
因为分工只存在于你的脑子里。每次有新活，还是你判断该找谁；开工前，还是你整理背景和材料；一个 Agent 做完，还是你读懂结果、判断能不能用、再转交给下一个。Agent 可以并行，你却只能逐个读、逐个判断、逐个路由。
瓶颈从“单个 Agent 不够强”，变成了“你自己”。 Agent 越多，你要维护的上下文和协作关系越多。这就是为什么很多人会有“Agent 更多了，人却更忙了”的体感。
第一步不是让 Agent 互发消息，是让分工离开你的脑子
CodexLoom 做的第一件事有点反直觉——不是急着让 Agent 之间开始通信，而是先给每个 Agent 一个稳定身份。
一条 Codex 会话可以绑定到一个长期 Agent，它有稳定的名字、身份和工作入口，下次工作仍然回到同一个主体继续。在这之上，每个 Agent 有一份 Profile，只回答三个问题：
- Identity：它是谁
- Domain：它长期负责什么
- Scope：它在哪里停下，什么不属于它
作者特意强调，Profile 不是给 Agent 发工牌，也不是写一段更长的 system prompt。它是把你已经从真实工作里摸出来的边界记下来。而且顺序很关键——不是“创建 Agent → 填 Profile → 得到一个 Domain Agent”，而是真实工作先暴露边界 → Profile 记下当前理解 → 后续工作继续验证和修正。
Profile 是这支团队当前采用的组织假设，不是最终答案。看官方的协作图就能印证：每个 Agent 卡片下面标着 PROFILE V1、V4、V5、V7——版本号不一样，说明这些边界都是在真实工作里不断改出来的。
回到开头那个故事，Scope 的意义就具体了：Web Agent 的责任是实现页面并上线，页面 live 了，它就走到了自己的边界；接下来该不该对外发、发哪个渠道、怎么表达，是 Community Agent 的判断。反过来 Community Agent 也不会因为管对外沟通，就去接管页面部署。Scope 不只说“你负责什么”，更说“你在哪儿停下，什么时候该交给别的 Domain”。
Agent 之间直接通信，人只在该出现的地方出现
身份和边界立住之后，Agent 才能开始直接协作。它们通过 Message 互相发消息、排队、回复；跨 Agent、跨天的事项用 Topic 收口；最终文件通过 Artifact 交接。
下面这张是作者自己 workspace 的真实截图，能看到一条 loom-product → loom-coach 的通知：新版产品结构已上线、生产版本号多少、测试和验收结果如何。这条消息不是发给人的，是一个 Agent 发给另一个 Agent 的工作交接。
那人去哪了？人退到了真正需要决策的位置。CodexLoom 有个叫 Needs You 的界面，只放真正需要你拍板的事——某个事实、某个选择、某项授权。作者定了一条很清醒的规矩：普通的 Agent 间回复应该回到发起请求的那个 Agent，由它自己整合；要是每条中间回复都发给你，就等于重新制造了这支团队本该减少的转发负担。
官方截图里 Needs You 是空的，写着“Nothing needs your input”，而右上角显示已答复过 26 条。Agent 会一直干到真的需要人为止。
作者还专门提醒：Agent 的收件箱是它自己的，可以当作负载和路由问题的证据，但不是你的第二份待办清单。这个区分很实在——很多多智能体工具最后都变成了给人堆消息。
它明确不做什么
这个项目让我意外的是边界感。作者在中文 Owner 指南里划了几条线，而且那份中文指南是正典、英文版是译本，分歧时以中文为准。
它不重新实现 agent runtime。 Codex 仍然是运行时，CodexLoom 只在上面加身份、责任、关系、通信、治理证据。它也不复制会话历史。
它不拥有你的目标。 原话是：Loom 只拥有它能可靠治理的 Agent 身份、长期责任、关系、通信和运行证据；业务项目、客户承诺、经营结果、什么算成功，仍然归 Owner 和他的业务事实源。
它不做企业多租户。 服务的是一个高级个人 Owner。同事可以通过飞书、Slack 里的受治理 Interface Agent 跟你的 Agent 协作，复用你长期养出来的能力，但产品方向不是企业管理系统。
Overview 不是公司仪表盘。 里面的负载、token、活跃度是观察信号，作者明说了不该当成绩效分数或自动的组织决策依据。
这几条加起来，比功能列表更能说明它想清楚了什么。多智能体这块最常见的翻车方式，就是把“看起来很忙”当成“运转良好”。
谁该看看它
如果你正在同时维护好几个 Agent，并且已经有“我在给它们当中转站”的感觉，这套东西说的问题你会秒懂。作者给的路径也很克制：从一个长期 Agent 开始，别一上来就画组织架构图；等重复工作真的暴露出负载、上下文或专业判断的边界，再拆。
也得说清现状。项目 7 月 7 日建仓，现在 64 star，还很早期；本地优先、需要自己从源码跑起来（装 codex CLI、ChatGPT 账号登录、make release）；Topic 和 Trigger 这些能力目前只在开发构建里，作者在文档里单独标注了、没算进 main 分支的承诺。协议是 NOASSERTION，商用前得自己确认许可。
别指望装上就能用，它更像一份被产品化了的最佳实践。真正值钱的是那份中文 Owner 指南——里面把“产品原则、当前行为、已验证实践、当前建议、假设”五类陈述分开标注，这种诚实在国产开源项目里不多见。
一年前大家比谁的 Agent 更强，今年比谁能同时开更多 Agent。yan5xu 这个项目提前问了下一个问题：当 Agent 长期存在、各有地盘、还得互相配合时，那些原本装在你脑子里的责任、关系和交接方式，该怎么变成整支团队都能用的东西。
项目地址
GitHub：https://github.com/yan5xu/codexloom
中文 Owner 指南（正典）：https://github.com/yan5xu/codexloom/blob/main/docs/owner-guide.zh-CN.md
官网：https://codexloom.ai/zh-cn/
发表于 1 小时前
|
查看: 6|
回复: 0
