[Aevatar Harness] 核心能力边界讨论

[eanzhao]

背景

这个 Discussion 由 issue #567 迁移而来：#567

我们把它从 issue 转成讨论形态，是因为这里讨论的不是一个单点实现任务，而是 Aevatar Harness 的能力边界、产品表达和后续拆解方向。

希望参与讨论的人：
@loning @jason-aelf @louis4li

当前先按五个角度组织讨论，每个角度在下方各有一个独立回复帖，团队可以在对应回复下继续补充、反驳、拆任务：

1. Agent Loop
2. Tools / Skills / Plugins
3. Memory / Session
4. Governance
5. Multi-Agent

架构图

当前状态总览

目标愿景总览

总体判断

Aevatar 不应该简单复刻一个通用 agent harness。它已经有自己的底座：

• Orleans 上的 GAgent / actor runtime；
• 基于 EventEnvelope 和 stream 的 agent-to-agent message plane；
• event sourcing 的 actor-owned state；
• CommittedStateEventPublished(state_event + state_root) 到 projection/readmodel 的观察链路；
• workflow / scripting / AI role / tool middleware 等已经存在的执行能力。

所以 Harness 的方向不是另起一套框架，而是把这些能力收敛成可描述、可治理、可观察、可扩展的运行时产品能力。

外部边界

这里也先明确一条原则：

• Tools / Plugins 优先结合 NyxID，复用 NyxID 当前公开的 service config、proxy、MCP、credential、approval、agent binding、rate limit、audit 等能力；Aevatar 不假设 NyxID 为 Aevatar 定制新增能力。
• Skills 优先结合 Ornn，复用 Ornn 当前公开的 skill 创建、发布、搜索、拉取能力；runtime/sandbox execution 按 Aevatar 的接入成熟度逐步纳入，不把外部能力直接等同于 Aevatar 已经具备的 Harness 能力。
• Aevatar 只做接入、编排、运行时上下文传递、状态/事件/投影、capability lifecycle，以及少量必要的 Aevatar-native tools。

这个 Discussion 不要求 NyxID、chrono-ornn、chrono-storage 等外部仓库新增能力。方案讨论应优先使用外部仓库当前已公开 surface；如果不足，优先考虑 Aevatar 内部绕开或暂不做。

讨论方式

建议每个角度都围绕这几类问题展开：

• Aevatar 已经有什么？
• 这些能力和普通 agent harness 有什么不同？
• 当前最明显的缺口是什么？
• 哪些应收敛成平台 primitive？
• 哪些只是业务层 pattern？
• 第一阶段最小闭环是什么？

[eanzhao]

1. Agent Continuation

更新（2026-05-06）：采纳 @loning 的建议，将本节从 "Agent Loop" 更名为 Agent Continuation。

Loning 的原话："我的理解, 不应该有loop. 即便看起来是loop, 也是基于事件驱动的. 我在收到pong的时候发一个ping这种事件驱动."

Actor 模型本就不应使用 "loop" 这个字眼混淆其真正运行机制。"Loop" 是命令式编程的栈上隐喻——上下文挂在调用栈、同步阻塞、崩溃即丢、approval / timeout / cancel 必须在循环内 hack。Aevatar 的 actor 推进根本不是循环，是 ping-pong：收到 pong 就发 ping，没人在中间等。

这也和 CLAUDE.md 既有的硬约束一致：self continuation 事件化、延迟/超时事件化、跨 actor 等待 continuation 化。本节的 framing、命名、序列化描述全部按这个原则重写。

Agent Continuation 图

核心判断

Agent 在 Aevatar 里的推进，不是 loop，是 actor 内的 event choreography。看起来像循环的部分，本质是 event → handler → emit next event 的链：LLM sampling、tool call、approval、timeout、retry、cancel、resume、completion 每一项都是 actor inbox 里独立的一拍，落到事件、状态和投影上。

这和普通 harness 的 while llm_wants_more: sample → tool → append 有本质区别：

• 上下文不在调用栈里，挂在 actor state；崩溃可恢复。
• 没有"等待"——actor 当前 turn 结束、发 self-message 或外部事件，下一拍另一个 turn 醒来继续。
• approval / timeout / cancel 是平等的事件，不是循环内的特殊分支。
• 每一拍都天然可观察、可投影、可治理。

当前已经有的基础

• ChatRuntime 已经实现 LLM → tool call → tool result → next round 的多轮推进。
• ToolCallLoop 和 StreamingToolExecutor 已经支持 structured tool call、文本/XML fallback、streaming tool execution。
• RoleGAgent 已经把 AI 推进接进 GAgent / actor 模型，通过 ChatRequestEvent 触发，通过 text/tool events 对外发布观察。
• ToolApprovalMiddleware + YieldApprovalHandler + PendingToolApprovalState 已经能把 approval yield 成 actor continuation。
• WorkflowRunGAgent 和 WorkflowExecutionKernel 更接近理想形态：step、timeout、retry、backoff、completion 都通过事件推进——这是 Agent Continuation 的标杆。
• GAgentBase<TState> 已经有 event sourcing 和 committed-state observation，这给 continuation 的状态化、投影化提供了底座。

注：ChatRuntime 和 ToolCallLoop 命名上仍带 "Runtime / Loop" 字样，是历史包袱。这些命名应跟随本次 framing 一起收敛（参见下文"第一阶段最小闭环"）。

主要缺口

现在的问题不是"完全没有 continuation"，而是几条 actor 推进链没有统一成 Harness 语义：

• Chat 推进、workflow 推进、tool 推进、approval 续跑还没有统一的 AgentRun / AgentSession / AgentTurn / AgentContinuation 概念。
• ChatRuntime 仍偏本地 in-stack 执行器，内部存在长耗时 LLM / tool 执行和后台任务；它把"多步打包成一次函数调用"，本质上就是栈上的 loop——这是当前最需要被事件化拆解的地方。
• LLM sampling、tool invocation、approval、timeout、budget、retry 没有全部成为 actor-owned continuation state。
• 中间态 readmodel 还不完整，例如 turn trace、tool ledger、approval ledger、budget usage、failure reason、resume point。
• run 的 ACK 语义还需要更诚实地区分 accepted、dispatched、committed、observed。

建议收敛方向：Event Choreography 而非 Pipeline

不再用"线性 8 步 pipeline"描述推进，改成 actor inbox 上的 event choreography：

ChatRequested
  └─► LLMSamplingRequested
        └─► LLMSamplingCompleted
              ├─► (no tool)  ─► RunCompleted
              └─► (has tool) ─► ToolInvocationRequested
                    └─► ToolInvocationCompleted
                          └─► TurnContinuationDecided
                                ├─► LLMSamplingRequested  (新一拍)
                                └─► RunCompleted

侧链（不阻塞主 turn）:
  ApprovalRequested ─► ApprovalDecided / ApprovalTimedOut
  BudgetWarning / BudgetExceeded
  RunCancelled / RunFailed

关键点：没有任何一处是"等待"。每一步都是 actor inbox 里独立的一拍，handler 决定下一步发什么事件。

可观察事件清单：

• AgentRunStarted / Completed / Failed / Cancelled
• AgentTurnStarted / Completed
• LLMSamplingRequested / Completed / Failed
• ToolInvocationRequested / Completed / Failed
• ApprovalRequested / Decided / TimedOut
• BudgetWarning / BudgetExceeded
• TurnContinuationDecided

第一阶段最小闭环

围绕 RoleGAgent 做最小闭环：

