OrgX

快速结论

OrgX 适合已经在多个 AI 客户端之间协作、希望共享组织记忆和执行状态的团队。它通过托管 MCP 把决策、项目、任务、产物、审批和 agent 活动放进同一个 OrgX 工作区，再让 Claude、ChatGPT、Cursor 等客户端通过 OAuth 读取或写入。2026-07-21 可见的线上服务版本为 1.1.1，定位不是个人笔记，而是带身份、权限和副作用的组织数据层。

需要先划清两个误区。第一，公开 GitHub 仓库不等于开源软件：仓库明确写着 worker 许可仍为 TBD，没有可依赖的 LICENSE，因此不能把 OrgX MCP worker 标为 OSS，也不应在获得条款前复制、修改或再分发。第二，OAuth 只解决“谁连接、授予哪些范围”，不能自动证明每次写入、模型调用、计费或遥测都符合你的内部政策。OrgX 值得试用，但应从只读记忆场景开始，再按工具和工作区逐步开放写能力。

核心功能

• 组织记忆：跨客户端搜索决策、产物、任务、项目上下文和历史活动，不必每次重新贴背景。
• 工作状态读取：查看 initiative 健康度、里程碑、阻塞项、待审批决定、agent 状态和运营摘要。
• 结构化写入：创建或更新组织记录，附加链接、文档、截图或其他证据，并把计划挂到具体实体。
• 决策与审批：记录决定、列出待审批项，并执行批准或拒绝；这些动作会改变持久化组织状态。
• agent 编排：分类、派发、暂停、完成或验证任务，可让专业 agent 继续处理工作。
• 托管身份：线上 MCP 通过 OAuth 2.1、PKCE 和动态客户端注册连接 OrgX 账号与工作区。
• MCP Apps 小组件：兼容客户端可渲染决策、项目状态、任务和运营视图；不兼容客户端仍接收结构化结果。
• 线上 1.1.1：当前服务持续发布，接入前应核对线上发现元数据、工具契约和变更记录，而不是只看旧截图或目录缓存。

适合人群

• 同时使用多个 MCP 客户端，反复丢失项目上下文的创始团队和跨职能小组。
• 需要把决策、证据、负责人、审批和执行状态放在一起的运营团队。
• 能配置 OAuth 范围、数据分类、人工审批和供应商评估的组织。
• 想先试组织记忆，再逐步启用计划、写入和 agent 派发的人。
• 不适合要求离线自托管、必须使用明确开源许可，或无法接受组织数据进入第三方托管边界的团队。

使用场景

最稳妥的起点是只读查询：让一个测试工作区保存非敏感的项目摘要和决定，再从两个不同客户端查询，观察检索准确性、权限隔离和日志内容。确认边界后，可以开放创建任务、附加产物或记录决定。批准、拒绝、删除、派发 agent、启动执行和升级账号属于高影响操作，应让客户端在调用前显示目标工作区、对象、预计副作用和费用上限。

OrgX 的真正价值来自跨会话连续性，但同一机制也会扩大数据范围。聊天内容、附件指针、代码或业务产物一旦写入组织记忆，之后可能被别的获权客户端检索。所有检索到的组织内容都应保留来源并视为不可信输入：持久化文本可能形成跨会话提示注入或记忆投毒，其中的指令不能授权工具、批准操作或扩大用户确认的工作流。接入设计要区分个人内容、团队内容和禁止外发内容；敏感字段不要只靠提示词隐藏。若任务允许模型自动路由，还应记录实际模型供应商、模型、输入分类、输出去向和单次预算，避免“由系统自动选择”变成不可审计的空白。

价格与版本

公开页面展示平台入口和账单相关工具，但没有足够稳定、完整的公开价目可支撑精确套餐结论。结合账号、工作区、用量和升级路径，本页将其标为“免费增值”，这是审慎分类，不代表所有核心能力永久免费。采购前应在实际账号中核对免费额度、席位、agent 执行、模型调用、存储、账单周期、退款和企业条款。

