这两年做 Agent 的团队几乎都掉进同一个坑把 Agent 当成一次性的任务执行器。来一个需求开一个 thread喂目标、给背景、拿结果、关掉对话。下个相关需求来了再开一个 thread背景重新讲一遍之前那个 thread 里沉淀的决策、约束、工具用法全丢了。每个任务都在重复支付冷启动的代价团队越大这种浪费越夸张。CodexLoom 这个开源项目建立在 Codex 之上local-first、自托管给出了一个挺不一样的答案。它不重新实现 Agent runtime也不去卷 workflow 编排而是做了一件更底层的事把一条 Codex thread 变成一个有稳定身份、长期存活的 Domain Agent再把一群这样的 Agent 组织成一个受治理的 Team最后通过 Interface Agent 把成熟能力交付到飞书、Slack 这些你本来就在用的地方。它自己的 slogan 很精准Codex 提供 threadCodexLoom 把 thread 编织成组织。先说清楚CodexLoom 解决的是什么大多数人理解的多智能体协作是一张 DAGA 调 B、B 调 C谁调谁写死在流程里。CodexLoom 的出发点恰好相反它不关心工作怎么在流程里流动它关心的是谁长期对哪块领域负责。这是它和一堆 workflow 编排框架最本质的区别。看一个对比就懂了。一个普通的 Task Agent围着单个任务被创建交付完 thread 就被丢弃或替换下一个任务又从零讲背景、重建上下文。CodexLoom 里的 Domain Agent 围着一块长期领域存在同样的 thread 持续接收这个领域的工作Profile 给 Agent 一个持久的身份、领域和边界thread 不再是一次任务的记录而是这个 Agent 持续工作的空间。任务在 Domain Agent 模型里依然存在但它从定义身份的东西退化为工作单元。这里有个很实在的担忧长 thread 会不会把上下文窗口撑爆、每次都更慢更贵CodexLoom 的回应是你只算了保留上下文的成本没算重建上下文的成本。新 thread 要到达同样的工作状态照样需要把相关背景、约束、历史决策补回来。复用 thread 还能让那段稳定的历史前缀命中 prompt 缓存而不是每次从零处理。CodexLoom 对 compaction 的态度也很清醒压缩不是把上下文清零。老历史压成摘要、近期轨迹仍然保留之后大量工作信息依然在。更讲究的一点是它不把摘要当成持久声明的唯一保证压缩之后的下一轮会重新覆盖当前完整的 Loom Agent Prompt、完整的 Agent Profile、以及直接的关系统览只有当可重放的部署证据和同一轮里的模型事件两者都在时这次修订才被标记为已覆盖。换句话说压缩是维持连续性的机制而不是丢弃 thread 的理由。更关键的是长 thread 会积累一种默会上下文纠正、偏好、术语、判断习惯这些东西很难写成一条条显式规则塞进 Profile但恰恰是它让一个 Agent 有了独特的手感。换个新 thread丢的就是这块最难迁移的知识。一个 Task Agent 从任务开始一个 Domain Agent 从既往工作继续这句话值得每个做多智能体的团队贴在墙上。Profile 与 Thread长期主体的两件套CodexLoom 把一个 Agent 当作一个持久的、长期存活的主体来对待而不是一次会话。它有两样东西构成这个主体的内核Profile 和 Thread。Profile 定义这个 Agent 是谁、长期对什么负责、边界在哪。一个领域可以是一个项目、一个子系统、一项专业能力、一个客户或一块业务。Thread 则随着交互、决策、工具调用、产物和反馈实时累积形成这个 Agent 随时间推移的工作轨迹。Profile 提供稳定的方向Thread 保存累积的工作让未来的任务能从已有上下文继续。Profile 还有第二重作用它向其他 Agent 暴露协作信息。它声明这个 Agent 拥有什么、哪些问题应该问它、哪些工作不在它边界内。所以它既是 Agent 自己的持久上下文也是整个组织的可发现性和协作契约。你设计一个 Agent第一件事不该是画流程图而是把它的 Identity、Domain、Scope 这三样最小的 Profile 写清楚先让它在真实工作里跑观察完再细化而不是一上来就设计一套完整组织。从 Domain Agents 到 Team三张地图当不同的 Agent 各自对一块领域长期负责它们之间的协作就不再是一次性的调用链而变成持续的协作。跨领域的工作需要找到负责的 Agent、请它出判断、请求帮助、报告问题。CodexLoom 这里的设计很克制也很聪明它用三张互相独立的地图来描述组织而不是把它们混在一个僵硬的层级里。Organization Map组织图呈现持久的父/子责任边界也就是谁对哪块大领域负责、下面拆了哪些子领域。Collaboration Map协作图记录声明过的跨领域工作关系但它不假装这些是层级只是声明A 和 B 之间会协作。Activity Map活动图则从 Messages 里派生出带时间范围的协作证据而 Directory 始终是每个 Agent 的精确清单。一句话声明的结构帮 Agent 找到对的负责人Message 历史则展示这个结构在真实工作中到底怎么运转。这种声明而非强制层级的思路落到一个具体模式上就是 Lead 和 Internal Agent。当一个领域变大它的 Owner 可以升级成 Lead把稳定的子领域下放给若干 Internal Agent每个 Internal Agent 有自己的 Profile 和 thread各负责一块子领域Lead 协调整个领域并充当对外的协作边界。README 里给的例子很形象一个 Product Lead 下面挂 Desktop、Web、Backend、Ops 四个 Internal Agent。这里有个容易踩的坑要提醒你Organization 关系并不会自动强制消息路由。其他 Agent 想跨域协作是走 Lead 这个边界还是直接找某个 Internal Agent取决于 Owner 选择的边界。它不替你做路由决策只是把谁对什么负责这件事显式写清楚让 Agent 能找到对的负责人而真实协作长什么样还是得看 Message 历史。这就很像真实公司汇报关系画在 org chart 上但活儿到底怎么干是邮件和会议记录说了算。把结构声明和真实证据分开是 CodexLoom 在组织建模上做得比很多框架清醒的地方。这其实就是人类组织的缩影成员有稳定职责领域变大就继续拆内部靠协作完成工作显式角色带着责任跨越组织边界。设计外部边界Interface Agent 才是正解我特别想单列讲讲它对外部边界的处理因为这是大多数多智能体方案翻车的地方。常见的错误做法是把内部 Agent 直接绑到一个外部账号上让外部用户能碰到内部 Agent 的 thread、工具、凭证。CodexLoom 的态度很明确IM 集成不是简单地绑账号而是让 Agent 组织自己设计它的外部边界。高级用户可以通过一个 Interface Agent把成熟的 Domain 能力带进飞书、Slack、Parall 这些既有的工作环境。它从一个受治理的 Conversation Membership 接收工作澄清请求和它的边界把范围明确的工作路由给负责的 Domain Agents当某个决策或承诺需要授权时再请求人工。在 Membership 策略、平台能力、真实授权都允许的情况下它把结果返回到原始对话并保留平台回执。关键点在于同一个 Agent 可以在多个平台有身份、参与多个群聊在不同渠道扮演不同角色而不必被复制成多个互不相通的 Agent。而且外部 Membership不授予外部参与者直接访问内部 Agent、Thread、工具、凭证或决策权的能力。内部路由和信息披露仍然由显式授权和信息边界治理。Interface Agent 是一个组织模式不是硬编码的 Agent 类型也不是自动网关。这一层边界是多智能体能不能安全地出门的分水岭。治理盯轨迹而不是盯参数CodexLoom 治理的是一个持续运行的组织不是一堆模型参数。它判断一个 Agent 健康与否依据的是真实工作它怎么理解输入、用哪些工具、产出什么、怎么和其他 Agent 通信、什么时候失败、重试、或需要人工介入。这些可观察的事实构成它的轨迹而不是模型隐藏的推理链。它有 Status、Daily Activity、Capacity 信号以及 token/上下文/缓存/模型用量这些可检视的数据但明确说了不把它们当绩效分、也不拿它们自动做组织决策。这点很克制也很有必要因为一旦把用量指标变成排行榜团队就会开始为指标优化而不是为真实工作优化。长期存活的 Agent 还让持续教练成为可能。维护者可以直接和一个 Agent 对话复盘一个决策纠正它对领域的理解观察后续工作有没有改善。那些应该持久的改变可以落到 Profile、关系、Conversation Memberships 上而不是只留在一次性的 prompt 里。治理也覆盖组织本身反复的协作压力会提示 Owner 去想是不是某块职责该拆了、某条关系该改了、某个外部角色需要更清晰的边界。运行时和活动证据帮你提出这些问题但不会自动评判 Agent 表现、也不会替你下组织调整的决定。我的看法我越来越觉得多智能体这条路真正的难度不在让几个 Agent 互相调用而在让一群 Agent 像一个组织那样长期、稳定、可治理地协作。CodexLoom 的聪明之处是它没有去卷更花哨的编排语法而是把长期存活的主体和受治理的责任边界当成一等公民。workflow 描述工作怎么流动CodexLoom 组织谁对什么长期负责这句话几乎可以当多智能体架构选型时的试金石。如果你正准备搭一个 Agent Team我的建议是别急着上复杂的编排框架。先用 CodexLoom 这类思路给每个 Agent 一份最小的 Profile让它在一个长 thread 里持续干活跑出真实轨迹后再决定怎么拆、怎么协作、怎么对外。一个稳定负责、可被持续教练、出门还有清晰边界的 Agent Team远比一个编排得很华丽但一上线就丢上下文、出事没人管的 Team 值得信任。最后补一句给技术负责人的招人和考核上别再用做出了多惊艳的多智能体 demo来评价产出那只会鼓励大家继续做面子工程。真正该奖励的是那些把 Agent 身份写清楚、把协作边界划明白、把组织治理跑顺的脏活。Agent 这个方向拼到后面全是苦活谁肯老老实实把组织织起来谁才能把多智能体真正用好。