• 定义 AgentRun / AgentSession / AgentTurn / AgentContinuation 的最小 typed contract。
• 给当前 chat 推进加一层 run / turn observation，不急着重写全部 executor。
• 把 tool invocation、approval、completion 投影成 readmodel。
• 明确 ChatRuntime 的去向：短期保留作为"单次 LLM sampling 的 IO worker"（HTTP 调用 + 流式解析），多 turn / tool 编排彻底搬到 RoleGAgent 的 event handler。不再存在"loop runner"这种角色。
• 对长耗时 approval / timeout / retry 优先 self-message + durable timer 化——"tab 关掉状态还在"，不是栈上的 await。
• 命名跟随收敛：后续 ToolCallLoop 等历史命名按职责改名（例如 ToolInvocationDispatcher）。

需要团队讨论的问题

• Agent Continuation 的权威状态应该放在 RoleGAgentState，还是新增 run-scoped actor？
• Chat 推进和 workflow 推进是统一成一个 Run model，还是共享 observation / readmodel 即可？
• 哪些中间态必须进入 event sourcing，哪些只做 transient streaming observation？
• streaming sampling 期间要不要 emit 中间 token event？还是只有 LLMSamplingStarted / Completed 进 actor inbox，token 走旁路 stream 给 UI？
• 第一阶段是否接受 ChatRuntime 继续作为本地 IO worker，只在边界补 observation？长期是否完全拆解？

---

二轮更新（2026-05-06，采纳 @loning 第二轮反馈）

@loning 的进一步判断：

"ChatRuntime 感觉也不该存在. 实际上, 软件工程就是最好的Harness, 对于agents的组织形态, 管理学就是最好的Harness."

"Loop的出现, 实际上是一种线性思维导致的结果, 本质上是把复杂的信息维度压缩在一根轴上, 这样会丢失大量信息."

"通过提示词要求AI, 给AI目标. 通过程序gates限制住AI. aevatar的tool call 天然能限制很多, 如果加上scheme约束之类的就更清晰."

推荐参考 NewMath / AutoMath 的因果链条思考方式。

接受。原本"短期保留 ChatRuntime 作为 IO worker"只是过渡形态——长期目标：彻底消除 ChatRuntime 这个抽象。

理由：

• ChatRuntime 现在的职责（拼 prompt → 调 LLM → 解析 streaming → 识别 tool call → dispatch tool → append history → 回到第一步）本质就是 loop 思维的产物——把"多步推进"打包成"一个函数调用"，仍然是栈上的 loop。
• 如果系统真是事件驱动的，没有任何角色应该叫 Runtime 在中间 orchestrate。
• Loning 推荐的 NewMath / AutoMath 因果 DAG 思考方式，正是 event choreography 的数学形式——多维信息保留在事件因果图里，而不是压缩到时间轴循环上。

长期形态

• LLM 调用降级为一个 connector / tool（与 HTTP / CLI / MCP 同级）
• 每次 LLM 响应 = LLMResponded 事件进 RoleGAgent inbox
• tool dispatch = RoleGAgent handler 收到事件后决定下一步发什么事件
• "下一轮" = 下一个 self-message
• 没有任何 "Runtime / Loop / Executor" 角色在中间

这样 LLM 就和其他外部能力一样接受四层 governance（详见 §4）：schema / boundary / actor / topology。

Self-Introspection（合并自作废的原 §3 Memory）

原 §3 Memory 节作废后（理由见 §3），其中"agent 看自己历史 / 状态"这一部分能力保留为 Continuation 模型的子集——但不引入 "Memory" 抽象层：

• inspect_self_state：tool，读 actor 当前 state（受 §4 governance 约束）
• search_self_events：tool，按事件类型 / 时间窗 / 相关键查 actor 自身 committed event log
• 跨 session preference / team memory 等需求 → 由对应 GAgent (User / Team) 的 state 直接表达
• agent 的"记忆"即它的 state + event log + projection——和它的"行为"在同一套结构里，不旁挂一套

[loning]

我的理解, 不应该有loop. 即便看起来是loop, 也是基于事件驱动的. 我在收到pong的时候发一个ping这种事件驱动.

[eanzhao]

愿景边界补充（2026-05-06）

这里的愿景建议收窄成“先 actor 化稳定 continuation state”，不要一开始 actor 化所有细节。

第一阶段最值得落地的是 run/session/turn 的权威状态：当前阶段、resume point、pending approval、tool ledger、timeout/retry lease、completion/failure reason。LLM token streaming、tool stdout/chunk、临时 parser 状态可以继续走旁路 stream / IO worker，只把稳定边界事件写回 actor。

也就是说，短期目标不是“重写 ChatRuntime 的所有内部执行”，而是让 RoleGAgent 拥有可恢复的 continuation contract；ChatRuntime 先降级为 IO worker，逐步从“loop runner”退出平台语义。

[loning]

ChatRuntime 感觉也不该存在.
实际上, 软件工程就是最好的Harness, 对于agents的组织形态, 管理学就是最好的Harness.

我们不该为了让系统看起来像实现了Harness而在做一些包装, 而是思考如果我们把Agent当成一个Human, 这样的组织形式能够让其目标明确、权限可控并且能够根据其历史行为进一步对其进行Harness约束从而提升其生产价值与效率.

比如一个论文编写过程, 我们可以写一个gate明确一些语法, 这样build failed时候AI就会处理, 同时也要改AI的提示词.

也就是说我们通过提示词要求AI, 给AI目标. 通过程序gates限制住AI.

aevatar的tool call 天然能限制很多, 如果加上scheme约束之类的就更清晰.

Loop的出现, 实际上是一种线性思维导致的结果, 本质上是把复杂的信息维度压缩在一根轴上, 这样会丢失大量信息.
实际上我建议大家的AI在思考问题时通过数学本身的逻辑链条来思考, 让他们去参考 newmath或automath的处理方式.

或者你们可以蒸馏一下我的skills, 也许可以更好的帮助大家理解我的一些思考的逻辑?

实际上进入复杂的思考模式是对的, 现在AI可以迅速的生成海量代码, 但好的代码可以处理很多问题.

为什么要研究数学, 因为一个好的数学结构可以投影很多问题.

深入讨论可以让我们一起来提升, 我也有很多问题想不清楚, 迭代起来挺好的

[eanzhao]

2. Tools / Skills / Plugins

Tools / Skills / Plugins 图

核心判断

Aevatar 不应该把自己做成一个大而全的 tools/plugins 平台。更合理的边界是：

• 外部 service / plugin 主要交给 NyxID。
• skills 的创建、搜索、分发、运行主要交给 Ornn。
• Aevatar 保留少量真正属于自身运行时的 native tools。

这样做的原因很直接：NyxID 当前公开 surface 已覆盖 credential、proxy、MCP、approval、agent binding、rate limit、audit 等方向；Ornn 当前公开 surface 已覆盖 skill package、search、generation、sandbox/runtime 等方向。但这不等于 Aevatar 已经原生接入这些能力，也不等于外部能力天然满足 Aevatar 的分布式运行时语义。Aevatar 如果每接一个服务就在本仓库写一个 typed provider，会绕开这些现成治理面，也会把维护成本压到 Aevatar 自己身上。

当前已经有的基础

Aevatar 现在并不是空白：

• IAgentTool / IAgentToolSource 是统一工具抽象。
• 工具可以声明 ApprovalMode / IsReadOnly / IsDestructive / RequiresApproval(argumentsJson)。
• IToolCallMiddleware 能拦截、改写、阻断工具调用，也能接 approval。
• NyxIdAgentToolSource 已经暴露 NyxID account/status/catalog/services/proxy/approvals/nodes/api keys/capability search 等工具。
• nyxid_proxy 和 nyxid_proxy_execute 已经能通过 NyxID proxy 调用下游服务。
• ornn_search_skills 和 use_skill 已经可以搜索/加载 Ornn 或本地 skill；当前 Aevatar 接入主要是搜索/加载 instruction，不是完整 Ornn runtime execution。
• Aevatar 还有 Lark、Telegram、Web、ChronoStorage、Workflow、Scripting、Binding、MCP 等 direct providers。