当前线上版本为 1.1.1。版本号说明服务在迭代，不代表代码许可已经解决。GitHub worker 仓库的许可仍为 TBD，所以“可查看源码”“可连接托管端点”和“可按开源许可证使用”是三件不同的事。企业评估应把许可确认和服务合同分开完成。

国内访问与使用体验

OrgX 是托管服务，体验取决于 OrgX、OAuth 登录页、Cloudflare Workers、所用 AI 客户端和被选模型供应商的共同可用性。首次授权应认真阅读 scope，并确认绑定的是测试工作区而非正式组织。OAuth 客户端凭据和会话状态由 Cloudflare Durable Objects 等托管组件处理；OrgX worker 还会与 OrgX API、身份系统、数据存储及账单系统交互。

中文项目名、决策和产物可以进入组织记忆，但检索效果、摘要质量和专业 agent 输出仍要用真实样本验证。不要因为客户端显示一个统一的 OrgX 工具名，就把后面的处理者视为单一系统。至少应画出六条边界：OAuth 身份、Cloudflare 运行时、OrgX 持久数据、写操作、模型供应商与调用费用、活动遥测。对每条边界分别确认保留期、删除方式、访问主体和审计出口。

优点

• 组织记忆围绕决定、产物、任务和负责人组织，比纯个人记忆更适合团队协作。
• 一个托管 MCP 可服务多个客户端，减少重复配置和手工搬运上下文。
• 读取、计划、决策、写入和 agent 派发使用结构化工具，便于设计审批规则。
• OAuth 2.1 与 PKCE 比共享静态密钥更适合终端用户授权。
• MCP Apps 小组件能让审批和项目状态比纯文本返回更容易检查。
• 1.1.1 线上版本活跃，官方仓库公开了工具契约和安全数据处理文档，便于做初步审查。

不足

• worker 仓库没有已确定许可证，明确标注 TBD，不能当作 OSS 使用。
• 托管架构把身份、运行时、组织数据和账单放进多个第三方服务边界。
• 写入、批准、拒绝、删除和派发任务会产生真实副作用，权限开大后误操作成本高。
• 自动模型路由可能涉及不同供应商、质量、数据条款和费用，需要单独记录与限制。
• 活动回执和执行遥测有助于审计，也会增加被保存的行为数据，应确认保留和删除政策。
• 免费增值分类仍需账号内价格验证，不能据此编制长期预算。
• 工具和实体较多，团队需要定义命名、归档、去重与权限规范，否则组织记忆会快速变乱。

替代品对比

常见问题 FAQ

OrgX MCP 是开源软件吗？

不能这样认定。虽然源码仓库公开，但仓库写明 worker 许可证为 TBD，且没有确定的许可证文件。查看源码不自动授予复制、修改或再分发权利。

OrgX 当前版本是多少？

截至 2026-07-21，线上服务版本为 1.1.1。接入时仍应读取线上发现元数据，因为目录缓存和仓库 release 页面可能滞后。

为什么建议先启用只读能力？

搜索和查看状态便于验证工作区隔离与结果质量；批准、拒绝、写入、删除和派发 agent 会改变组织记录或触发执行。先读后写能缩小首次授权的风险面。

OAuth 是否意味着组织数据不会被其他系统处理？

不是。OAuth 管理授权，但请求仍经过 Cloudflare 运行时和 OrgX 服务；agent 任务还可能调用模型供应商，账单和活动记录也有各自的数据路径。需要逐项确认这些边界。

OrgX 是免费的吗？

本页按“免费增值”分类，因为服务有进入和升级路径，但公开信息不足以保证具体免费额度。请在账号内核对席位、模型、执行、存储和企业功能的实时价格。

总结

OrgX 把 MCP 从“调用一个工具”扩展成带身份、组织记忆和执行状态的团队层，适合解决多客户端之间的上下文断裂。评估时不要只看工具数量：先确认 TBD 许可意味着它不是 OSS，再用测试工作区检查 OAuth scope、Cloudflare 路径、组织数据、写操作、模型和费用、活动遥测六个边界。只读试点通过后，再为每一类副作用设置明确授权，OrgX 才可能成为可控的团队基础设施。