yan5xu/codexloom

 # CodexLoom **一个用于长期运行 Codex Agent 的工作环境。** **English** · [简体中文](README.zh-CN.md) 赋予每个 Agent 持久的 Domain 职责，将它们组织成一个受治理的 Team，并通过 Interface Agent 向客户、社区和协作者交付成熟的能力。 对内，持续治理一个长期运行的 Agent Team。对外，在负责的 Domain Agent 于明确的身份、Conversation、授权和信息边界内完成专业工作的同时，提供统一清晰的服务窗口。 [官网](https://codexloom.ai/en/) · [中文官网](https://codexloom.ai/zh-cn/) · [Owner 指南（简体中文，权威版本）](docs/owner-guide.zh-CN.md) · [英文指南](docs/owner-guide.md) · [开始使用](#quick-start) · [社区](#community) · [文档](#documentation) ## CodexLoom 是什么 CodexLoom 构建于 Codex 之上。它没有重新实现 Agent runtime，也没有复制线程历史。相反，它将 Codex 线程转化为长期运行的 Domain Agent 的持续工作空间，并在此基础上增加了持久的身份、Profile、Team 关系、有界协调、人工治理以及受控的外部交付。 在 CodexLoom 中，Agent 拥有稳定的 ID、名称、Profile 和主 Thread。同一个 Agent 可以通过 Codex Desktop、Mobile 或 CodexLoom WebUI 恢复其当前工作。其他 Agent 通过有界的 Messages 和 Topics 进行协作，并消费显式管理的 Artifact 交接；它们不会接管该 Agent 的主 Thread。外部协作者可以通过受控的 Interface Agent，在 Feishu (Lark)、Slack 和 Parall 等现有环境中开展工作。 从一个负责持续任务的长期 Agent 开始。当重复的工作暴露出稳定的负载、上下文或专业判断边界时，Owner 可以将这项职责分配给其他 Agent，并声明它们如何协作。当团队需要参与外部组织时，Owner 可以赋予 Agent 受控的身份以及在不同对话中的不同角色。Lead、Internal Agent 和 Interface Agent 是实用的组织模式，而非硬编码的 Agent 类型。 `Loom` 这个名字描述了这一组织过程：每个线程保留其自身的历史和方向，同时职责和关系将其编织成一个更大的协作结构。 ## 你现在可以做什么 - **长期存活的 Agent：** 为每个 Agent 维护稳定的身份、可编辑的名称、主线程、Profile 和模型配置。 - **一个线程，多个界面：** 可以从 Codex Desktop、Mobile、WebUI 和 CLI 处理同一个线程，并实现实时消息和状态同步。 - **Agent 间通信：** 发送、排队和回复 Messages，同时保留送达状态、响应关系和完整历史。 - **有界协调与人工决策：** 通过 Topics 协调跨 Agent 的工作，通过 Needs You 请求 Owner 的明确决策，并通过管理的 Artifacts 交接最终文件。 - **Team 结构：** 可拖拽的 Organization、Collaboration 和 Activity 地图将正式职责、声明的跨域工作和 Message 证据区分开来；Directory 始终是每个 Agent 的精确视图。 - **概览与治理证据：** 检查当前的 Status、Daily Activity、Capacity 信号以及 token/context/cache/model 使用情况，而不将其视为绩效评分或自动的组织决策。 - **受控外部交付：** 通过 Feishu (Lark)、Slack 和 Parall 管理外部身份、Conversation Memberships、Inbox 和 Outbox，Interface Agent 充当明确的组织边界。 - **持续运营：** 运行 Schedules，通过持久的外部 Triggers 恢复现有工作，检查全局 runtime 状态，按需创建备份，并在当前活跃轮次结束后优雅重启。 Lead、Internal Agent 和 Interface Agent 目前是通过 Profiles、声明的关联、Messages 和 Conversation Memberships 来表达的。专用的分层消息策略和组织模板仍在建模中。 ## 适用人群 ### 高级个人和一人公司所有者 - 长期维护多个专业 Agent。 - 日常工作中使用 Codex 应用。 - 让负责不同领域的 Agent 直接协作。 - 将 Agent 引入他们已经在使用的工作组和社区。 - 让同事通过 Feishu 或 Slack 与受控的 Agent 协作，复用 Owner 已经开发的专业能力。 - 减少重复的回答和上下文转发，同时通过 Agent 为身边的协作者提供直接支持。 CodexLoom 目前首先服务于单个高级个人 Owner。外部协作者可以通过现有的对话与受控的 Agent 协作，但企业多租户管理和一般的公司运营并不是主要的产品方向。 ## 快速开始 CodexLoom 目前是本地优先和自托管的。要从源码启动它，请安装 `codex` CLI，登录 ChatGPT 账户，并运行： ``` make release ./bin/codex-loom ``` ### WebUI 中的 Owner 路径 打开 。如果你还在考虑什么内容值得拥有一个长期存活的 Agent，请先从[权威中文 Owner 指南](docs/owner-guide.zh-CN.md)或其[英文翻译版](docs/owner-guide.md)开始。 创建第一个简单的 Agent： 1. 选择 **New agent**。 2. 给它起一个稳定的名称以及它所需的工作目录。 3. 打开它的工作区，并发送一个来自它将要持续负责领域的真实任务。 4. 在 Agent Inspector 中使用 **Profile** 记录最小可用的 Identity、Domain 和 Scope。在观察实际工作后再对它们进行完善，而不是一开始就设计一个完整的组织结构。 ### CLI 等效操作 同样的初始设置可以通过本地 CLI 执行： ``` ./bin/loom agent create research --cwd /path/to/repo ./bin/loom profile set research \ --identity "Long-term researcher for this domain" \ --domain "Continuously research the relevant products, protocols, and implementations" \ --scope "Answer domain questions, preserve conclusions, and advise related agents" ./bin/loom thread send research "Establish a baseline for the current state of this domain" ``` ## 为什么需要长期存活的 Domain Agent ### Task Agent 从任务开始 代码 Agent 通常围绕任务进行组织：创建线程、提供目标和背景、交付结果，然后结束协作。该线程可能已经包含了项目上下文、约束、工具使用情况和先前的决策，这些对下一步的工作非常有价值。然而，下一个相关任务通常在一个新线程中开始，迫使用户重述背景、恢复先前的决策并重建工作上下文。每个任务都要再次承担冷启动成本。 CodexLoom 做出了不同的选择：一个线程在一项任务结束后应该继续承载工作。同一领域的后续任务会回到该线程并重用它所积累的内容。Profile 为 Agent 提供了持久的领域、职责和边界。线程不再是单个任务的记录，而是成为了 Domain Agent 的持续工作空间。 | | Task Agent | Domain Agent | |---|---|---| | 创建围绕 | 单个任务 | 长期存活的领域 | | 线程生命周期 | 交付后被放弃或替换 | 继续接收同一领域的工作 | | 下一个任务 | 重新引入背景并重建上下文 | 从现有上下文和轨迹继续 | | 职责 | 完成当前任务 | 对该领域保持负责 | ### 重建上下文也有成本 关于长生命周期线程的一个常见担忧是，上下文窗口是有限的，较长的历史可能会使每个任务变慢或成本更高。这种担忧是真实的，但它只计算了保留上下文的成本，而没有计算重建上下文的成本。新线程仍然需要相关的背景、约束和先前的决策才能达到相同的工作状态。重用线程还可以让其稳定的历史前缀受益于 prompt caching，而不是重复从头处理相同的上下文。 ### Compaction 保持连续性 Compaction 不会将上下文重置为零。在较早的历史被压缩后，其摘要和最近的轨迹仍然保留了大量的工作信息。长生命周期线程不要求每条原始消息无限制地增长；其上下文可以通过缓存和压缩来演变。Compaction 是维持连续性的机制，而不是放弃线程的理由。 CodexLoom 并不将摘要视为持久声明的唯一保证。在压缩后的下一个 Turn 中，新的上下文 epoch 会重新覆盖当前的 Loom Agent Prompt、完整的 Agent Profile 和直接关系快照。只有在存在可重放的 rollout 证据和同一 Turn 中的模型事件之后，修订才会被标记为 `covered`。参见 [Epoch Context Coverage](docs/epoch-context-coverage.md)。 长生命周期的线程还会积累难以在单个 prompt 中重建的隐性上下文。纠正、偏好、术语、判断和协作习惯通过重复的工作进入线程，并在连续的压缩中得到提炼。它们可能不适合作为 Profile 中的单独规则，但它们共同创造了该 Agent 独有的工作理解。开启一个新线程恰恰会丢失这些最难显式迁移的知识。 任务仍然存在于 Domain Agent 模型中，但它们变成了工作单元，而不是身份或生命周期的定义。Agent 可以在任务之间保持空闲，之后仍然可以从它已经学到的内容中继续。 ## Profile 和 Thread CodexLoom 将 Agent 视为一个持久的、长期存活的主体。它的 Profile 定义了 Agent 是谁、它持续负责什么以及它的边界在哪里。Domain 可以是一个项目、子系统、专业能力、客户或业务领域。 线程承载了发生时的交互、决策、工具调用、Artifacts 和反馈，随着时间推移形成了 Agent 的工作轨迹。Profile 提供稳定的方向；线程保留积累的工作，以便未来的任务可以从现有的上下文继续。 Profile 还向其他 Agent 公开了协作信息。它声明了 Agent 拥有什么，哪些问题应该直接向它提出，以及哪些工作超出了它的边界。它既是 Agent 的持久上下文，也是组织的可发现性和协作契约。 ## 从 Domain Agent 到组织 当 Agent 对不同的领域持续负责时，它们的关系就不再是一次性的调用链，而是变成了持续协作。跨越领域边界的工作需要找到负责的 Agent，询问它的判断，请求帮助，并报告在使用其所属物时发现的问题。 Organization Map 呈现了持久的父/子职责边界。Collaboration Map 记录声明的跨域工作关系，而不是假装它们是层级结构。Activity Map 从 Messages 推导出有明确时间范围的证据，而 Directory 始终是精确的清单。声明的结构帮助 Agent 找到合适的 Owner；消息历史展示了该结构在实际工作中是如何运作的。 ### 跨域通信 当一个 Agent 使用由另一个 Agent 维护的工具时，它可以询问所有者如何使用它或直接报告故障。如果接收方正忙，消息会一直等待，直到其当前轮次结束。问题、判断和结果通过回复保持关联。`loom` CLI 提供发现、送达、排队、回复和状态检查功能，而 Messages 记录了由此产生的跨域协作。 ### Internal Agents 当一个领域变得太大时，其 Owner 可以成为 Lead，并将稳定的子领域委托给 Internal Agents。每个 Internal Agent 都有自己的 Profile 和线程，并持续负责一个子领域。Lead 协调整个领域，并充当该团队的公共协作边界。 ``` Product Lead ├── Desktop Internal Agent ├── Web Internal Agent ├── Backend Internal Agent └── Ops Internal Agent ``` 人工维护者可以直接与任何 Internal Agent 交互。当 Owner 选择了该边界时，其他 Agent 可以通过 Lead 进行协作，但 Organization 关系不会自动强制执行消息路由。 这类似于人类组织：成员拥有稳定的职责，不断增长的领域会被进一步划分，内部工作通过协作完成，而明确的角色跨组织边界承担责任。 ## 设计外部边界 高级用户可以通过 Interface Agent 将成熟的领域能力引入到现有的工作环境中。它接收来自受控 Conversation Membership 的工作，明确请求及其边界，将划定范围的工作路由给负责的 Domain Agents，并在决策或承诺需要时请求人工授权。当 Membership 策略、提供商能力和实际授权允许时，它将结果返回到原始 Conversation 并保留提供商回执。 ``` Feishu (Lark) / Slack / Parall <-> Interface Agent <-> Domain Agent Team ``` 一个 Agent 可以在多个平台上拥有身份，并参与多个群组对话。外部身份声明了可以在哪里访问到该 Agent。Conversation Membership 定义了它在特定对话中的角色：需要关注什么、何时发言、绝对不能披露什么，以及何时必须咨询内部 Owner。因此，同一个 Agent 可以在不同的频道中扮演不同的角色，而无需被复制成分离的、互不相干的 Agent。 Interface Agent 是一种组织模式，而不是硬编码的 Agent 类型或自动网关。外部 Membership 不会授予外部参与者直接访问内部 Agents、Threads、工具、凭证或决策权的权限。内部路由和披露仍然受到明确授权和信息边界的约束。 | 状态 | 平台 | |---|---| | 可用 | Feishu (Lark), Slack, Parall | | TODO | Microsoft Teams | ## 在人们已经工作的地方工作 CodexLoom 不要求每个参与者都转移到新的聊天界面。同一个 Agent 仍然可以通过不同的界面访问，同时保留其身份和线程的连续性。 | 参与者 | 界面 | 目的 | |---|---|---| | 日常用户 | Codex Desktop / Mobile | 跨设备继续与 Agent 及其线程协同工作 | | Agent 维护者 | CodexLoom WebUI | 使用 Agent 并管理 Profiles、关系、外部界面和 runtime 状态 | | 其他 Agent | `loom` CLI | 发现领域 Owner、发送和回复消息，并检查送达状态 | | 外部协作者 | 外部 IM | 从他们已经在使用的工作环境中使用 Agent | ## 管理 Agent 组织 CodexLoom 管理的是一个持续运行的 Agent 组织，而不是一堆模型参数。Agent 的健康状况必须从实际工作中来评估：它如何解释输入、使用哪些工具、产出了什么、如何与其他 Agent 通信，以及它何时失败、重试或需要人工干预。这些可观察的事实构成了它的轨迹；它们不是模型隐藏的思维链。 长期存活的 Agent 也使持续的辅导成为可能。维护者可以直接与 Agent 交谈，审查一项决策，纠正领域的理解，并观察后续工作是否有所改善。应该持久化的更改可以应用到 Profiles、关系和 Conversation Memberships 中，而不是停留在一次性的 prompt 里。 治理包括组织本身。反复出现的压力可以促使 Owner 调查是否应该划分职责、改变关系，或者外部角色是否需要更清晰的边界。Runtime 和活动证据有助于提出这些问题；它们不会自动判断 Agent 性能或强制规定组织变更。 对于高级个人而言，这是一组可以随着时间推移进行协作并参与到现有工作环境中的 Agent 伙伴。CodexLoom 帮助 Owner 组织这些 Agent；它不会成为 Owner 公司的 CRM、ERP、项目管理系统或操作系统。 ## 产品边界 CodexLoom 构建于 Codex 之上。Codex 继续提供 Agent runtime、线程历史记录以及诸如 Desktop 和 Mobile 的日常客户端。CodexLoom 提供持久的 Agent 身份、长期职责、组织通信、外部边界和治理。任务和工作流仍然可以在 Agent 内部运行，但它们不是 CodexLoom 治理的主要对象。 ## License CodexLoom 是在 [Elastic License 2.0 (ELv2)](LICENSE) 下提供源代码的。根据开源促进会 (OSI) 的定义，它不属于开源软件。 版权所有 2026 yan5xu。第三方依赖项和组件仍受其各自的许可条款和版权声明约束。 ## 文档 - [Owner 指南（简体中文，权威版本）](docs/owner-guide.zh-CN.md) - [Owner 指南（英文翻译版）](docs/owner-guide.md) - [文档地图（简体中文，权威版本）](docs/README.zh-CN.md) - [文档地图（英文翻译版）](docs/README.md) - [Agent Profiles：定义长期的身份、领域和范围](docs/agent-profile.md) - [Agent 通信与 `loom` CLI](docs/loom-cli.md) - [内置 Skills 和 Codex 发现](docs/skills.md) - [Topics：跨越 Turns、时间和 Agents 的有界协调](docs/topics.md) - [外部条件与 GitHub Triggers](docs/triggers.md) - [外部平台集成设计](docs/agent-platform-integration.md) - [设置 Feishu、Slack 和 Parall 集成](docs/integrations.md) - [Conversation Membership：Agent 在特定对话中的角色](docs/conversation-membership.md) - [Codex app-server 协议和适配器说明](docs/codex-app-server-protocol.md) - [架构、数据流、API、迁移和开发手册](docs/handbook.md) ## 项目状态 CodexLoom 是一个 Codex 原生、本地优先、自托管的项目，目前正处于积极开发中。诸如 Remote 等功能依赖于实验性的 Codex API，其接口和后端行为可能会随着 Codex 的版本发布而改变。有关当前的限制和兼容性策略，请参见[开发手册](docs/handbook.md#已知限制)。 CodexLoom 是构建于 Codex 之上的独立项目。它不隶属于 OpenAI，也不受其认可。

标签：AI智能体, EVTX分析, LLM应用框架, SOC Prime, 人工智能, 任务编排, 协同工作, 开发工具, 文档结构分析, 用户模式Hook绕过