主要缺口

问题在于边界还没收敛：

• Direct external providers 太多，长期会变成 Aevatar 自己维护一套 plugin ecosystem。
• 现有 NyxIdAgentToolSource 已经能暴露一组 NyxID 工具，但还缺少统一、动态、版本化的 NyxID-backed capability source：从 NyxID 已连接 services/MCP surface 发现工具，并通过 NyxID proxy 调用。
• 工具列表已有 activation / config-change refresh，但缺少外部 catalog / service 变更驱动的 refresh：用户在 NyxID 连接/撤销 service 后，agent 可能不知道。
• Aevatar 本地 approval 与 NyxID approval 的职责边界还不够清楚。
• use_skill 目前偏“加载 instruction”，还不是完整 Ornn runtime skill execution。
• Ornn 接入主要覆盖 keyword search 和 package fetch，semantic search、version/provenance、runtime execution、artifact retrieval 还没充分接入。
• 非流式 tool metadata 传递存在风险，需要保证 NyxID/Ornn token/context 在所有工具路径都一致。

建议分层

建议明确三类工具：

1. NyxID-backed external tools

外部服务和 plugins 默认走 NyxID。Aevatar 负责发现、展示、调用上下文、capability lifecycle、run observation；credential、scope、approval、rate limit、audit 在 NyxID 当前公开契约范围内由 NyxID 管。

2. Ornn-backed skills

Skills 默认走 Ornn。Aevatar 负责搜索、选择、加载、运行委托、记录 skill usage；skill package、provenance、runtime/sandbox 由 Ornn 管。

3. Aevatar-native tools

只保留与 Aevatar 运行时内部强相关的工具，例如 self-memory inspection、workflow/binding 内部操作、ask_user、少量 actor/runtime 控制能力。

第一阶段最小闭环

• 盘点所有现有 providers，标记为 NyxID-backed / Ornn-backed / Aevatar-native / transitional。
• 新增或收敛一个 NyxID service/plugin tool source，优先复用 NyxID MCP/dynamic tools。
• 明确 direct Lark/Telegram/Web/ChronoStorage 这类 provider 的迁移策略。
• 对 Ornn 增加 version/provenance、semantic search、runtime execution 的接入计划。
• 所有 Aevatar-native tools 强制补 risk classification。

需要团队讨论的问题

• 哪些 direct providers 必须长期保留在 Aevatar？
• NyxID MCP 直接接入是否优于 Aevatar 自己把 endpoint schema 映射成 tools？
• Ornn runtime skill 的执行结果应该作为 tool result、run artifact，还是独立 skill run readmodel？
• Aevatar-native tools 的白名单应该放在哪里治理？

[eanzhao]

愿景边界补充（2026-05-06）

NyxID / Ornn 应该被当成外部公开 surface，而不是 Aevatar 的内部子系统。

Aevatar 需要自己拥有 capability lifecycle：工具身份、版本、水位、刷新触发、risk classification、run observation、usage ledger。NyxID 负责它边界内的 credential/proxy/approval/audit；Ornn 负责它边界内的 skill package/search/runtime。Aevatar 不应该假设外部仓库会为 Harness 补新接口。

当前 Ornn 接入尤其要说清楚：Aevatar 现在主要是 keyword search + instruction fetch/use，不是完整 runtime skill execution。semantic search、sandbox execution、artifact retrieval 都应作为后续接入项，而不是当前事实。

[potter-sun]

从产品和前端的角度来看，想确认一下是否合理：我支持统一做 Capabilities，而不是 Tools / Skills / Plugins 三个入口。用户要解决的是“这个 Agent 能做什么、是否安全、能不能用、这次 Run 怎么用的”。所以 V1 应该优先定义能力状态、来源动作、分配关系和 Run 调用展示，而不是先做插件市场。

[eanzhao]

从产品和前端的角度来看，想确认一下是否合理：我支持统一做 Capabilities，而不是 Tools / Skills / Plugins 三个入口。用户要解决的是“这个 Agent 能做什么、是否安全、能不能用、这次 Run 怎么用的”。所以 V1 应该优先定义能力状态、来源动作、分配关系和 Run 调用展示，而不是先做插件市场。

先能load ornn的skills就行了，应该不做插件市场，aevatar也不适合做插件市场。这一个模块跟前端没什么关系了应该。

[eanzhao]

3. Memory / Session — 本节作废

No Standalone Memory Module 图

作废（2026-05-06，采纳 @loning 反馈）

@loning 的判断：

"我觉得不需要做memory, 只要有足够的上下文让我处理信息就好了, 告诉我目标, 告诉我做什么, 我为什么要"记忆"?

如果连给我的工作都说不清楚, 而还要我的偏好, 那么结果一定不是好的.

因此, 不需要memory."

接受的理由

"Memory" 作为独立 Harness 模块是 trivial 抽象——它只是给已有结构（GAgent state + committed event log + projection / readmodel）起了个新名字，不产生任何新约束 / 新能力。

trivial 抽象的代价：

1. 新词覆盖已有结构，认知负担 +1
2. 容易被脑补成 LangChain 风格的旁路系统（vector DB / chat history / sidecar），偏离 actor-native 模型
3. 让"GAgent state + event log 就是真相"这个简单事实被淡化
4. 引入新模块就要配套写 contract / readmodel / API / 文档，全部是为命名服务，不是为能力服务

所谓 memory 的需求如何被已有结构覆盖

看起来像 memory 的需求	Aevatar 已有的对应物
Session memory	RoleGAgentState.sessions
Long-term state	任意 GAgent 的 state
Projection memory	Projection / Readmodel
User preference	User GAgent 的 state
Team memory	Team GAgent 的 state
Self-introspection	两个 tool（inspect_self_state / search_self_events）— 详见 §1

没有一项需要"Memory"这个新抽象层。

保留的能力

"agent 看自己的 state / event"这一部分能力作为 Continuation 模型的子集，已合并到 §1 Agent Continuation 的 "Self-Introspection" 子段。

关于本评论

保留评论位置（不删除评论）以维持 discussion thread 连贯，并保留 @loning 的 reply 上下文。

本节的演化轨迹（"五层 memory" → "fan-out 多视图" → "整节作废"）反而是 Discussion 形态的最佳例证：每一次重写都比上一次砍掉更多 trivial 抽象。这个过程本身值得作为团队架构反思的素材。

[eanzhao]

愿景边界补充（2026-05-06）

Memory 这块建议避免一上来做“通用长期记忆平台”或“vector store first”。

第一阶段应该从 RoleGAgent 已经有的 session/run 事实出发，投影 session summary、tool ledger、approval ledger、important state changes，并提供受治理的 self-memory query surface。Turn context 只是 LLM 当前窗口，不是权威 memory，不应该被当成持久状态。

跨 agent / team / project memory 如果有稳定业务语义，应由 aggregate actor 拥有，再 fan-out 到 readmodel；不要在 query path 临时 replay 或拼装。

[loning]

我觉得不需要做memory, 只要有足够的上下文让我处理信息就好了, 告诉我目标, 告诉我做什么, 我为什么要“记忆”?

如果连给我的工作都说不清楚, 而还要我的偏好, 那么结果一定不是好的.

因此, 不需要memory.

[eanzhao]

所谓的memory应该调整为agent的Self-Introspection：agent的自我反思能力

