LoopX overall roadmap: long-running multi-Agent collaboration / LoopX 整体路线总纲

[huangruiteng]

LoopX 的整体方向 / Where LoopX is going

我们希望一个人能通过本地前端或 Lark 提出、修订和验收复杂目标，让持久管家协调多个长程 LoopX Agent，在本地 managed 与云端 runtime 上持续完成工作。每个 Agent 保有明确的目标、承诺与执行边界；管家组织、委托和综合，peer 之间也能直接求助、交接产物和独立复核。

LoopX should let a person express, revise and accept complex goals through the local frontend or Lark, while a persistent steward coordinates long-running LoopX Agents across local managed and cloud runtimes. Agents retain explicit commitments and execution boundaries. The steward organizes and synthesizes; peers can directly request help, hand off artifacts and review work.

Read the overall roadmap: 中文 · English

Execution tracker: #4574 — LoopX overall delivery program. The roadmap was merged in #4570.

一份总纲，覆盖完整产品 / One roadmap for the whole product

总纲连接原有 30 个主 RFC、13 条工作流、6 个产品组合里程碑和 7 张核心执行卡，并纳入 RFC 外的重要领域：

• 产品与持久管家、目标规划、multi-LoopX-Agent 协作和 handoff；
• typed TS 内核、shared authority、本地 managed/attached 与云端 host；
• frontend/Lark、人机判断、材料/证据/记忆、预算/成本/调度；
• 能力与扩展、身份/权限/隐私、可靠性诊断与运营；
• 科学研究与评测、安装发布/开发体验/社区治理、采用与商业可持续性。

The roadmap connects all 30 pre-existing primary RFCs, 13 streams, 6 portfolio milestones and 7 core execution cards. It covers product/steward work, planning and peer collaboration; TS and shared authority; managed/attached/cloud hosts; frontend/Lark; materials, memory, budgets and scheduling; extensions, trust and operations; research, releases, developer/community experience and sustainable adoption.

协作能力如何证明 / What counts as collaboration

多 Agent 能力需要证明具体的工作关系：

1. 并行汇合： 多个分支产物经过验收后进入集成；失败分支不能变成整体成功。
2. 流水线交接： 下游消费上游的已验收、带版本产物；可以拒绝不完整输入并请求补充。
3. 同伴求助/复核： worker→worker 协作保留各自承诺和受众边界，不要求管家转发每条消息。
4. 执行责任接续： 上下文交接与 claim/lease 转移分开；旧 worker 回归不能重复提交。
5. 跨主机恢复： 断网、来源会话消失、重复投递和权限撤销后，结果与回报义务仍可对账。

Collaboration must prove parallel joins, versioned pipeline handoff, peer help/review, fenced execution-responsibility continuation and cross-host recovery. Message receipt, work adoption, effect commit, result acceptance and answer delivery are different facts. A directory, team card or a hundred registrations does not establish a working long-running team.

推进顺序 / Delivery order

可信基线 → 2–3 Agent 真实小团队 → 可恢复协作工作台 → 本地/云端共同工作 → 10/30/100+ 活跃 cohort 资格。

Trustworthy baseline → real 2–3-Agent team → recoverable workspace → local/cloud collaboration → qualified 10/30/100+ active cohorts.

最早的小团队里程碑就要求真实 peer handoff、依赖产物、至少两轮推进、故障恢复、用户补充与独立验收。百 Agent 是后续系统资格，不是先提高一个数量上限。成本、吞吐、恢复、人工介入和成果质量需要固定口径与完整失败分母。

The first team milestone already requires real peer handoff, dependent artifacts, two work cycles, recovery, owner correction and independent acceptance. Scale follows evidence rather than a larger cap. Measure cost, throughput, recovery, attention and accepted outcomes with fixed definitions and complete failure denominators.

采用路线也可以独立推进：已有 agent 系统先接入 L1 被动诊断 → L2 建议 → 经授权的 L3 seam → 可选 L4 控制面。它不必等待百 Agent；每次增加控制权都需要独立证据与授权。

Existing systems can adopt independently through L1 passive diagnostics → L2 advice → authorized L3 seams → optional L4 control-plane adoption. This need not wait for hundred-Agent scale; each authority increase needs its own evidence and authorization.

参与讨论与贡献 / How to participate

欢迎围绕以下问题给出可公开或合成的案例：

• 你的长程工作最常在哪里丢失上下文、卡在依赖或需要人工接续？
• 哪种 peer 协作关系最先有价值，什么结果才算完成？
• 本地 frontend、Lark、managed 或已有 host 的采用阻力是什么？
• 你能提供哪种可复现的故障、adapter、验证或真实用户旅程？

Share public-safe or synthetic examples of continuity failures, dependency stalls, valuable peer relationships, acceptance criteria, adoption friction, reproducible faults or adapter/user-journey contributions. Please exclude private transcripts, credentials and organizational context.

请先查看 执行总跟踪 #4574 及其已有领域 Issue；具体实现用有界 Issue/PR 跟踪，方向与取舍在这里讨论。现有技术方向讨论、管家与 handoff 讨论 和前沿研究讨论 继续作为相关领域入口。

Use bounded issues/PRs for implementation and this discussion for portfolio tradeoffs. The existing technical-directions, manager/handoff and frontier-research discussions remain useful domain entrypoints.

总纲合并意味着方向与执行路径可发现，不意味着所有 RFC 已接受、功能已交付、provider 已晋升或商业模式已验证。仓库总纲是当前计划来源；领域合同保留权威，实际 Todo/Issue/PR 保存执行证据。

Merging the roadmap makes direction and execution paths discoverable. It does not mean every RFC is accepted, every capability shipped, providers promoted or product-market fit established. Repository plans, domain authority and actual execution evidence remain separate.