From affd7dd3efcf2c98a526c8d54fa58c6f6cfcbe98 Mon Sep 17 00:00:00 2001 From: huangruiteng <14976749+huangruiteng@users.noreply.github.com> Date: Fri, 18 Sep 2026 11:58:05 +0800 Subject: [PATCH] docs(rfcs): align autonomous managed teams and continuation ownership Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com> --- .../agent-im-openviking-collaboration-v0.md | 15 +++++ .../rfcs/agent-session-execution-modes-v0.md | 59 ++++++++++++++++++- .../agent-session-execution-modes-v0.zh-CN.md | 48 ++++++++++++++- .../capable-manager-semantic-handoff-v0.md | 34 +++++++++++ ...pable-manager-semantic-handoff-v0.zh-CN.md | 24 ++++++++ .../rfcs/desktop-execution-frontends-v0.md | 57 ++++++++++++++---- .../desktop-execution-frontends-v0.zh-CN.md | 42 ++++++++++--- .../rfcs/harness-selection-dsh-pi-v0.md | 35 +++++++++++ .../rfcs/harness-selection-dsh-pi-v0.zh-CN.md | 27 +++++++++ .../rfcs/loopx-overall-roadmap-v0.md | 35 ++++++++++- .../rfcs/loopx-overall-roadmap-v0.zh-CN.md | 25 +++++++- ...shared-goal-authority-state-provider-v0.md | 15 +++++ ...-goal-authority-state-provider-v0.zh-CN.md | 11 ++++ .../rfcs/single-owner-local-daemon-v0.md | 11 ++++ 14 files changed, 415 insertions(+), 23 deletions(-) diff --git a/docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md b/docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md index f5f0e70f8f..adacd9acbb 100644 --- a/docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md +++ b/docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md @@ -112,6 +112,21 @@ Both ingress paths use the same transition contract: - command-specific evidence; - an accepted, rejected, conflict, or already-applied receipt. +Use the [shared ingress policies](desktop-execution-frontends-v0.md#agent-scoped-bot-ingress-modes) +for Agent messages as well as human-origin events: inbox persists for explicit +drain, queue schedules subsequent input, and steer targets a supported safe +point in the active execution. Preserve requested/effective mode, dedupe and +consumption readback; an IM acknowledgement is not work adoption. Pending tools +do not permit fabricated results or silent interrupt-as-steer fallback. + +The [session RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership) +owns creation/attachment and one continuation owner per binding. Any authorized +peer may coordinate another level through the handoff contract; IM topology +grants neither extra permission nor a fresh team budget. A scoped facade to one +supported local authority can precede shared-service deployment; it is not +independent multi-host authority qualification. The direct Agent work path and +the three-plane ownership model above remain unchanged. + ## Projection Contract An IM room may display a compact projection such as: diff --git a/docs/architecture/rfcs/agent-session-execution-modes-v0.md b/docs/architecture/rfcs/agent-session-execution-modes-v0.md index 7195d557c5..92608c3f1b 100644 --- a/docs/architecture/rfcs/agent-session-execution-modes-v0.md +++ b/docs/architecture/rfcs/agent-session-execution-modes-v0.md @@ -221,6 +221,54 @@ monitor, or lifecycle truth; conversation text as a receipt; a second scheduler for the same binding; a Goal-wide default binding; and a mode change inferred from a probe, a transport, or a prompt. +### Reusable Agent operations and continuation ownership + +This proposed extension refines the managed-team delivery contract; it does not +add CLI flags, promote a host, or change existing session/profile defaults. +Keep three identities separate: the registered Agent, its current host session +and execution generation, and each work request/attempt. Creating an Agent is +not starting a process, attaching a session is not claiming work, and a returned +artifact is not accepted work. + +| Operation family | Existing owner to reuse | Required observation | +| --- | --- | --- | +| Discover/create/reuse an Agent | Registry, directory, onboarding and configured execution profile | Stable Agent identity, effective scope and supported capabilities; repeated creation does not duplicate the identity | +| Attach/start/resume/stop | This RFC's binding and the selected host adapter | Exact session/generation, actual running or blocked state, cancellation and replacement readback; attached hosts never acquire a substitute executor | +| Send/receive/return | Collaboration request owner and the [ingress policies](desktop-execution-frontends-v0.md#agent-scoped-bot-ingress-modes) | Requested/effective inbox, queue or steer semantics; delivery, consumption and work adoption remain distinct | +| Claim/validate/settle | Existing Todo, lease, acceptance and quota owners | Current execution proof and independent acceptance; a host cannot certify its own completion | + +These are semantic operation families, not a new universal adapter API. Both a +lead Agent and an authorized managed worker may call them. Host lifecycle +differences remain explicit; a coordination role grants no extra authority. + +**Continuation ownership is a separate axis from session mode and provider.** +Each binding has one qualified owner of the next execution opportunity: + +- **LoopX-governed Turn:** the existing runtime/scheduler admits a complete + bounded work unit; the host runs its own model/tool loop and returns a typed + candidate for independent validation and settlement. Local and cloud hosts + may implement the same contract. A Turn is not one model call or a scripted + business phase; the Agent may investigate, delegate and revise within scope. +- **Native Goal runtime:** submit one Goal/task body and let that runtime own + continuation, with qualified handling of LoopX continue/defer/complete, + cancellation, budget and result readback. A prompt alone is not a scheduler; + provider Goal evaluation does not replace LoopX work acceptance. +- **Same-session host driver:** an explicitly activated host integration can + obtain fresh LoopX admission and enqueue the next task in the existing + session. Qualify this separately from a provider's native Goal evaluator. + +Never wrap a self-continuing native Goal in repeated externally driven Turns on +the same binding. To change the continuation owner, stop new admission, reconcile +pending tools and uncertain effects, fence the old executor, and read back the +new binding before execution. Disconnection does not authorize that switch. + +For the first mixed managed cohort, qualify a cloud adapter against the same +governed Turn contract as the local worker before expanding native Goal profiles. +This is a delivery priority, not a default migration. The +[harness selection RFC](harness-selection-dsh-pi-v0.md) owns provider qualification. +Reuse the existing profile editor and session projections; do not add a +manager-only creation service, task ledger or scheduling loop. + ### State model and schema The binding is the unit of mode ownership. Its canonical fields: @@ -307,11 +355,12 @@ it may not claim an executing session binding. ### Capability and delivery-mode orthogonality -Five axes that are frequently confused, each with one owner: +Six axes that are frequently confused, each with one owner: | Axis | Values | Owner | | --- | --- | --- | | Execution mode | `managed_runtime`, `attached_host` | This RFC | +| Continuation owner (proposed) | LoopX Turn driver, native Goal runtime, same-session host driver | This RFC; qualification per selected profile, never inferred from provider or location | | Transport | web chat, Lark, CLI | Desktop frontends RFC; transports never change mode | | Event source | group message, document comment, monitor observation, inbound file | Connector and collaboration contracts | | Ingress/delivery mode | `live_steering`, `session_queue`, `async_inbox` | Desktop frontends RFC, gated per binding | @@ -433,6 +482,14 @@ future evidence and must not be reported as green. Deterministic package tests are not sufficient for admission. A new host needs at least one real-host row: a live process, a real bind, and a real restart. +The proposed continuation extension also requires an installed local/cloud pair +to use the same admission/result/independent-validation contract, a managed +worker to request and adopt another worker's artifact, and a driver-switch race +to reject the old executor. Test ordinary waiting, pending tools, budget +exhaustion and native Goal defer/terminal handling separately. None of these +rows is qualified by registration, HTTP acknowledgement or a fixed phase script. +Preserve feature-off behavior for every existing profile and entrypoint. + ## 11. Operational contract - **Observability.** Session readback exposes mode, host surface, executor diff --git a/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md b/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md index b0885874e7..3a642cc219 100644 --- a/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md +++ b/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md @@ -176,6 +176,46 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一 对话文本作为回执；同一绑定上的第二个调度器；Goal 级默认绑定；以及从探测、传输或 提示词推断出的模式变更。 + + +### 可复用的 Agent 操作与续跑归属 + +本提案细化 managed 团队的交付契约，不新增 CLI 参数、不晋升宿主，也不改变现有 +会话/profile 默认。区分三组身份：已注册 Agent、其当前宿主会话与执行代际、每次工作 +请求/尝试。创建 Agent 不等于启动进程，挂接会话不等于领取工作，返回产物不等于工作验收。 + +| 操作族 | 复用的现有 owner | 必须读回的事实 | +| --- | --- | --- | +| 发现/创建/复用 Agent | Registry、directory、onboarding 和配置的 execution profile | 稳定 Agent 身份、生效范围和支持能力；重复创建不产生第二身份 | +| 挂接/启动/恢复/停止 | 本 RFC 的 binding 与选定 host adapter | 精确会话/代际、实际执行或阻塞、取消和替换读回；attached host 不获得替身执行器 | +| 发送/接收/返回 | Collaboration request owner 与[入口策略](desktop-execution-frontends-v0.zh-CN.md#agent-scoped-bot-ingress-modes) | 请求/实际 inbox、queue、steer 语义；投递、消费、工作采用仍是不同事实 | +| 领取/验证/结算 | 既有 Todo、lease、acceptance、quota owner | 当前执行 proof 与独立验收；宿主不能自行证明工作完成 | + +这些是语义操作族，不是新增的万能 adapter API。主 Agent 和获授权的 managed worker +都可调用；宿主生命周期差异保持显式，协调角色不增加权限。 + +**续跑归属是独立于 session mode 和 provider 的轴。** 每个 binding 只有一个经过 +资格化的下一执行机会 owner： + +- **LoopX 受控 Turn：** 既有 runtime/scheduler 准入一次完整的有界工作；宿主运行 + 自己的模型/工具循环，返回 typed candidate，经独立验证后结算。本地和云端宿主可 + 实现同一合同。Turn 不是一次模型调用或脚本业务 phase；Agent 可在范围内调查、 + 委派和修订。 +- **原生 Goal runtime：** 一次提交 Goal/task body，由该 runtime 拥有续跑；必须 + 验证其处理 LoopX continue/defer/complete、取消、预算和结果读回。Prompt 本身 + 不是调度器，provider Goal 自评不替代 LoopX 工作验收。 +- **同会话 host driver：** 显式激活的宿主集成可取得新鲜 LoopX 准入，将下一任务排入 + 原会话。它与 provider 原生 Goal evaluator 分别资格化。 + +禁止在同一 binding 上，一边重复外部受控 Turn，一边包裹会自行续跑的原生 Goal。 +更换续跑 owner 前，停止新增准入、对账未决工具和不确定副作用、fence 旧执行器， +再读回新绑定后执行；断连不授权该切换。 + +首个混合 managed cohort 优先让云端 adapter 与本地 worker 通过同一 governed Turn +合同，再扩展 native Goal profile。这是交付优先级，不是默认迁移；provider 资格由 +[harness 选型 RFC](harness-selection-dsh-pi-v0.zh-CN.md)负责。复用现有 profile editor +和会话投影，不新建管家专属创建服务、任务账本或调度循环。 + ### 状态模型与 schema 绑定是模式归属的单元。其规范字段： @@ -242,11 +282,12 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一 ### 能力与投递模式的正交性 -经常被混淆的五个轴，每个轴有唯一属主： +经常被混淆的六个轴，每个轴有唯一属主： | 轴 | 取值 | 属主 | |---|---|---| | 执行模式 | `managed_runtime`、`attached_host` | 本 RFC | +| 续跑 owner（提案） | LoopX Turn driver、原生 Goal runtime、同会话 host driver | 本 RFC；按选定 profile 验证，不从 provider 或部署位置推断 | | 传输 | web chat、Lark、CLI | 桌面执行前端 RFC；传输绝不改变模式 | | 事件源 | 群消息、文档评论、monitor 观察、入站文件 | 连接器与协作契约 | | 入口/投递模式 | `live_steering`、`session_queue`、`async_inbox` | 桌面执行前端 RFC，按绑定门控 | @@ -349,6 +390,11 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一 确定性的包测试不足以支撑接入。新宿主至少需要一条真实宿主行：一个真实进程、一次真实 绑定、一次真实重启。 +续跑扩展还要求：已安装的本地/云端组合使用同一准入/结果/独立验证合同；普通 managed +worker 请求并采用另一 worker 的产物；driver 切换竞态拒绝旧执行器。普通等待、未决 +工具、预算耗尽、native Goal defer/终态处理分别验证。注册、HTTP ACK 或固定 phase +脚本都不能满足这些尚未资格化的项目；每个现有 profile 和入口保持 feature-off 行为。 + ## 11. 运维契约 - **可观测性。** 会话回读暴露模式、宿主面、执行器端点、能力、状态、活跃 turn 与稳定 diff --git a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md index 708f7dbbeb..cead56ee5a 100644 --- a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md +++ b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md @@ -152,6 +152,14 @@ The durable semantic context consists of a small typed identity/control header p Prefer one cohesive replacement to compatibility wrappers that preserve duplicate decisions. Inventory every existing producer/reader, migrate with lossless mappings, switch one writer and delete the replaced rules. Reusing contracts and data is required; reusing every current class, JSON directory and prompt is not. +The lead Agent owns task decomposition, investigation, delegation, revision and +synthesis. Host services execute admitted operations and recover their receipts; +they do not encode the scenario's next business phase. A managed worker may +coordinate other Agents through the same scoped creation, session and request +operations defined by the [session execution RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership). +Keep the manager application thin and shared state transitions in their typed +owners. Do not build a second scheduler in the manager or provider adapter. + ### 5.3 Authority that enables work Resolve a request from authenticated principal, origin/audience, resource scope and requested effect, then match the existing persistent grant. A grant is reused across turns and restarts until revoked, expired or outside scope. Authorized delegation may carry an attenuated reference to a real standing grant; handoff is not inherently powerless. The receiver verifies the grant chain, target/action scope and its own host authority. It neither trusts a model-written permission string nor requires the user to approve the same in-scope work again. Read-only discovery, direct reversible effects and protected operations keep their actual permission semantics; none is forced through a second confirmation merely because the entrypoint is chat. @@ -212,6 +220,32 @@ At-least-once delivery with idempotent Core effects is the target. Do not promis The receiver commits result/evidence links and audience-ready text. The manager may synthesize multiple worker outcomes into one answer, maintaining request-level coverage. A deterministic outbox delivers an already committed result even if the manager model is unavailable. If synthesis is required, persist that duty; do not let an optional synthesis step erase the worker's result. Model retries never replay an already accepted action. +#### Hierarchical delegation and autonomous progress + +An Agent may delegate a bounded subproblem and remain responsible for integrating +its result. Record parent/request lineage without treating it as a grant. At +each hop, scope, allowed effects, depth, total fanout and shared budget remain +within effective authorization; child creation does not multiply the team's +resource allowance. Reuse an existing peer when appropriate. Cancelling one +request affects only its owned descendant executions, not a shared Agent's +unrelated work. Detect wait cycles and release unnecessary execution slots +while awaiting children, so parents cannot consume all child capacity. + +Return follows the real dependency: child artifact -> receiver validation and +adoption/rejection -> parent integration -> original requester. Directly +forwarding a grandchild's output to the lead does not prove the intermediate +Agent coordinated or accepted it. Messages use the shared inbox/queue/steer +policies; receiving a message cannot grant a claim, alter intent or accept work. + +Extend A6/A8/A13 with a three-level synthetic journey and two input revisions. +The lead retains substantive work of its own; an intermediate worker decides +whether another peer is needed. Freeze the objective, constraints and injected +failure, not the team roster or phase sequence. At least one revised delegation +must originate from an Agent's response to contradictory evidence. Record +request/decision references and adoption facts, not private reasoning traces. +The harness may inject faults and check invariants; it must not supply every +next phase, manually forward results or certify success from message counts. + ### 5.7 Session and product continuity **Cross-session continuation is a first-class product journey, not transcript forwarding.** A user can ask “continue in another session/agent and report back here” once. Within existing authorization, the host prepares the context, selects the supported continuation path, presents it to the receiver and returns the conclusion automatically. The receiver reassesses the work; the user need not export JSON, repeat the background or approve routine restoration. This applies to manager and worker sessions alike. diff --git a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md index 6a328c6db4..942d23e087 100644 --- a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md +++ b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md @@ -152,6 +152,12 @@ flowchart LR 优先一次内聚替换，不用兼容包装长期保留两套判断。盘点所有 producer/reader，无损迁移、切换单 writer、删除被替代规则。必须复用有效契约和数据，不必复用每个类、JSON 目录和 prompt。 +主 Agent 负责拆解、调查、委派、修订和综合；host 服务执行已准入动作并恢复其回执， +不编码场景的下一业务 phase。普通 managed worker 也能经 +[会话执行 RFC](agent-session-execution-modes-v0.zh-CN.md#reusable-agent-operations-and-continuation-ownership) +定义的同一组有范围创建、会话和请求操作协调其他 Agent。保持管家应用薄，共享状态 +转移留在其 typed owner，不在管家或 provider adapter 中另建调度器。 + ### 5.3 让工作真正能推进的授权 基于已认证主体、来源/受众、资源范围和请求效果解析意图，匹配现有持续授权。范围内跨回合、重启复用，直到撤销、到期或超出范围。被授权的委托可以携带真实持续授权的收窄引用，handoff 不应天然没有行动能力。接收方验证授权链、目标/动作范围和自身宿主权限，既不信模型写的权限字符串，也不要求用户重复批准同一范围内的工作。只读发现、直接可逆操作、受保护操作维持各自真实权限语义；不能因为入口是聊天就额外要求一次确认。 @@ -212,6 +218,24 @@ LoopX 不是只有任务队列。交接应让接收方结合权威状态和持 接收方提交结果/证据链接和适合受众的文本。管家可将多个 worker 的结果综合成一份答复，保留逐请求覆盖。确定性 outbox 在管家模型不可用时也能投递已提交结论；若确实需要综合，持久化这个待办义务，不能让可选综合环节吞掉 worker 结果。重试模型不得重放已接受操作。 +#### 分层委派与自主推进 + +Agent 可以委派有界子问题，并保留综合结果的责任。记录 parent/request lineage，但 +不能把 lineage 当授权。每一跳的范围、允许效果、深度、总 fanout、共享预算都在 +生效授权内；创建 child 不能倍增整队额度。适合时复用已有 peer。取消某请求只影响 +它拥有的后代执行，不终止共享 Agent 的无关工作。检测等待环，等待 child 时释放 +不必要的执行槽，避免父任务占满 child 容量。 + +返回沿真实依赖发生：child 产物→接收者验证及采用/拒绝→父级综合→原请求者。 +直接把孙级输出转给主 Agent，不能证明中间 Agent 协调或验收过。消息复用统一 +inbox/queue/steer 策略；收到消息不授予 claim，不改变 intent，也不验收工作。 + +扩展 A6/A8/A13，使用三层合成旅程与两次输入修订。主 Agent 保留自己的实质工作，中间 +worker 自行判断是否需要其他 peer。冻结目标、约束和注入故障，不冻结团队名单或 +phase 顺序。至少一次委派修订由 Agent 根据矛盾证据自主产生。保留请求/决策引用 +及采用事实，不保存私有推理轨迹。验证 harness 可以注入故障并检查不变量，不能提供 +每个下一 phase、人工转发结果，或以消息数证明成功。 + ### 5.7 会话与产品连续性 **跨 session 续接是明确的产品旅程，不是转发聊天记录。** 用户只需说一次“换个会话/Agent 继续，结果还回这里”。在现有授权内，宿主准备上下文、选择可用续接路径、呈现给接收方并自动回报结论。接收方重新判断工作；用户不用导出 JSON、重复背景或批准常规恢复。管家和干活 Agent 都遵循此契约。 diff --git a/docs/architecture/rfcs/desktop-execution-frontends-v0.md b/docs/architecture/rfcs/desktop-execution-frontends-v0.md index 8bd428e18e..ba3ac7c362 100644 --- a/docs/architecture/rfcs/desktop-execution-frontends-v0.md +++ b/docs/architecture/rfcs/desktop-execution-frontends-v0.md @@ -299,9 +299,12 @@ inbound working conversation is Agent-scoped. ## Agent-scoped Bot ingress modes -An Agent-to-Bot connection needs three explicit ingress semantics. They are -delivery policies for one bound Agent, not three Agents and not a -natural-language classifier: +Agent-to-Bot connections and peer collaboration need the same three explicit +ingress semantics. User-facing names are **inbox**, **queue** and **steer**; +the existing vocabulary below remains. They express delivery intent for one +bound Agent, not three Agents or a natural-language classifier. This proposal +extends the common policy to peer ingress; it does not ship a new API or change +existing adapters merely by renaming their input: ```text agent_bot_ingress_mode_v0 = @@ -314,10 +317,23 @@ The three policies solve different availability conditions: | Mode | Delivery target | Availability model | Durable boundary | |---|---|---|---| -| `live_steering` | The currently attached or managed working session | Session is live and accepts ordered ingress | Existing session/event store; no second Agent session | -| `session_queue` | The same Agent working session when it next accepts input | Runtime exists but is busy, reconnecting, or temporarily offline | Owner-local ordered ingress queue keyed by Agent and session | +| `live_steering` | The specified active execution in the bound working session | Host can apply input at a declared safe point | Existing session/event store and consumption receipt; no second executor | +| `session_queue` | A subsequent work input in the same bound session | Current work finishes or explicitly yields its execution before delivery | Owner-local durable ordered ingress queue keyed by Agent and session | | `async_inbox` | The next eligible LoopX Agent turn after an explicit drain | No Agent process needs to remain alive | Existing provider-owned event inbox plus content-free quota urgency | +This refines the earlier queue phrase "when it next accepts input": a host that +merges pending input into the active work has not thereby implemented the +proposed queue semantics. Qualify the change explicitly, preserving old profile +behavior until its opt-in implementation and compatibility tests pass. + +Persist the requested mode, permitted fallback and actual delivery disposition +with existing ingress identity and recipient scope. Readback distinguishes +durable receipt, queued dispatch, host consumption and steering application; +work adoption/acceptance remains with collaboration/work owners. Model prose or +HTTP success is not a consumption receipt. Unknown capabilities fail explicitly. +Frontend, CLI and Lark show the effective mode, waiting reason and result on the +original work/conversation surface, rather than creating a separate team board. + ### Capture, ingress, and reply are orthogonal Provider selection and Agent delivery must not reuse one overloaded flag. The @@ -361,11 +377,20 @@ shares the Web ingress serializer, upstream resume identity, interrupt policy, workspace, runtime, trust, and capability boundary. If that binding is stale, ambiguous, terminal, or owned by another Agent, delivery fails closed. -Steering is transport, not task authority. A read-only exchange may remain a -normal session turn. A material effect still requires the fresh LoopX -decision, validation, writeback, and settlement appropriate to the attached or +Steering is transport, not task authority. Read-only input can be consumed by +the active session without claiming new work. A material effect still requires +the fresh LoopX decision, validation, writeback, and settlement appropriate to the attached or managed execution mode. +Steer targets the current execution generation and its next supported safe input +point; it is not interrupt/restart. While an external tool is outstanding, the +host may durably accept a pending correction without claiming it was applied. +If safe injection is unavailable, report that fact and use only the request's +explicit fallback. Never fabricate a tool result to deliver the correction. +An invalidated tool call needs an explicit cancellation disposition; reconcile +its late result against the current input version and execution fence. The +message itself neither cancels all peers nor revokes their authority. + ### Session queue `session_queue` is a broker-owned buffer for a known Agent working session. It @@ -373,8 +398,9 @@ preserves stable event dedupe, per-session order, bounded size, expiry, backpressure, cancellation, and crash-safe dispatch. It is not the LoopX Todo queue and may not mutate Goal priority, claim work, or grant capabilities. -When the same session becomes ready, the broker submits the oldest eligible -entry through the normal serialized ingress. A missing or replaced session +After the current work ends or explicitly yields execution, the broker submits +the oldest eligible entry through normal serialized ingress. A pending-tool +idle observation alone is not that boundary. A missing or replaced session requires an explicit rebind or dead-letter decision; it does not silently route the entry to a fresh Agent history. @@ -387,7 +413,8 @@ mention/reply counts, oldest age, and `reply_due`, never message bodies, senders, provider ids, private paths, or chat ids. When `reply_due=true`, the inbox lane preempts ordinary advancement and monitor -work. The selected Agent drains bounded content, interprets it against fresh +work at the next eligible admission; this does not interrupt an active execution. +The selected Agent drains bounded content, interprets it against fresh Goal state, writes any durable effect first, sends at most one idempotent source-thread reply with provider readback, and only then ACKs. Drain alone is read-only; collection or ACK is never semantic authority. @@ -400,6 +427,14 @@ must split provider collection from ingress policy, require the registered Agent id, and either submit through a verified working-session binding or publish the inbox pointer to the canonical quota path. +Qualify the three modes with one corrected-input fixture: pending tool, busy and +offline recipient, expired message, full queue, duplicate/conflicting identity, +session replacement, sender revocation and late tool result. Assert the actual +consumption boundary and fallback, not just message existence. Inbox drain must +not claim work acceptance; queue must not alter active work; steer must not claim +application before the host receipt. These are proposed acceptance requirements, +not evidence that every host currently supports all modes. + ### Initial product ordering The first integration should enable `async_inbox` for environments where an diff --git a/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md b/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md index bb01935762..772dacc80f 100644 --- a/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md +++ b/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md @@ -253,10 +253,14 @@ owner-local inbox 存储中；状态和 quota 只看到无内容的紧迫性。 绑定”的交互式聊天约束。Goal 级 Kanban、生命周期通知和共享协作工件可以保持 Goal 级；入站工作对话是 Agent 级的。 + + ## Agent 级 Bot 入口模式 -Agent 到 Bot 的连接需要三种显式的入口语义。它们是同一个已绑定 Agent 的 -投递策略，不是三个 Agent，也不是自然语言分类器： +Agent 到 Bot 的连接与 peer 协作需要同样的三种显式入口语义。用户侧简称 +**inbox**、**queue**、**steer**，保留下述现有词汇。它们表达同一已绑定 Agent 的 +投递意图，不是三个 Agent 或自然语言分类器。本提案将共同策略扩展到 peer 入口， +不因重命名输入就声称新增 API 或改变已有 adapter： ```text agent_bot_ingress_mode_v0 = @@ -269,10 +273,19 @@ agent_bot_ingress_mode_v0 = | 模式 | 投递目标 | 可用性模型 | 持久边界 | |---|---|---|---| -| `live_steering` | 当前挂接或托管的工作会话 | 会话在线并接受有序入口 | 现有会话/事件存储；无第二个 Agent 会话 | -| `session_queue` | 同一 Agent 工作会话在下次接受输入时 | 运行时存在但忙碌、重连中或暂时离线 | 按 Agent 与会话键控的 owner-local 有序入口队列 | +| `live_steering` | 已绑定工作会话中指定的当前执行 | 宿主能在声明的安全点采用输入 | 现有会话/事件存储及消费回执；无第二执行器 | +| `session_queue` | 同一已绑定会话中的后续工作输入 | 当前工作结束或明确交还执行权后再投递 | 按 Agent 与会话键控的 owner-local 持久有序入口队列 | | `async_inbox` | 显式排空后的下一个合格 LoopX Agent Turn | 无需 Agent 进程保持存活 | 现有 provider 拥有的事件 inbox 加无内容 quota 紧迫性 | +这细化了此前 queue 的“下次接受输入”表述：把 pending 输入合入当前工作的宿主， +并不因此实现拟议 queue 语义。变更必须显式资格化，在 opt-in 实现和兼容测试通过前 +保持旧 profile 行为。 + +沿现有入口身份和接收者范围持久化请求模式、允许的 fallback 和实际投递处置。读回 +区分耐久收件、排队派发、宿主消费和 steer 采用；工作采用/验收仍属于 collaboration/work +owner。模型正文或 HTTP 成功不是消费回执；未知能力明确失败。前端、CLI、Lark 在 +原工作/对话面展示实际模式、等待原因及结果，不另造一块团队看板。 + ### 捕获、入口与回复正交 provider 选择与 Agent 投递不得复用同一个过载标志。初始 Lark 群形态是： @@ -307,16 +320,23 @@ mention 准入同时绑定已验证 provider profile 返回的 App id 与 Bot op 上游恢复身份、中断策略、工作区、运行时、信任和能力边界。如果该绑定陈旧、 模糊、终态或属于另一个 Agent，投递失败关闭。 -操控是传输，不是任务权威。只读交流可以是普通会话 Turn。实质效果仍然需要与 +操控是传输，不是任务权威。当前会话可以消费只读输入而不领取新工作。实质效果仍然需要与 所采用执行模式相称的最新 LoopX 决策、验证、回写和结算。 +Steer 面向当前执行代际及其下一个支持的安全输入点，不等于 interrupt/restart。 +外部工具未返回时，宿主可以耐久接收 pending correction，但不能声称已经采用。 +无法安全注入时明确报告，仅按请求显式 fallback 处理；绝不伪造工具结果来投递纠正。 +失效工具调用需要明确取消处置，其迟到结果对照当前输入版本和执行 fence 对账。 +消息本身不取消所有 peer，也不撤销其权限。 + ### 会话队列 `session_queue` 是已知 Agent 工作会话的 broker 拥有的缓冲。它保留稳定的事件 去重、按会话排序、有界大小、过期、背压、取消和崩溃安全派发。它不是 LoopX Todo 队列，不得改变 Goal 优先级、认领工作或授予能力。 -当同一会话恢复就绪时，broker 通过正常的串行化入口提交最旧的合格条目。缺失 +当前工作结束或明确交还执行权后，broker 通过正常串行化入口提交最旧的合格条目； +仅有 pending-tool idle 观察不能证明这个边界。缺失 或被替换的会话需要显式重新绑定或死信决策；它不会把条目静默路由到全新 Agent 历史。 @@ -327,8 +347,9 @@ Todo 队列，不得改变 Goal 优先级、认领工作或授予能力。 `operator_inbox_urgency_v0`：pending/question/mention/reply 计数、最旧年龄和 `reply_due`，绝不投影消息正文、发送者、provider id、私有路径或 chat id。 -当 `reply_due=true` 时，inbox 通道抢占普通推进和 monitor 工作。被选中的 Agent -排空有界内容，对照最新 Goal 状态解释它，先写入任何持久效果，然后发送至多 +当 `reply_due=true` 时，inbox 通道在下次合格准入时抢占普通推进和 monitor 工作， +不打断当前执行。被选中的 Agent 排空有界内容，对照最新 Goal 状态解释它，先写入 +任何持久效果，然后发送至多 一条带 provider readback 的幂等 source-thread 回复，最后才 ACK。仅排空是 只读的；采集或 ACK 永远不是语义权威。 @@ -338,6 +359,11 @@ Goal Topic 兼容运行时目前把 provider 采集、Inbox 文件、Goal Chat 采集与入口策略分开、要求已登记的 Agent id，并且要么通过已验证的工作会话 绑定提交，要么把 inbox 指针发布到规范 quota 路径。 +用同一修订输入 fixture 验证三模式：未决工具、接收方忙碌/离线、消息过期、满队列、 +重复/冲突身份、会话替换、发送方撤权及迟到工具结果。断言实际消费边界和 fallback， +不能只看消息存在。Inbox drain 不证明工作验收；queue 不改当前工作；steer 不能先于 +宿主回执声称已采用。这些是拟议验收要求，不是所有宿主已支持三模式的证据。 + ### 初始产品排序 第一次集成应针对已运行的 App 会话尚不能接受 broker 输入的环境启用 diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md index 8a9f6d94eb..20763e88b3 100644 --- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md +++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md @@ -192,6 +192,41 @@ Open gaps before this binding is a promoted production default: still covers visible hosts only, because a headless-only host such as `dsh` cannot own a visible session. +### Mixed local/cloud managed qualification (proposal) + +The [session execution RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership) +separates provider, session ownership and continuation owner. Extend the same +managed work contract to a qualified cloud host; do not encode local = Turn and +cloud = native Goal. Keep the current managed-host and steward defaults above. + +LoopX's public [Ark Managed Agent host contract](../../../loopx/ark_managed_agent_host.py) +currently specifies one-shot Goal activation, native continuation and no outer +Turn driver. A cloud governed-Turn adapter is a **separate, unqualified opt-in +candidate**, not a reinterpretation of that profile. DSH's +[bounded Turn adapter](../../../loopx/dsh_goal_mode/README.md) and +[same-session plugin](../../../packages/dsh-loopx-plugin/README.md) likewise have +different continuation contracts; qualification cannot be borrowed between them. + +First qualify a complete local/cloud work unit: actual tools/artifact transfer, +typed result, independent rejection of a wrong artifact, accepted writeback, +usage readback, cancellation and recovery. Then qualify two dependent work cycles +and worker-initiated delegation using the shared collaboration contract. A host +adapter transports Agent decisions; it must not contain the scenario's business +phase sequence. Waiting parents must not occupy every slot needed by children. + +Native Goal qualification additionally needs publicly documented activation and +identity, duplicate-activation behavior, evaluation/terminal readback, bounded +resource use, defer/wake and restart handling. A successful message or an idle +session is insufficient. A provider API or slash wrapper stays in its adapter; +it is not a generic LoopX command. Provider claims require public versioned +sources and reproducible qualification; this proposal cites only LoopX-side +contracts and makes no new claim about an Ark deployment or API guarantee. + +Report actual provider usage separately from LoopX's validated-work quota: +rejected work can still incur inference cost. Unknown usage is not zero. Promote +only the tested profile; keep unavailable capabilities explicit and preserve +rollback to the prior selected profile without creating a concurrent driver. + ## Evidence Baseline LoopX was inspected at `bf217e1e01bec79f357c9ecbd580cf2dfa73db8b`. diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md index 49bfb668fd..c82b529c46 100644 --- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md +++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md @@ -149,6 +149,33 @@ LoopX **选择**托管有界 Turn 的默认宿主，而从不由启动时的意 `--host-identity` 列表仍只覆盖可见宿主，因为像 `dsh` 这种仅 headless 的宿主无法 拥有可见会话。 +### 混合本地/云端 managed 资格化（提案） + +[会话执行 RFC](agent-session-execution-modes-v0.zh-CN.md#reusable-agent-operations-and-continuation-ownership) +区分 provider、会话归属和续跑 owner。把同一 managed 工作合同扩展到合格云端宿主， +不能编码成本地=Turn、云端=原生 Goal；上文现有 managed-host 与管家默认保持不变。 + +LoopX 公开的 [Ark Managed Agent host contract](../../../loopx/ark_managed_agent_host.py) +当前规定一次 Goal 激活、原生续跑、无外层 Turn driver。云端 governed-Turn adapter +是**独立、尚未资格化、需显式选择的候选**，不能重新解释该 profile。DSH 的 +[有界 Turn adapter](../../../loopx/dsh_goal_mode/README.md)与 +[同会话 plugin](../../../packages/dsh-loopx-plugin/README.md)也有不同续跑合同，资格 +不能互借。 + +先验收一次完整的本地/云端工作单元：真实工具/产物传递、typed result、独立拒绝错误 +产物、验收后写回、usage 读回、取消与恢复；再验两轮依赖工作及 worker 主动委派， +复用统一协作合同。Host adapter 传输 Agent 的决定，不包含场景业务 phase 顺序。 +等待中的父任务不能占满子任务需要的全部执行槽。 + +原生 Goal 还需公开文档支持的激活与身份、重复激活行为、评估/终态读回、有界资源使用、 +defer/wake 和重启验证。消息成功或 session idle 都不足以证明。Provider API 或 slash +包装只放在其 adapter，不成为 LoopX 通用命令。Provider 能力声明必须有公开版本化 +来源及可复现资格证据；本提案仅引用 LoopX 自身合同，不新增对 Ark 部署或 API 保证的声明。 + +实际 provider 用量与 LoopX 已验收工作 quota 分开报告：被拒绝的工作仍可能产生推理 +费用，unknown 不能记零。只晋升已测试 profile，明确不可用能力；回滚到原选定 profile +时不能产生并行 driver。 + ## 证据基线 LoopX 检查基线为 `bf217e1e01bec79f357c9ecbd580cf2dfa73db8b`： diff --git a/docs/architecture/rfcs/loopx-overall-roadmap-v0.md b/docs/architecture/rfcs/loopx-overall-roadmap-v0.md index 738c97b9e6..734983ace4 100644 --- a/docs/architecture/rfcs/loopx-overall-roadmap-v0.md +++ b/docs/architecture/rfcs/loopx-overall-roadmap-v0.md @@ -171,6 +171,22 @@ This change adds no capability/provider. R1/R3 should extend existing work-items Steward coordination permits logical goal decomposition, priority suggestions, delegation and synthesis. `peer_v1` does not prohibit that product role; it prohibits the role conferring unilateral writes, preemption or elevated authority. Macro-goals spanning Goals use existing Goal relationships and scoped requests. Where cross-Goal dependencies or aggregate acceptance lack an owner, deliver a bounded contract with a real caller first, not a global scheduling DSL. +The lead may be an existing attached Agent or a managed Agent; an authorized +worker can coordinate another level through the same operations. Separate Agent +creation/reuse, session attach/start, communication and work acceptance. The +[session RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership) +owns this common lifecycle and the single continuation owner per binding; +the [frontend RFC](desktop-execution-frontends-v0.md#agent-scoped-bot-ingress-modes) +owns inbox/queue/steer delivery, and the handoff RFC owns receiver adoption and +hierarchical return. These are proposed integration requirements, not a new +runtime, provider guarantee or permission default. + +Agents choose and revise the work graph. Generic host services enforce admission, +dispatch, budget and recovery without encoding business phases. Qualify local and +cloud managed work against one governed Turn contract first, while retaining +native Goal and same-session driver profiles as distinct qualified paths. A +team's total resource allowance is not copied to each child coordinator. + ### Collaboration and Handoff Between LoopX Agents Participants are long-running LoopX Agents with their own goals, commitments, frontiers and execution bindings, not merely temporary subtasks inside the steward process. Manager→worker and worker→worker share one collaboration contract. Workers can request help, provide results, challenge dependencies and propose replanning without asking the steward to relay every message. The steward owns overall progress and synthesis, not a serial transit point for every message or commit. @@ -215,7 +231,7 @@ These priorities do not change live Goal quota or authorize experiments/cloud re - **Entrypoint/owner:** existing session binding, Turn driver, quota/scheduler and manager runtime configuration; reuse the current settings editor/profile owner. - **Delivery:** distinguish registered, addressable, bound, launchable, executing and blocked. Plan readiness cannot imply running work. For authorized, qualified managed bindings, launch the next bounded Turn through existing launch/supervision. Attached hosts retain their original execution driver. - **Qualification:** use the actual selected runtime for at least two work→artifact→independent validation→settlement→successor cycles; interrupt/restart one worker while another progresses. Verify returning stale-executor fences, cancellation and no new launches after stop. Qualify DSH single-segment read-only Chat separately from Codex `trusted_owner`. -- **Exit:** 2–3 workers, one dependency, one failure and one direction correction; inspect through packaged frontend and independent CLI readback. An authorized Lark entry reads the corresponding audience-visible feedback. Untested Lark remains explicitly unqualified. +- **Exit:** 2–3 workers, one dependency, one failure and one direction correction; Agents select and revise delegation without manual phase input or result forwarding. Inspect through packaged frontend and independent CLI readback. An authorized Lark entry reads the corresponding audience-visible feedback. Untested Lark remains explicitly unqualified. - **Rollback:** stop new admission, drain accepted work and retain bindings/receipts; attached fallback cannot be used to simulate availability. ### R3: Semantic Requests and Automatic Return @@ -225,6 +241,14 @@ These priorities do not change live Goal quota or authorize experiments/cloud re - **Exit:** actual manager→worker and worker→worker callers; follow-up messages, lost source session, oversized answer, duplicate callback, successful send with lost ACK and transport restart. CLI, packaged frontend and Lark read back the same result with audience isolation. Ordinary already-authorized work gains no second confirmation. - **Migration/rollback:** characterize first, record old writer/reader mappings and deletion payoff; disabling new production must leave old requests drainable. Do not retain two writable lifecycles. +R3 also qualifies the handoff RFC's hierarchical A6/A8/A13 extension: a managed +worker requests, validates and integrates another peer's artifact before returning +to the lead. Reuse the same request and work owners at each level. The ingress +fixture distinguishes inbox receipt, subsequent queue work and applied steer +under a pending tool, cancellation and a late result; transport success alone +does not close the request. Keep existing R2/R3 successors rather than opening +a parallel team-orchestration program. + ### R4: Shared Goal Alignment and Evolution - **Owner:** alignment RFC Stage 3–5 and TS Goal/work-graph owners. @@ -250,6 +274,15 @@ L3 checkpoint: standalone acquisition/takeover, atomic claim admission and maint - **Exit:** at least two real hosts, including one cloud worker, collaborate in an isolated tenant; wrong-tenant/actor, revocation and split-brain negatives pass. Shared budgets/admission have explicit ownership; local quota is not a distributed resource reservation. - **Rollback:** stop remote admission, retain committed facts and drain; do not import or rebind another host's raw session data. +A useful precursor may keep one already-supported local authority and execute +cloud work through a scoped host facade. It can advance R2/R3 and qualify a +provider adapter without deploying a shared database service. Label it **single +authority, mixed execution**: it does not pass G3/R6's independent-host recovery, +shared reservation or service qualification. Never clone independently writable +Goal state into the cloud; full R6 retains its authenticated-service and D1–D3 +requirements. Evaluate each continuation profile separately, with no concurrent +outer Turn and native Goal driver on one binding. + ### R7: Hundred-Agent Qualification - **Owner:** existing directory/projection, quota/scheduler, authority/provider and host supervisor. The manager consumes bounded summaries, pages and evidence on demand. diff --git a/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md b/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md index c9901d0398..f6f16ed198 100644 --- a/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md +++ b/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md @@ -171,6 +171,18 @@ flowchart TD “管家协调”允许逻辑上的目标分解、优先级建议、委托和综合；`peer_v1` 不禁止这种产品角色，但禁止因角色获得单方写入、抢占或提权。跨多个 Goal 的宏观目标应通过已有 Goal 关系和有范围请求关联；跨 Goal 依赖或汇总验收若缺少 owner，先交付一个有真实 caller 的有界合同，不能先造全局调度 DSL。 +主 Agent 可以是已有 attached Agent 或 managed Agent；获授权的 worker 能用同样操作 +协调下一层。区分 Agent 创建/复用、会话挂接/启动、通信和工作验收。 +[会话 RFC](agent-session-execution-modes-v0.zh-CN.md#reusable-agent-operations-and-continuation-ownership) +拥有通用生命周期与每 binding 唯一续跑 owner； +[前端 RFC](desktop-execution-frontends-v0.zh-CN.md#agent-scoped-bot-ingress-modes)拥有 +inbox/queue/steer 投递语义；handoff RFC 拥有接收者采用和分层返回。这些是拟议集成 +要求，不是新 runtime、provider 保证或权限默认。 + +Agent 决定并修订工作图；通用 host 服务负责准入、派送、预算和恢复，不编码业务 +phase。先让本地/云端 managed 工作通过同一 governed Turn 合同，同时保留分别 +资格化的 native Goal、同会话 driver 路径。整队资源额度不能复制给每个子协调者。 + ### 多个 LoopX Agent 的协作与 handoff 验收 协调对象是各自持有目标、承诺、frontier 与执行绑定的长程 LoopX Agent，不只是管家进程中的临时子任务。管家→worker 与 worker→worker 使用同一协作合同；worker 可以主动求助、提供结果、质疑依赖和提出重规划，无需每次让管家转发。管家负责整体推进与综合，不能成为每条消息或每次状态提交的串行中转站。 @@ -215,7 +227,7 @@ R2 的一条依赖必须通过真实 LoopX Agent 间的请求/产物交接完成 - **入口与 owner：** 现有 session binding、Turn driver、quota/scheduler、manager runtime 配置；复用已有设置 editor，不新建 profile。 - **交付：** 区分 registered、可接收请求、已绑定、可启动、正在执行和阻塞；计划 ready 不能暗示正在工作。对已授权且具备资格的 managed binding，沿现有 launch/supervision 路径启动下一有界 Turn。attached host 继续由其原 host 驱动。 - **资格：** 用真实选定 runtime 执行至少两轮“取工作→产物→独立验证→settle→下一工作”，中断并重启一个 worker，另一个保持推进；验证旧执行器返回时的 fence、取消及停止后不再启动。DSH 单段 read-only Chat 与 Codex `trusted_owner` 分别验收，不互借资格。 -- **退出：** 2–3 worker、一个依赖、一个故障、一个方向补充，经 packaged frontend 查看，同一状态能从 CLI 读回；Lark 的授权入口能读到对应受众可见反馈。无 Lark 实测则该入口标为未验收。 +- **退出：** 2–3 worker、一个依赖、一个故障、一个方向补充；Agent 自主选择和修订委派，无人工 phase 输入或结果转发。经 packaged frontend 查看，同一状态能从 CLI 读回；Lark 的授权入口能读到对应受众可见反馈。无 Lark 实测则该入口标为未验收。 - **回滚：** 停止新增 admission，drain 已接受工作并保留绑定/receipt；不能借 attached fallback 保持“在线”。 ### R3：语义请求与自动回报 @@ -225,6 +237,11 @@ R2 的一条依赖必须通过真实 LoopX Agent 间的请求/产物交接完成 - **退出：** manager→worker 和 worker→worker 两个真实 caller，补充消息、来源会话消失、超长答案、重复回调、发送成功但 ACK 丢失及传输重启；同一结果在 CLI、packaged frontend、Lark 回读一致且受众隔离。普通已授权工作不增加第二次人工确认。 - **迁移/回滚：** characterization 先行，记录旧 writer/reader 映射与删除收益；关新 producer 后可 drain 旧请求。不要同时保留两份可写生命周期。 +R3 还需验证 handoff RFC 的分层 A6/A8/A13 扩展：普通 managed worker 请求、验证并 +综合另一 peer 的产物后再返回主 Agent；各层复用相同 request/work owner。入口 +fixture 在未决工具、取消、迟到结果下区分 inbox 收件、后续 queue 工作和已采用 +steer；传输成功不关闭请求。复用现有 R2/R3 后继，不另开平行团队编排项目。 + ### R4：共享目标对齐与演化 - **Owner：** alignment RFC Stage 3–5；TS Goal/work-graph owner。 @@ -250,6 +267,12 @@ L3 检查点：独立领取/接管、原子 claim 准入与维护共用 typed le - **退出：** 至少两个真实 host（含一个云端 worker）在隔离 tenant 上协作；错 tenant/actor、撤销与 split-brain 负例通过；共享预算与 admission 有明确 owner，不能声称本地 quota 就是分布式资源预留。 - **回滚：** 停远端 admission，保留已提交事实并 drain；不导入或重绑另一 host 的原始 session 数据。 +有用的前置切片可以保留已支持的单一本地 authority，经有范围 host facade 执行云端 +工作，不部署共享数据库服务也能推进 R2/R3 并验证 provider adapter。应标为 +**单一权威、混合执行**，不因此通过 G3/R6 的独立 host 恢复、共享预留或 service +资格。禁止向云端复制可独立写入的 Goal 状态；完整 R6 保留认证服务和 D1–D3 要求。 +各续跑 profile 分别验证，同一 binding 不并行运行外层 Turn 与 native Goal driver。 + ### R7：百 Agent 资格化 - **Owner：** 现有目录/投影、quota/scheduler、authority/provider 和 host supervisor；管家只消费有界摘要、分页及按需证据。 diff --git a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md index d13c6a2e01..727d5aced9 100644 --- a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md +++ b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md @@ -375,6 +375,21 @@ with T1–T3/D1/D2; changing storage/profile/source or retiring a whole legacy Goal writer still requires the applicable D3/T4 boundary. A new handoff is not a provider promotion request. +Hierarchical coordination uses these same boundaries at every hop. Parent/request +lineage is not an authority token, and a child coordinator does not receive a +fresh copy of the team's quota. Admission, reservations, claim/lease and accepted +effects stay with their existing typed owners; provider session status and +inbox/queue/steer receipts remain execution or transport observations. A native +Goal evaluator cannot declare canonical work complete on their behalf. + +For the roadmap's first mixed-execution slice, an already supported local +authority may receive scoped commands through a host facade while cloud Agents +execute work. This creates neither a new authority provider nor independent +cloud writers. An outage must preserve the selected-source and stale-fence +rules; it cannot trigger local/cloud authority fallback. Independently scheduling +hosts still require authenticated service transport and applicable D1–D3 +qualification. In-process admission code is not evidence of that deployment. + ## 2. What We Will Do, and What We Will Not **What this version will do** diff --git a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md index aacd5c24a4..71b53e9322 100644 --- a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md +++ b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md @@ -303,6 +303,17 @@ canonical amendment。管家与 provider 都不成为该 authority。M1–M3 管 T1–T3/D1/D2 并行；改变存储/profile/source 或退役完整 legacy Goal writer，仍遵守 适用的 D3/T4 边界。新 handoff 不构成 provider 晋级请求。 +分层协调的每一跳都使用相同边界。Parent/request lineage 不是权限令牌，子协调者 +也不会获得整队 quota 的新副本。准入、资源预留、claim/lease 和已验收效果仍由 +既有 typed owner 负责；provider 会话状态、inbox/queue/steer 回执只是执行或传输 +观察。原生 Goal evaluator 不能替这些 owner 宣布 canonical 工作完成。 + +总纲首个混合执行切片可以由已支持的本地 authority 经 host facade 接收有范围命令， +云端 Agent 负责执行。这不创建新的 authority provider 或独立云端 writer。故障时 +保持选定来源和 stale-fence 规则，不能触发本地/云端 authority fallback。需要独立 +调度的多 host 仍须认证 service transport 与适用 D1–D3 资格；进程内 admission 代码 +不能证明该部署存在。 + ## 2. 要做的，以及不要做的 **这版要做的** diff --git a/docs/architecture/rfcs/single-owner-local-daemon-v0.md b/docs/architecture/rfcs/single-owner-local-daemon-v0.md index d220e992bf..c23a0d768c 100644 --- a/docs/architecture/rfcs/single-owner-local-daemon-v0.md +++ b/docs/architecture/rfcs/single-owner-local-daemon-v0.md @@ -112,6 +112,17 @@ LaunchAgent and cannot detach or self-relaunch. The platform adapter must prove child containment after supervisor death before promotion; a process group alone is not sufficient proof on every platform. +Managed team supervision must also respect the +[session continuation owner](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership). +One service-profile process owner does not prove one executor per Agent binding; +the session/work owners still enforce their own identity, admission and fences. +A daemon may deliver admitted work, wake an eligible session, drain queues and +recover receipts. It must not encode a team's business phases or compete with +an active native Goal/same-session driver for the next execution opportunity. +Local and cloud host adapters reuse this composition rather than installing a +manager-specific daemon. Readiness must distinguish service health from a +worker's launchability, pending tool, deferred work and terminal result. + ### Read contract The proposed control routes are served on the configured status origin, initially