[loning]

自我反思能力是一个行为不是状态, memory是状态

[eanzhao]

4. Governance

重写（2026-05-06，采纳 @loning 反馈）

原文设计了中心化的 AgentGovernanceProfile（permission_mode / tool_rules / path_rules / connector_rules / memory_rules / budget_rules / approval_policy / audit_policy），并引入 AgentPolicyEvaluator 中心化判定。@loning 的判断：

"这种为了看起来像治理而构建治理的行为, 与数学中的一个词"平凡", 极其类似."

"治理框架只是为了让未来方便迭代而构建的体系, 而不是构建一种中心化AgentGovernanceProfile配置."

数学的"平凡（trivial）"指：形式上成立，但不增加任何新信息（如 0 是任何齐次方程的平凡解）。AgentGovernanceProfile 只是把已有规则编目，没有产生新约束。代价：

1. 治理盲点：config 写一套，代码做另一套——实际生效的永远是代码，profile 是装饰
2. 维护负担：多一套 contract / readmodel / 同步逻辑要维护
3. 掩盖真治理：让 type / schema / actor boundary 这些"违规无法表达"的真治理被忽视
4. 架构错觉：让人误以为加了 profile 就有治理

本节按四层无中心化 governance 重写。

Governance 图

核心判断

真正的治理 = 让违规无法表达，而不是"事先声明规则、运行时检查"。

约束分布在四层结构里，每层让特定类型的违规根本无法构造、无法发出、无法到达、无法越权：

Schema-level   ─► tool 自带 typed args / proto schema
                  违规调用根本无法构造（编译期 / 反序列化期失败）

Boundary-level ─► connector allowlist / NyxID scope / MCP 暴露面
                  违规请求根本无法发出（边界拒绝）

Actor-level    ─► GAgent 内聚的 command 接受 / 拒绝
                  违规命令到了 inbox 也被拒（actor 不变量保护）

Topology-level ─► 部门 parent / child link
                  越权命令根本不在 actor topology 路径上（不可达）

中心化 AgentGovernanceProfile 不在四层中——因为它不阻止任何东西，只描述已有约束。如果 profile 和实际代码不一致，实际生效的永远是代码。

@loning 的"管理学就是最好的 Harness"在治理层的对应物正是这四层：制度（schema）、流程（boundary）、岗位职责（actor）、组织架构（topology）。没有一家健康公司用"治理 config 中心"管所有事。

四层各自的当前状态与定位

1. Schema-level（最强约束）

已有：

• IAgentTool 的 typed signature；tool args 走 protobuf / typed JSON schema
• Workflow / scripting 的 typed input contract
• EventEnvelope 的 typed payload

应做：

• 强制所有 Aevatar-native tool 提供 typed args，禁止 free-form JSON 兜底
• Tool 的 risk classification（IsReadOnly / IsDestructive / RequiresApproval）作为 schema 元数据
• LLM tool call 必须先通过 schema validation 再 dispatch

特点：违规根本无法构造。最强、最便宜、最不可绕过。

2. Boundary-level

已有：

• HTTP / CLI / MCP connector 的 allowlist
• NyxID scope / approval / rate limit / audit
• nyxid_proxy 的 service id 限制

应做：

• 明确 connector allowlist 是"边界 hard rule"而非"配置建议"——绕过 allowlist 的任何兜底路径必须删
• NyxID-backed tool 的边界治理由 NyxID 管，Aevatar 不重复
• Aevatar-native connector 列出可信调用源（哪些 GAgent / scope 可以发起）

特点：违规请求根本发不出去。

3. Actor-level

已有：

• GAgent 自己决定接受 / 拒绝哪些 command（事件处理逻辑天然内聚）
• RoleGAgentState 的 pending approval 机制
• Workflow run 的 step admission

应做：

• 明确 actor 拒绝 command 时返回 typed CommandRejected 事件（详见下文 Denied Ledger）
• 拒绝原因强类型化：Unauthorized / OutOfScope / InvariantViolated / RateLimited / BudgetExceeded
• approval 统一为"actor 接受请求 → emit ApprovalRequested → 等 ApprovalDecided 事件 → 继续/拒绝"——和 §1 Continuation 同一套世界观

特点：违规命令到了 inbox 也无法推进 actor 状态。

4. Topology-level

已有：

• parent / child link
• scope GAgent 持有它管辖范围
• Stream forwarding topology

应做：

• 明确"部门"GAgent 拥有它的下属——下属的 cross-scope 命令必须经部门转发或在部门约束内
• 跨 scope 调用必须显式 cross-link，不能默认连通
• Topology 本身就是组织级权限（详见 §5 Multi-Agent）

特点：越权命令根本不在 actor topology 路径上。

应该明确删除的设计

• ❌ AgentGovernanceProfile 中心化对象——不存在、不引入
• ❌ AgentPolicyEvaluator 中心 evaluator——不存在、不引入
• ❌ 任何"先声明规则、运行时统一查"的中心 service
• ❌ 把 hooks 当 hard gate 用（hooks 是 best-effort，见下文）

Hooks 的定位（明确分责）

Hooks（pre-tool / post-sampling / pre-connector / pre-command-dispatch / failure / stop）是 best-effort 旁路，不承担 hard gate：

• ✅ 适合：trace / metrics / notification / 辅助审查 / debug 观察
• ❌ 不适合：安全门禁 / 权限判定 / 拒绝执行

Hard gate 必须在四层结构内（schema / boundary / actor / topology），由结构本身阻断。Hook 失败不阻断主流程是设计特性，不是 bug——它强迫真治理走结构而不是走 hook。

Denied Ledger（保留可观察性，不引入新治理对象）

被拒绝的 tool call / command / connector 调用，作为事件进 readmodel ledger（不只是 log）：

• CommandRejected(reason, layer, agent_id, scope_id, ...)
• ToolCallDenied(tool, reason, schema_violation_field?, ...)
• ConnectorRequestBlocked(connector, allowlist_rule, ...)

便于 audit / debug / 申诉。它是事后可观察性（fan-out 视图，见 §1），不是事前治理逻辑——不要把它和 governance config 混淆。

第一阶段最小闭环

• 盘点所有 Aevatar-native tools，强制补 typed schema + risk classification（schema-level）
• 明确所有 connector allowlist 是 hard boundary，绕过路径必须删（boundary-level）
• 给 GAgent 的 command 拒绝路径定义 typed CommandRejected 事件（actor-level）
• 不引入 AgentGovernanceProfile / AgentPolicyEvaluator / 任何中心化 policy 对象
• Denied ledger 作为 readmodel 提供给 audit / approval UI

需要团队讨论的问题

• 跨 scope 调用的"显式 cross-link"应该是声明式（in proto / manifest）还是命令式（runtime grant）？谁有权创建这种 link？
• NyxID-backed tool 在 Aevatar 这一侧还需不需要二次 deny？还是完全信 NyxID 边界？
• CommandRejected 事件是否所有 GAgent 默认 emit，还是按需声明？
• approval UI / channel 优先在 Aevatar 自己做，还是路由到 NyxID？

[eanzhao]

愿景边界补充（2026-05-06）

Governance 的愿景要区分 hard gate 和 best-effort hook。

Hooks 适合 trace、metrics、notification、辅助审查；真正的安全门禁必须是 fail-closed policy evaluator，并且在 pre-tool、pre-connector、pre-command-dispatch 这些关键点返回 typed decision。被拒绝也应该进入 denied ledger，而不是只变成错误字符串或日志。

NyxID 可以承担外部 service 边界的审批、凭证和审计，但 Aevatar 仍要在自己的 run/session/scope 语义里做二次治理，尤其是 Aevatar-native tools、actor command、memory mutation、workflow/scripting 操作。

[loning]

这种为了看起来像治理而构建治理的行为, 与数学中的一个词“平凡”, 极其类似.

治理框架只是为了让未来方便迭代而构建的体系, 而不是构建一种中心化AgentGovernanceProfile配置.

[loning]

Hooks 的定位.

所有的agents在定义过程中会定义自己的harness, 只需要提供继承关系或者tools就可以, 不需要有包含语义的Hooks.

即便是有, 那也是对于某一个GAgent基类, 有一些专门的Hooks、Gates.
也就是说, 这些都应该跟某些有语义的GAgent基类绑定.

[eanzhao]

5. Multi-Agent

重写（2026-05-06，采纳 @loning 反馈）

@loning 在本节给出了完整替代方案：

"按照公司或者组织架构进行设计.. 一个部门是一个GAgent, 一个公司是一个部门. 一个部门下面可以有许多员工, 也可以有许多部门."

"为什么要有 TaskBoardGAgent 这种奇怪的东西?"

"我通过workflow已经明确定义了我处理什么消息, 我如何处理. 那我等着消息来就可以了. 然后有 StreamProxy 把外部的事件传进传出系统. 我为什么还要关心去哪里拿任务?"

"即便是任务分发, 那也是一个部门在收集任务, 一个部门在分发任务. 为什么动不动的就要搞个新抽象?"

接受。TaskBoardGAgent / TeamManagerGAgent 作为平台 primitive 是 trivial 抽象——它们只把已有的 parent/child + 消息 包装成新名字，没产生新约束 / 新能力。

本节重写为组织架构模型。TeamManagerGAgent / TaskBoardGAgent 退回 application-level example pattern，不再作为 platform primitive 提出。

Multi-Agent 图

核心判断

Aevatar 的 Multi-Agent 模型直接对应现实组织架构——不引入"中介者"、"任务板"等程序员常见的 mediator pattern。

Company (GAgent)
  ├── Department A (GAgent)
  │     ├── Employee A1 (GAgent)
  │     ├── Employee A2 (GAgent)
  │     └── Sub-Department A.x (GAgent)
  │           ├── Employee A.x.1 (GAgent)
  │           └── ...
  └── Department B (GAgent)
        └── ...

每个 GAgent 既可以是叶子（员工），也可以是父节点（部门）。
Manager 行为：给 child 发消息（"做这个"）
Worker 行为：完成后给 parent 发消息（"做完了"）

这是 fractal topology——同一种 actor 抽象按 parent/child 组合出任意层级，没有特殊的 "manager actor" 或 "task board actor"。

Platform Primitive（仅此而已）

Aevatar Multi-Agent 平台层只需要三件事：

1. GAgent（actor 抽象，已有）
2. parent / child link（topology，已有 OrleansActorRuntime.LinkAsync）
3. 消息（已有 SendToAsync / PublishAsync）

所有"组织模式"（CEO 部门 / 研发部门 / 评审部门 / 任务分发 / 多 worker 并行）都是这三个 primitive 在运行时的编排，不是新平台对象。

判定标准：如果一个能力可以通过 已有 primitive + 业务逻辑 表达，它就不是 platform primitive，它是 application-level pattern。

当前已经有的基础

• GAgentBase + Orleans grain 承载 actor identity 与 inbox
• EventEnvelope direct route + publication route
• IEventPublisher 区分 PublishAsync / SendToAsync
• OrleansActorRuntime.LinkAsync(parent, child) 建 parent / child topology
• StreamTopologyGrain 持久化 topology
• 静态 [EventHandler] + 动态 IEventModule 的事件处理 pipeline
• RuntimeActorGrain 通过 stream 接收 envelope

这些已经是充分的 multi-agent runtime。

TeamManagerGAgent / TaskBoardGAgent 退回 example

这两个不再是平台 primitive，而是 application-level example pattern——展示如何用 GAgent + parent/child + 消息 表达"经理-员工"和"任务分发"模式。

具体退回方式：

• TeamManagerGAgent → 移到 examples/ 或 samples/，命名改为业务名（如 EngineeringTeamGAgent）
• TaskBoardGAgent → 同上，作为"分发部门"的具体实现示例
• 文档明确：这些是"参考实现"，不是平台 SDK 的一部分

主要缺口（重新定义）

不再是"缺少 TeamManager / TaskBoard 平台 primitive"，而是：

1. 缺少组织模式 example library

需要把以下模式作为 application-level example 沉淀，全部用 GAgent + parent/child + 消息 实现，不引入新平台对象：

• 经理-员工
• 评审-提交（reviewer / submitter）
• 分发-汇报（dispatcher / reporter）
• supervisor-worker
• 跨部门协作（lateral message between departments under common parent）

2. 缺少 Agent-to-agent protocol descriptor

GAgent 需要声明：

• 入站 / 出站事件类型
• 超时 / 重试语义
• 能否被跨 scope 寻址
• 哪些事件需要 approval

这是 schema-level 治理（详见 §4），属于 GAgent 自身元数据，不是新 actor 类型。

3. 缺少 topology readmodel

需要 readmodel 暴露：

• 当前 topology graph
• 消息 ledger
• agent 健康
• pending reply / timeout

这是 fan-out 视图（详见 §1 Agent Continuation），不是新 actor 类型。

4. 缺少跨 agent governance 的明确表达

哪个 agent 可以给哪个 agent 发什么 command，哪些事件可跨 scope，哪些 link 需要审批——这是 §4 Governance 的 topology-level，不是新 actor 类型。

第一阶段最小闭环

• 把 TeamManagerGAgent / TaskBoardGAgent 从"platform primitive 候选"降级为 application-level example
• 整理一个最小 example library：CEO 部门、研发部门、reviewer、分发-汇报模式（全部用 GAgent + parent/child + 消息 表达）
• 定义 AgentProtocolDescriptor（schema-level 元数据，归属 §4 Governance 范畴）
• 投影 TopologyReadModel / MessageLedger（fan-out 视图，归属 §1 范畴）
• 跨 agent 调用治理纳入 §4 的 topology-level

需要团队讨论的问题

• "部门 GAgent" 是一个统一基类，还是任何 GAgent 都可以有 child？倾向后者——任何 GAgent 都是 fractal node。
• workflow / scripting 是不是另一种 manager 部门的具体实现？还是和 multi-agent 平行的概念？
• StreamProxy 在组织架构里是什么角色？@loning 提到"StreamProxy 把外部事件传进传出"——它对应"对外联络部门"还是"基础设施 / 网关"？
• Agent protocol descriptor 是 code discovery、proto option 还是 manifest 生成？

[eanzhao]

愿景边界补充（2026-05-06）

Multi-Agent 的愿景可以成立，但不要把已有 TeamManagerGAgent / TaskBoardGAgent 直接等同于 Codex-like 多 worker 系统。

当前代码已经有成员、广播、任务、原子 claim 等基础 primitive；要走到多个 worker 并行处理同一目标，还需要 artifact/work lease/conflict detection/merge result/review decision 这些强类型契约。否则只能表达“分任务”，不能表达“并行修改同一产物并合并”。

第一阶段建议先做 run-scoped team/taskboard + message/task/readmodel + governance；artifact lease 和 merge/review 作为第二阶段。

[loning]

StreamProxy 的继承问题确实是,如果StreamProxyGAgent继承RoleGAgent,实际上可以完成一些功能.

还有就是StreamProxyGAgent 未来支持多模态的话, 那么RoleGAgent现在不能处理多模态. 整个体系感觉是要用策略模式之类的.把流处理能力封装.

我希望大家未来这样考虑问题.

[loning]

按照公司或者组织架构进行设计..

一个部门是一个GAgent, 一个公司是一个部门.
一个部门下面可以有许多员工,也可以有许多部门.

为什么要有TaskBoardGAgent 这种奇怪的东西?

[loning]

我通过workflow已经明确定义了我处理什么消息, 我如何处理. 那我等着消息来就可以了. 然后有StreamProxy把外部的事件传进传出系统. 我为什么还要关心去哪里拿任务?

[loning]

即便是任务分发, 那也是一个部门在收集任务, 一个部门在分发任务.
为什么动不动的就要搞个新抽象?

[AbigailDeng]

基于目前 docs/designs 里的 Team-first / Scope = Team 方向，我整理了一版 Aevatar Console / Studio 的产品形态草案，想请大家帮忙确认这个 IA、页面关系以及第一版 scope 是否合理。

这版主要想表达几个判断：

1. Console 的核心对象是 Team

   • 用户首先进入“我的团队”
   • 从团队列表点击某个团队卡片 / 行，进入该团队的概览页
   • 每个 Team 下面看运行概览、事件拓扑、事件流、团队成员、连接器和高级编辑

2. Studio 不是整个产品壳，而是 Team 内部的成员/行为编辑器

   • 从 Team Detail 的团队成员、行为配置或高级编辑入口进入 Studio
   • Studio 主要负责行为定义、脚本行为、Agent 角色、集成、设置和测试运行

3. “待处理事项”不是一个独立任务系统

   • 它只是 Team Overview 上聚合异常状态
   • 例如连接器断开、人工审批、测试运行失败、事件流异常
   • 点击后应该跳到对应的 Team Detail 页面或 Studio Test Run

另外有一个 scope 问题想确认：

• 事件拓扑 / 事件流 / 测试运行这三个运行视图，第一版是否还需要处理？
• 我印象里之前会上提过第一版可能暂时做不了这一部分，如果是这样，是否应该先把它们作为后续阶段能力，只在 IA 上预留入口？

下面是当前草案里的几个关键页面，想重点确认：

• Team-first 的导航结构是否合理？
• 从“我的团队”进入“团队概览”的路径是否清楚？
• Team Detail 和 Studio 的边界是否清楚？
• “连接器”和“团队成员”是否应该作为 Team Detail 下的一等页面？
• 如果事件拓扑 / 事件流 / 测试运行第一版不做，当前 IA 应该如何降级展示？

说明：这版主要用于确认 IA、产品对象关系和阶段 scope，视觉和中文排版还会继续 polish。

1. 团队列表 / Team-first entry

2. 团队概览

3. 事件拓扑

4. 构建团队

5. Aevatar Studio - 行为定义

6. Aevatar Studio - 测试运行

[AbigailDeng]

补充一个 user story / 页面链路视角，方便后续讨论时不只看“页面是否齐”，也看用户能不能从目标一路走到结果。

核心链路

1. 从团队列表进入团队概览

   • 我的团队 / 团队管理中心 -> 点击某个团队卡片或团队行 -> 团队详情 - 概览
   • 这里需要确认：团队卡片是否应该整体可点击，还是需要显式的“进入团队 / 查看详情”入口。

2. 创建一个新团队

   • 我的团队 -> 构建团队 -> 团队目标 -> 添加成员 -> 连接器 -> 创建 -> 新团队概览
   • 如果第一版不做完整向导，是否先降级为：团队名称 + 目标 + 创建空团队，成员和连接器后续在 Team Detail 中配置。

3. 查看团队健康状态

   • 团队概览 -> 待处理事项 / 运行洞察 / 团队成员摘要 / 连接器摘要
   • “待处理事项”不是独立任务系统，而是概览页上的异常聚合。
   • 每个待处理事项都应该有明确去向，例如：连接器异常 -> 连接器页；人工审批 -> Studio Test Run；事件失败 -> 事件流或事件详情。

4. 管理团队成员

   • 团队概览 -> 团队成员摘要 -> 查看全部 -> 团队成员列表 -> 编辑成员 -> Aevatar Studio / 成员编辑器
   • 需要确认成员列表里哪些操作进入 Studio，哪些只打开成员详情 / 状态抽屉。

5. 管理连接器

   • 团队概览 -> 集成连接器摘要 -> 管理配置 -> 连接器管理
   • 连接器页至少需要表达：添加连接器、测试连接、重新连接、查看被哪些成员使用。
   • 如果第一版只做展示，需要明确连接器页是 read-only 还是可配置。

6. 调查一次异常

   • 理想链路：团队概览的待处理事项 -> 事件流中的异常事件 -> 查看拓扑路径 -> 进入相关成员的 Studio 测试运行
   • 也可以反向：Studio 测试运行 -> 在事件流中查看 -> 查看该 run 产生的事件 -> 在事件拓扑里看经过哪些节点
   • 这里需要确认第一版是否做事件拓扑 / 事件流 / 测试运行。如果第一版做不了，建议 IA 上预留入口，但产品里不要让用户点进空页面。

7. 编辑并测试一个成员行为

   • 团队成员列表 -> 编辑某个成员 -> Studio 行为定义 -> 应用更改 -> 测试运行 -> 发布 / 返回团队概览
   • 这里需要补充编辑生命周期：保存草稿、测试版本、发布、回到团队详情、处理失败状态。

当前草案基本覆盖的页面

• 我的团队 / 团队管理中心
• 构建团队
• 团队详情 - 概览
• 团队详情 - 事件拓扑
• 团队详情 - 事件流
• 团队详情 - 团队成员
• 团队详情 - 连接器
• Aevatar Studio - 行为定义
• Aevatar Studio - 测试运行

仍需要补齐或确认的部分

• 团队列表到团队概览的明确入口。
• 团队概览中每个待处理事项的目标页面。
• 团队成员到 Studio 的编辑入口，以及成员详情 / 状态抽屉是否需要。
• 连接器添加、测试、重新连接、绑定成员的流程。
• Studio 的保存草稿、测试、发布、返回团队详情流程。
• 事件拓扑 / 事件流 / 测试运行如果第一版不做，需要明确：隐藏、禁用、只展示摘要，还是只在 IA 中预留。
• 空状态、错误状态、无权限状态、加载状态。
• “部署项目”背后的流程：部署什么版本、部署到哪里、如何看结果、如何回滚。

我的理解是：这套图作为产品方向讨论已经够用了；但如果要变成第一版产品规格，还需要先收敛 scope，并把上述关键跳转和状态补上。

[AbigailDeng]

补充一下这一轮 Aevatar Console / Studio 设计 patch 的当前状态。这个版本不是在重新定义 IA，而是在前面已经讨论过的 Team-first 结构上，把几个关键用户链路补齐。

1. 当前产品结构的收敛

这一轮我理解的核心结构是：

Console = 团队级运维与治理入口
Team Detail = 一个团队的状态、成员、连接器、事件与部署
Studio = 团队内部某个成员 / 行为的编辑与测试工作台

也就是说，Studio 不再作为一个新的一级产品壳出现，而是从 Team Detail 的成员行为进入。用户的上下文应该始终能回答三个问题：

我在哪个团队？
我正在编辑哪个成员？
我正在发布哪段行为？

2. 团队成员页：补齐进入 Studio 的入口

团队成员页这一轮补的不是更多 dashboard 指标，而是把成员级操作链路补上：

团队成员页
-> 查看状态
-> 编辑行为：进入 Studio 行为定义
-> 测试运行：进入 Studio 测试运行

由于表格右侧空间有限，长中文按钮很容易被截断，所以当前方向改成 icon actions：查看 / 编辑 / 测试。这个方向我认为是对的，适合 Console 的信息密度。

注意：这张图里右侧最后一个 icon 仍有一个 __OUT 的 icon-font 导出残留，这属于视觉导出问题，不是产品 IA 问题。最终图需要修掉这个渲染瑕疵，但链路方向可以先拿来讨论。

3. Studio 发布闭环

之前比较缺的是：用户在 Studio 里改完行为之后，发布动作结束后应该回到哪里。

我建议的闭环是：

Studio 编辑成员行为
-> 发布确认
-> 发布中 / 发布成功 / 发布失败
-> 成功后返回团队概览或团队成员页

这里的发布对象不应该是泛化的 Project，而应该表达成当前上下文里的对象：

客户支持团队 / Intake Agent / 客服接待流程

发布确认态：

发布失败态：

成功态目前也已经收敛为：

发布成功
-> 返回团队概览
-> 返回团队成员页
-> 查看发布日志

这比“返回团队列表”更合理，因为发布完成后用户仍然处在当前 Team context 里。

4. 连接器页的定位

连接器管理页应该继续放在 Team Detail 下，而不是 Studio 下。

原因是连接器是团队可复用资源，不是某一个行为编辑器内部的局部配置。一个连接器可能被多个成员使用，所以它更适合在 Team Detail 里表达：

Team Detail / 连接器
-> 添加连接器
-> 测试连接
-> 重新连接
-> 查看使用成员

如果某些连接器能力 V1 还不能完整支持，可以保留入口并标注 即将上线，但不建议把连接器塞回 Studio 里。

5. 还需要团队确认的问题

我觉得现在可以基于这几条继续讨论：

1. 团队成员 -> 编辑行为 / 测试运行 -> Studio 这个入口方向是否成立？
2. 发布成功后的主返回路径是否应该固定为 团队概览 和 团队成员页？
3. 发布失败态是否只需要 重试发布 / 取消，还是也需要 查看发布日志？
4. 事件拓扑 / 事件流 / 测试运行 如果 V1 做不了完整能力，是保留入口并做 minimal readable state，还是先从可见 IA 里隐藏？
5. 连接器是否确认作为 Team-level resource，而不是 Studio-level config？

我的当前判断：产品链路已经基本收敛，可以继续拿这版讨论；但团队成员页那张图还需要修掉 icon-font 导出残留后，才能作为最终视觉稿使用。

[potter-sun]

我先按当前项目的后端契约和 V1 可落地范围给一个判断：这版 Team-first / Member-first 的方向是成立的，但运行视图需要降级表达，避免把愿景页面做成空壳。

1. 团队成员 -> 编辑行为 / 测试运行 -> Studio 这个入口方向成立。

Studio 不应该再作为一个独立产品壳出现，而应该吃显式上下文：scopeId / teamId / memberId。用户进入 Studio 后始终知道自己在哪个 Team、正在编辑哪个 Member、要发布哪段行为。当前后端边界也基本支持这个方向：已有 Team endpoints、Member endpoints、Team -> Members 查询、Member binding、binding-run status、member endpoint contract 等能力。

但这里要注意一个字段语义问题：即使产品文案里继续强化 “Team-first / Scope = Team”，前端路由和 DTO 里也不要把 scopeId、teamId、memberId 混成一个字段。当前最好显式保留三者，这样后续 scope 是否继续等价于 team、或一个 scope 下是否有多个 team，都不会污染 IA。

2. 发布成功后的主返回路径建议固定为 团队概览 和 团队成员页，不要回到团队列表。

发布完成后用户仍在当前 Team context 里，返回团队列表会打断上下文。发布成功态可以保留：

返回团队概览
返回团队成员页
查看发布日志 / binding run detail

发布对象文案也应该使用当前上下文对象，例如：

客户支持团队 / Intake Agent / 客服接待流程

不要再写成泛化的 Project。

3. 发布失败态建议 V1 至少保留 重试发布、返回编辑 / 取消、查看发布日志。

原因是 member binding 本身是异步协议：PUT /binding 的 202 Accepted 只表示 command accepted，真正完成态要看 binding-run/readmodel。因此失败态不能只做 toast，也不应该只剩“重试/取消”。查看发布日志 或 查看详情 至少要能落到 binding run status / failure reason，否则用户不知道失败发生在 admission、platform binding、member notification 还是最终发布阶段。

4. 事件拓扑 / 事件流 / 测试运行 V1 建议这样降级：

• 测试运行：可以保留在 Studio 内作为 member-level action，但只展示当前 member / 当前 run 的真实状态，不承诺完整 team run observability。
• 事件流：先做 member/run scoped activity 或 binding/test run timeline，不做 Team 级总事件流。
• 事件拓扑：如果没有真实 Team-level topology readmodel，V1 不建议作为可点击主 tab。可以在 IA 图里预留，但产品里要么隐藏，要么显示明确的 “即将上线 / 暂不可用”，不要让用户进入空页面。

当前 runtime 有 EventEnvelope、parent/child topology、stream forwarding 这些底座，但这不等于已经有可产品化的 Team 级事件拓扑/事件流 readmodel。V1 里应该优先展示真实可解释的数据。

5. 连接器确认应作为 Team-level resource，而不是 Studio-level config。

这个判断我同意。连接器是团队可复用资源，一个连接器可能被多个成员使用；Studio 只应该选择/引用某个 member 可用的 capability 或 binding，不应该承担连接器凭证、重连、使用成员关系这类团队级管理职责。

如果 V1 连接器的添加、测试、重新连接还没完整接上，可以把 Team Detail / 连接器页做成 read-only 或 minimal management，但不要塞回 Studio。

另外团队成员页改成 icon actions 的方向也对，适合 Console 的信息密度。视觉稿里的 __OUT 属于导出瑕疵，修掉即可，不影响 IA 方向。

[AbigailDeng]

没看懂“事件拓扑 / 事件流 / 测试运行”这部分说的啥意思，我印象里之前会上后端提过第一版可能暂时做不了这一部分，那能不能直接隐藏？

[AbigailDeng]

补充这一轮 Console mockup 的更新：这次主要不是继续扩 IA，而是把“一个用户进来以后到底怎么创建团队、点哪里、到哪里、看什么”这条链路补清楚。

我现在建议把这次补充分成两条线看：

主链路：创建团队 walkthrough
补充链路：首页待处理事项的分流去向

1. 创建团队 walkthrough

这条链路现在是：

我的团队
-> 构建团队
-> 步骤 1：团队目标
-> 步骤 2：添加成员
-> 步骤 3：连接器
-> 步骤 4：创建确认
-> 创建成功
-> 团队概览

这版想表达的产品判断是：

• 创建 Team 时先让用户说清楚“这个团队要解决什么业务问题”，不要一上来暴露底层协议、登录系统或 Studio 细节。
• Team 是用户创建和管理的主对象。
• 创建团队时只配置团队目标、初始成员和外部通道。
• Studio 不是创建团队流程的一部分；Studio 应该从创建后的 团队成员 -> 编辑行为 / 测试运行 进入。
• 连接器是 Team-level resource，可以创建时选择，也可以创建后在 Team Detail 里补齐。

入口：我的团队

用户进入 Console 后先看到团队列表。这里的 构建团队 是创建团队的主入口。

步骤 1：团队目标

第一步只做三件事：

• 团队名称
• 团队目标
• 业务场景模板

模板只是初始建议，不应该把某个例子写死成产品结构。比如“交易风控团队”“客户支持团队”“内容审核团队”都只是可选场景，用户也可以从自定义团队开始。

步骤 2：添加成员

第二步让用户确认初始成员组合。这里先表达“团队由哪些成员协作完成目标”，不在这里展开 Studio 的行为编辑细节。

示例成员：

• Intake Agent：接收外部消息并创建运行
• Risk Review Agent：判断风险并推进分支
• Human Review Agent：承接人工确认任务

这个页面里也明确了一个边界：真正编辑成员行为，应在团队创建后从 团队成员 -> 编辑行为 进入 Studio。

步骤 3：连接器

第三步配置连接器。连接器是团队和外部业务系统之间的通道，例如消息、API、数据库或通知。

这里我建议不要把连接器做成创建团队的强制前置条件。用户可以现在连接，也可以创建团队后在 Team Detail 的连接器页继续补齐。

步骤 4：创建确认

第四步是创建前确认，汇总：

• 团队信息
• 初始成员
• 连接器选择

这里需要特别避免和“发布行为”混在一起。创建团队只是创建 Team shell 和初始成员；某个成员行为的测试、发布、失败处理，仍然应该从 Team Detail 进入 Studio 后完成。

创建成功

创建完成后，用户应该有两个明确出口：

• 进入团队概览
• 返回我的团队

这个成功页也提示下一步：配置成员行为、补齐连接器、查看运行状态。

2. 待处理事项的去向

前面讨论过 待处理事项 不应该被设计成一个独立 Inbox。它更像是 Team-first Console 首页上的 operation action summary：告诉用户有哪些事情需要处理，并把用户带回对应的业务页面。

现在建议先按类型分流：

连接器异常 -> 连接器页
生产人工任务 -> 运行详情 / 人工任务详情
发布失败 -> 发布日志详情
测试运行失败 -> Studio 测试运行

待处理事项列表

当用户点击“查看全部待处理”，可以进入这个汇总页。它不是独立任务系统，而是把所有需要动作的事项按类型、团队、对象和优先级展示出来。

人工任务详情

如果是生产运行中的人工确认任务，不建议跳到 Studio Test Run。它更像是一个运行中的人工处理页面，例如 退款确认 Run #084。

发布日志详情

如果是发布失败，应该有一个专门的发布日志详情页。这样用户能看到失败原因、时间线、日志和下一步动作，而不是只在 toast 或发布结果页里丢一句错误。

3. 当前这轮实际改动 / 补充的页面

01 我的团队首页                已改：补齐构建团队入口
12 创建团队步骤 1：团队目标    已重写：从混合配置页收敛为目标页
16 创建团队步骤 2：添加成员    新增
17 创建团队步骤 3：连接器      新增
18 创建团队步骤 4：创建确认    新增
19 创建成功页                  新增

13 待处理事项列表              新增
14 人工任务详情                新增
15 发布日志详情                新增

4. 想请大家重点确认的问题

1. 创建团队是否应该按 团队目标 -> 添加成员 -> 连接器 -> 创建确认 这条向导走？
2. 创建团队时是否只创建 Team shell + 初始成员，而不进入 Studio？
3. Studio 入口是否固定从 团队成员 -> 编辑行为 / 测试运行 进入？
4. 连接器是否确认作为 Team-level resource，而不是 Studio 内部配置？
5. 首页 待处理事项 是否按类型分流到具体页面，而不是做成独立 Inbox？
6. 生产人工任务是否需要专门的运行 / 人工任务详情页，而不是放进 Studio Test Run？
7. 发布失败是否需要独立的发布日志详情页？

我的当前判断：如果 V1 要先收敛，优先保证这两条链路能讲通：

创建团队：我的团队 -> 创建团队向导 -> 创建成功 -> 团队概览
编辑行为：团队概览 -> 团队成员 -> Studio -> 测试运行 -> 发布结果 -> 回到团队

事件拓扑 / 事件流 / 测试运行这类能力可以继续讨论 V1 是否展示完整页面，但不要影响上面这两条基础链路的清晰度。

[AbigailDeng]

补一张刚才漏掉的 02-team-overview 更新版。这个页面应该放在创建团队 walkthrough 和后续 Studio 链路之间，作为 Team Detail 的主落点。

也就是说创建成功后的主路径应该是：

创建成功
-> 进入团队概览
-> 查看团队运行摘要 / 健康依据 / 团队详情摘要
-> 再进入团队成员、连接器、事件流或事件拓扑

这张图里我觉得比较重要的点是：

• 团队概览 不再试图展开所有库存列表，而是作为团队级状态页。
• 概览页回答的是“当前团队是否正常、最近发生了什么、是否需要人工介入”。
• 团队成员、连接器、事件流 / 事件拓扑 都作为入口存在，不在概览页里塞满细节。
• 右上角 打开团队工作台 可以继续讨论是否保留；如果保留，需要明确它是进入团队成员 / Studio 的快捷入口，还是另一个独立工作台。

所以目前完整的基础链路应该补成：

我的团队
-> 构建团队向导
-> 创建成功
-> 团队概览
-> 团队成员 / 连接器 / 事件流 / 事件拓扑
-> 从团队成员进入 Studio 编辑与测试行为

这个页面我建议作为 V1 必做页，因为它是 Team-first Console 里最重要的落点：用户创建团队、进入团队、发布行为返回团队，最后都应该回到这里。

[AbigailDeng]

补充今天已经收敛过的一组页面，主要是 团队成员页 -> Studio 成员行为编辑页 这条链路。

这轮重点不是扩 IA，而是把页面从“开发实现展示”收回到用户能理解的 member-first 操作路径：

团队概览
-> 团队成员
-> 编辑某个成员的行为
-> 保存草稿 / 测试草稿 / 发布新版本
-> 查看运行日志或发布记录

1. 团队成员页

这页现在定位为 member management list，不再放多余 dashboard 区块。表格里每个成员都围绕真实成员模型展示：

• 成员职责
• 实现方式：Workflow / Script / GAgent
• 发布服务和版本
• 生命周期：created / build ready / bind ready
• 最近运行
• 操作：编辑 / 测试 / 日志

这里的判断是：用户从团队进入后，应该先看到“这个团队有哪些成员、每个成员现在是否可用、我要点哪里编辑或测试”。

2. Studio：成员行为定义页

这页按代码里的 member-first 实现重新收敛了一版。它不再把 NyxID/Auth 或泛化流程概念放进产品叙事，也不再暴露 API route、read model、request body、ImplementationRef / LastBinding 这类后端字段。

当前页面表达的是：

我正在编辑 Intake Router 这个团队成员的 Workflow 行为。
我可以保存草稿、测试草稿，确认后发布新版本。
发布后团队成员页会看到新的版本号。
线上运行日志可以单独查看。

页面结构：

• 左侧：当前成员、线上版本、未发布草稿、发布记录入口
• 中间：成员内部 Workflow 行为流程，展示步骤、分支和输出
• 右侧：选中步骤的设置、发布状态、测试当前草稿、线上运行日志

3. 想请大家重点看

1. 团队成员 -> 编辑行为 -> Studio 这个入口是否已经足够清楚？
2. Studio 里是否应该继续用“发布新版本”作为用户词，而不是暴露 binding 这类实现词？
3. Workflow 类型成员的编辑页，是否接受现在这种“行为流程 + 步骤设置 + 草稿/发布/测试”的布局？
4. Workflow / Script / GAgent 作为成员实现方式是否足够清楚，还是需要在成员页加更明确的解释？
5. 运行日志和发布记录分开是否合理：运行日志看线上调用，发布记录看版本发布过程。

我的当前判断：这两页已经可以作为 member-first Studio 链路的基准稿继续讨论；下一步可以再分别看 Script / GAgent 成员进入 Studio 时是否需要不同的编辑页形态。