[Onboarding Exam] 后端 / 架构入门测验

[eanzhao]

Aevatar 后端 / 架构入门测验

目标读者：会参与 aevatar 后端、架构、平台能力改造的同事
答题时长：约 90 分钟
AI 工具：允许（包括 Cursor/Claude Code/ChatGPT/Copilot 等）

如果你是前端同事，只需要掌握基础架构边界，不需要做这 8 道全量题。请做：

• frontend-architecture-basics.md — 约 40 分钟，关注 Command / Query / ReadModel / Observation / ACK 语义，以及前端不应依赖的后端细节。
• 前端版有自己的精简必读清单（在该题面顶部），不需要读完下面后端版的必读材料。下面那份是后端 / 架构方向的全量清单。

为什么这个测验值得做

允许用 AI 答题，恰恰是因为这套题不奖励"AI 顺手生成的标准答案"。Aevatar 的设计规范、模块边界、与 Discussion #568 之间的差距，只有把 CLAUDE.md / ADR / 关键源文件读穿才答得对。AI 帮你检索和组织语言，但代码引用、文件路径、行号、变量名、规则原文必须由你确认到本仓库当前状态。

如果你能在 90 分钟内交出一份证据扎实的答卷，说明你已经具备独立改 aevatar 的最低门槛。

必读材料

答题前先粗读，答题中按需精读。

仓库内：

• 根目录 CLAUDE.md — 顶级架构约束、Actor / Projection / 命名 / 序列化 / 文档 / 测试 规则
• 根目录 AGENTS.md — 配套工程约束（含外部仓库改动权）。如果它和 CLAUDE.md 表述不同，以当前分支实际生效的仓库约束为准，答题时写清楚引用的是哪一份。
• docs/canon/architecture-vocabulary.md — Module / Interface / Depth / Seam / Adapter / Leverage / Locality
• docs/canon/architecture.md — 整体分层
• docs/canon/cqrs-projection.md — 投影主链路
• docs/canon/role-model.md — RoleGAgent / 工具 / 中间件
• docs/canon/workflow-runtime.md — Workflow run 语义
• docs/adr/ — 全部 ADR；尤其 0006 / 0009 / 0011 / 0013 / 0014 / 0015 / 0019 / 0020

仓库外：

• 讨论 aevatarAI/aevatar#568 — Aevatar Harness 核心能力边界讨论
  • §1 Agent Continuation
  • §2 Tools / Skills / Plugins
  • §3 Memory / Session（已作废，作废理由本身是考点）
  • §4 Governance（四层结构 / 反"中心化 Profile"）
  • §5 Multi-Agent（组织架构模型 / TaskBoard 降级）
• 关联 issue #596 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛
• 关联 issue #560 SessionStreamGAgent RFC

答题方式

后端 / 架构全量题每道题一个 markdown 文件。请在该文件末尾的 ## 答题区 之下作答，不要修改题面。提交时把整个 tests/ 目录连同改动一起 commit 到你自己的分支。

答题前请先确认你当前 checkout 的分支已经包含本题目，然后从当前分支直接切出自己的答题分支；不要另行从 dev/master/main 重新切分支，以免丢失题面或基线。

分支命名遵循 CLAUDE.md §"提交与 PR" 的硬约束：<type>/YYYY-MM-DD_<purpose>，type ∈ {feat, fix, refactor, docs, test, chore}。本场答卷固定使用 docs/ 类型，把 <your-name> 换成你自己的英文名（小写、连字符）：

git checkout -b docs/2026-05-11_onboarding-exam-<your-name>
git add tests/
git commit -m "docs(tests): <your-name> onboarding exam answers"
git push origin docs/2026-05-11_onboarding-exam-<your-name>

如果交卷时已经过了 2026-05-11，请把日期改成你 push 当天的日期，仍然遵循 YYYY-MM-DD 定长格式。

题目 8 道，建议时间分配：

题号	题目	建议用时
01	硬规则甄别 — PR 评审	15 min
02	一次 Lark 回复链路的模块依赖图	12 min
03	Continuation 当前实现 vs #568 理想形态	15 min
04	trivial 抽象判定	10 min
05	Governance 四层落点	10 min
06	读写分离 + Memory 模块去留	12 min
07	Multi-Agent 组织拓扑现状	8 min
08	综合论述（≤300 字）	8 min

评分维度

每题 10 分，总分 80。评分会同时看：

1. 结论正确：你判断对了吗？
2. 证据扎实：是否引用了仓库具体文件路径 / 行号 / ADR 编号 / 讨论原文。没有具体引用的答案最多给一半分。
3. 规则原文：能否引到 CLAUDE.md / Discussion [Aevatar Harness] 核心能力边界讨论 #568 的具体段落（不是改写转述）。
4. 当前/理想区分：能否清晰地把"当前代码这样写"和"目标形态应该这样"分开论述。
5. 避免幻觉：编造不存在的接口名、文件名、规则会被扣分；先到代码里查。

如果一道题你认为题面有错或前提不成立，可以直接在答题区写 "我认为题面有问题，理由是..."，逻辑自洽且能引到证据，照样给分。

出题人友情提示

• 不要直接相信 AI 的第一版答案。它很容易给出"看起来对"的答案：把过时接口名混进来，把已删除的概念当现存，把 [Aevatar Harness] 核心能力边界讨论 #568 已作废的方向当主张。自己在仓库里 grep 验证一遍再交。
• 评卷会同步对答案做"反幻觉抽查"——任何引用都会回查到对应文件和行号。
• 题目顺序无依赖。你可以从你最熟的开始。

---

题 01 — 硬规则甄别（PR 评审模式）

满分：10 分（每小题 2 分）
必读：根目录 CLAUDE.md 全文，重点 Actor 设计原则 / Actor 执行模型 / 权威状态 / ReadModel / Projection / 中间层状态约束 / 序列化 / 测试与质量门禁。

题面

下面是 5 个伪 PR diff 片段，由不同新同事提交。每段 diff 都至少违反 CLAUDE.md 中的一条强制约束（标记为"强制"或"硬约束"的条目）。

请对每段 diff：

1. 指出违反了哪条规则（必须把 CLAUDE.md 中对应小节标题写出，例如"§Actor 执行模型 — 单线程事实源"），并引一句该小节里能直接证明"这就是违反"的原文（不少于 8 个汉字）。
2. 改写该 diff（≤8 行伪代码）让它合规。
3. 如果该违规直接对应仓库里已经存在的某条 CI 门禁脚本（在 tools/ci/ 下），写出脚本文件名；不是每条规则都有专门的 CI 脚本——如果你 grep 一圈没找到，直接写 "无对应 CI 脚本，规则仅在 CLAUDE.md 文字层" 即可，不扣分。

任一小步缺失或答错扣 0.5 分。

---

A. 在 Aevatar.CQRS.Projection.Core 中新增

public sealed class WorkflowRunIndex
{
    private readonly ConcurrentDictionary<string, WorkflowRunContext> _runs = new();

    public void Track(string runId, WorkflowRunContext ctx) =>
        _runs[runId] = ctx;

    public WorkflowRunContext? Find(string runId) =>
        _runs.TryGetValue(runId, out var ctx) ? ctx : null;
}

B. 在 RoleGAgent 内的工具回调里

private async Task OnHttpToolFinishedAsync(ToolResult result)
{
    var shouldComplete = false;
    lock (_pendingToolsLock)
    {
        _pendingToolCount--;
        if (_pendingToolCount == 0)
        {
            State.Stage = ChatTurnStage.Completed;
            shouldComplete = true;
        }
    }

    if (shouldComplete)
    {
        await PersistDomainEventAsync(new TurnCompletedEvent());
    }
}

C. 在新写的集成测试里

await client.PostAsync("/api/scopes/x/workflows/y/runs", body);
await Task.Delay(2000); // 等投影
var snap = await client.GetFromJsonAsync<RunSnapshot>("/api/.../runs/last");
snap.Status.Should().Be("Completed");

D. 在 Application 层新增

public sealed class WorkflowRunQueryService
{
    public async Task<RunDto> GetAsync(string runId, CancellationToken ct)
    {
        var events = await _eventStore.LoadAsync(runId, ct);
        var state = WorkflowRunState.ReplayFrom(events);
        return _mapper.ToDto(state);
    }
}

E. 在新增的领域事件契约里

public sealed record ChatTurnAppendedEvent
{
    public string RunId { get; init; } = "";
    public string PayloadJson { get; init; } = "";
    // 后续阶段把它解析成 typed payload
}

答题区

---

题 02 — 一次 Lark 群消息回复的模块依赖图

满分：10 分
必读：

• agents/Aevatar.GAgents.Channel.Runtime/Conversation/ConversationGAgent.cs
• agents/Aevatar.GAgents.Channel.Runtime/Conversation/IChannelLlmReplyRunDispatcher.cs
• agents/Aevatar.GAgents.NyxidChat/AgentRunDispatcher.cs
• agents/Aevatar.GAgents.NyxidChat/AgentRunGAgent.cs
• src/Aevatar.AI.Core/Chat/ChatRuntime.cs
• src/Aevatar.AI.Core/Tools/ToolCallLoop.cs
• agents/channels/Aevatar.GAgents.Channel.NyxIdRelay/
• docs/adr/0009-channel-bot-callback-architecture.md
• docs/adr/0011-lark-nyx-relay-webhook.md
• docs/adr/0014-interactive-reply-abstraction.md
• 提示：Issue 将 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛为 actor-owned Agent Continuation #596 的 "目标架构" mermaid 是这条链路的理想形态抽象，但当前代码已经走完了 Phase A。请以仓库现状为准。

题面

一条用户消息从飞书侧发出，经 NyxID Relay 进入 aevatar，再产生一次 LLM 回复推回飞书。请回答下列问题。

2.1（4 分）画依赖链

按调用 / 投递顺序列出从 "NyxID Relay 调到 aevatar HTTP 端点" 起，到 "回执 chunk 走出 aevatar 进程" 为止，消息穿过的每一个有名字的角色。每一行写：

N. <项目相对路径>::<类型/接口名> — 它在这一拍干了什么（≤ 15 字）

要求：

• 不少于 7 行，不多于 12 行。少写漏环节扣分，多写无关层也扣分。
• 至少出现一次 EventEnvelope 字眼或与之等价的投递载体说明。
• 如果一拍是异步事件而非同步调用，请在该行末尾用 [event] 标注。

2.2（3 分）边界

回答以下三个问题，每问 ≤ 30 字，必须点到具体类型/方法名：

• (a) ConversationGAgent 拒绝承担哪一类执行职责？把那个职责现在落到哪个类承担？
• (b) AgentRunGAgent 用什么作为它的 actorId？这个 actorId 提供的是寻址/幂等还是stale 守门？stale 请求由另一个什么机制丢弃？请给出两处源码 file::line——一处指向 actorId 构造，一处指向 stale 实际判定。
• (c) 新进来的 NeedsLlmReplyEvent 从 ConversationGAgent 投到 AgentRunGAgent 有没有经过 Projection Pipeline？为什么？

2.3（3 分）演进状态识别

下列5 个名字中：

1. ChannelLlmReplyInboxRuntime
2. IChannelLlmReplyRunDispatcher
3. IChannelLlmReplyInbox
4. AgentRunGAgent
5. ToolCallLoop

请回答：

• 先给出你实际跑过的 grep 或 rg 命令。
• 把 5 个名字分别归到下面 4 类之一，并各写一句证据：
  • 当前主链路：一次 Lark 回复现在真的会经过它。
  • 保留的边界 / 适配点：还在为当前链路服务，但不是执行主体（典型如 IO worker / 适配 port）。
  • 历史 / 已下线：当前仓库不存在，或只剩文档、历史引用、测试迁移痕迹。
  • 待后续收敛：当前仍在用，但 Issue 将 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛为 actor-owned Agent Continuation #596 / Discussion [Aevatar Harness] 核心能力边界讨论 #568 已把它标成历史包袱或后续拆解对象。
• 至少 2 个名字必须引用源码路径，至少 1 个名字必须引用 Issue 将 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛为 actor-owned Agent Continuation #596 的原文或 gh issue view 输出。

说明：4 类中允许有某一类为空（只要 5 个名字全部分类完毕、证据成立即可）。如果你判定某类为空，请在答题区末尾写一句 "X 类为空，因为 …" 说明。把名字硬塞进不合适的类反而扣分。

答题区

---

题 03 — Continuation 当前实现 vs Discussion #568 §1 理想形态

满分：10 分
必读：

• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §1 "Agent Continuation"（含 loning 的两轮 reply）
• src/Aevatar.AI.Core/Chat/ChatRuntime.cs
• src/Aevatar.AI.Core/Tools/ToolCallLoop.cs
• src/Aevatar.AI.Core/RoleGAgent.cs
• agents/Aevatar.GAgents.NyxidChat/AgentRunGAgent.cs
• 根目录 CLAUDE.md §"Actor 执行模型（强制）"

题面

Discussion #568 §1 给出一个核心判断："Agent 在 Aevatar 里的推进，不是 loop，是 actor 内的 event choreography。" 同时承认当前代码里 ChatRuntime / ToolCallLoop 仍然是 in-stack loop，是历史包袱。loning 在 §1 reply 中进一步主张 "我的理解, 不应该有 loop. 即便看起来是 loop, 也是基于事件驱动的"，并质疑 ChatRuntime 这个抽象应当消失。

3.1（3 分）找到 loop 的"案发现场"

到 src/Aevatar.AI.Core/Chat/ChatRuntime.cs 中：

• (a) 给出一条 for 或 while 循环的起始行号和 1 行 diff-style 引用，证明这就是 §1 描述的 in-stack loop。
• (b) 指出这个 loop 单次循环体内至少 3 件带"跨边界 / 长耗时 / 外部副作用"性质的事情（包括但不限于：跨网络调用、跨 actor 投递、HTTP/SSE 流处理、tool 中间件 / hook 调用、channel writer 推送给外部消费者等）。用变量名或方法名引用，不要泛泛说"调 LLM"。
• (c) 用一句话解释：为什么这个 loop 即使包了一层 async/await，仍然违反 CLAUDE.md §"Actor 执行模型 — 跨 actor 等待 continuation 化"？

3.2（4 分）对照 AgentRunGAgent 是不是 §1 的最小闭环

AgentRunGAgent（agents/Aevatar.GAgents.NyxidChat/AgentRunGAgent.cs）已经是 Issue #596 Phase A 的产物。但它不等于 Discussion #568 §1 描述的最终形态。

请用以下表格作答（每行 ≤ 25 字）：

维度	§1 理想形态怎么说	AgentRunGAgent 当前怎么做	是否对齐
LLM sampling 是 actor inbox 一拍吗
tool 调用是 actor inbox 一拍吗
approval / timeout 是事件还是循环内特殊分支
当 actor turn 结束时，下一拍由谁触发

最后一行加一句结论（≤ 30 字）：当前 AgentRunGAgent 把多拍折叠成几拍？

3.3（3 分）loning 的 "ChatRuntime 不该存在"

loning 在 §1 第二轮回复中说："ChatRuntime 感觉也不该存在. 实际上, 软件工程就是最好的 Harness ..." 对这个观点：

• (a) 用一句话解释 loning 为什么不接受"短期保留 ChatRuntime 作为 IO worker"这个折中。
• (b) Issue 将 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛为 actor-owned Agent Continuation #596 在落地路线上并没有完全照搬 loning 的极端方案，给出两条具体理由（每条 ≤ 30 字），从 Issue 将 ChatRuntime / ChannelLlmReplyInboxRuntime 收敛为 actor-owned Agent Continuation #596 的"Phase A / Phase E / 非目标"段落中找。
• (c) 给出一个判断：如果今天让你只能改三个文件把 ChatRuntime 的 loop 性质再削弱一档，你会改哪三个文件？每个写一行该改什么。

答题区

---

题 04 — Trivial 抽象判定

满分：10 分（每小题 2.5 分 × 4）
必读：

• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §3（"Memory 模块作废"那段，特别是"trivial 抽象的代价"四点）
• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §4（"AgentGovernanceProfile 不在四层中"那段）
• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §5（"TeamManagerGAgent / TaskBoardGAgent 退回 example"那段）
• 根目录 CLAUDE.md §"删除优先" / §"架构哲学 — 单一主干，插件扩展"

题面

Discussion #568 反复用一个判断方式："如果一个抽象只是给已有结构起新名字，没产生新约束 / 新能力，它就是 trivial（平凡）抽象，不值得引入。" loning 把它和数学里的"平凡解"做了类比。

下面是 4 个新同事提案。每个提案请回答：

• (a) 是 / 不是 / 视情况 trivial 抽象？
• (b) 如果是，它重命名/包装了仓库里现有的哪几个结构？请给出具体类型名 / 接口名（至少 2 个）。
• (c) 如果你判 "不是 trivial"，必须说明它产生了什么新约束或新能力（一句即可），并指出它会落地到 CLAUDE.md 中哪个分层。
• (d) 给出一个最终建议：接受 / 拒绝 / 改写为...。

判断错（a 给反）直接 0 分。其他每小问 0.5～1 分。

---

提案 1：AgentGovernanceProfile

新同事提议在 Application 层引入：

public sealed record AgentGovernanceProfile(
    string AgentId,
    PermissionMode Mode,
    IReadOnlyList<ToolRule> ToolRules,
    IReadOnlyList<ConnectorRule> ConnectorRules,
    BudgetRules Budget,
    ApprovalPolicy Approval);

public interface IAgentPolicyEvaluator
{
    Task<PolicyDecision> EvaluateAsync(AgentInvocation invocation, CancellationToken ct);
}

理由："这样我们就能集中治理。"

提案 2：ICapabilityRegistry

新同事提议把所有 IAgentToolSource 的工具枚举包装成一个统一的 ICapabilityRegistry：

public interface ICapabilityRegistry
{
    Task<IReadOnlyList<CapabilityDescriptor>> ListAsync(AgentScope scope, CancellationToken ct);
    Task<CapabilityHandle> ResolveAsync(string capabilityId, CancellationToken ct);
}

CapabilityDescriptor 内部字段就是 IAgentTool 已有的 name / args schema / IsReadOnly / RequiresApproval，加上一个 source 字段标记是 NyxID-backed 还是 Aevatar-native。

理由："前端要画一个统一的'能力中心'页面。"

判定提示：请分两种用法分别回答 trivial 与否——

• 情形 1：source 字段只用于前端展示，运行时仍然按原 IAgentToolSource 路径调用工具。
• 情形 2：source 字段被运行时消费，用来做路由 / 治理 / approval 分流（例如 NyxID-backed 工具强制走 NyxID approval，Aevatar-native 工具不走）。

两种情形可能给出不同结论。两者都要答。

提案 3：ITurnContextStore

新同事在 Aevatar.AI.Core 加：

public interface ITurnContextStore
{
    Task SaveAsync(string turnId, TurnContext ctx, CancellationToken ct);
    Task<TurnContext?> LoadAsync(string turnId, CancellationToken ct);
}

实现是 InMemoryTurnContextStore : ConcurrentDictionary<string, TurnContext>。

理由："工具回调里需要恢复 turn 上下文。"

提案 4：AgentProtocolDescriptor

新同事提议：每个 GAgent 用 [AgentProtocol(...)] attribute 声明自己接受的入站事件类型、超时、是否要求 approval、能否被跨 scope 寻址；编译时生成一份 manifest，运行时由 dispatch 层在投递前校验。

[AgentProtocol(
    Inbox: [typeof(NeedsLlmReplyEvent), typeof(ApprovalDecidedEvent)],
    CrossScope: false,
    DefaultTimeout: "00:05:00")]
public sealed class AgentRunGAgent : GAgentBase<...> { ... }

理由："让 schema-level 治理对每个 GAgent 都成立。"

答题区

---

题 05 — Governance 四层落点

满分：10 分
必读：

• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §4 "Governance"（重写后版本，loning 的两条 reply 同样是考点）
• 根目录 CLAUDE.md §"Command / Envelope / Dispatch（强制）"
• 仓库里的工具中间件实现（提示：grep -rln "IToolCallMiddleware\|ToolApprovalMiddleware" src agents）

题面

Discussion #568 §4（重写版）把 Governance 分为 四层：Schema / Boundary / Actor / Topology。每一层分别"让某种违规根本无法构造 / 无法发出 / 无法到达 / 无法越权"。loning 在 reply 里强调："hooks 不是 hard gate"。

5.1（4 分）四层映射 — 现实证据

请用下表作答。每一层给出仓库里一个真实的、当前正在运行的机制，要求：

• 写出 <相对路径>::<类型/接口/方法> 至少一个；
• 给出 一句 ≤ 25 字 的解释，说明该机制如何让"违规根本无法构造/发出/到达/越权"。

层级	当前仓库的对应机制（路径::类型）	它阻止了什么样的违规
Schema-level
Boundary-level
Actor-level
Topology-level

禁止用 IToolCallMiddleware 当 Schema 层或 Actor 层的答案——那是 hooks 类（详见 5.2）。

5.2（3 分）IToolCallMiddleware 是 hard gate 还是 hook？

答题前请先到 Discussion #568 §4 Governance 找 "Hooks 的定位（明确分责）" 那一小段——它列出了 pre-tool / post-sampling / pre-connector / pre-command-dispatch 等 6 类钩子点并明确"hard gate 必须在四层结构内"。判断时请以 §4 原文给出的 hook 边界为准，而不是按"调用栈能不能同步阻断"直觉判断。

下列 4 个判断里至少有 2 个是错的，至多有 3 个是对的。请逐条标 T / F，并对每条 ≤ 25 字 解释你的依据（必要时引 §4 原文或仓库源码）：

• (i) IToolCallMiddleware 在调用栈上同步阻断违规调用，所以是 hard gate。
• (ii) ToolApprovalMiddleware + YieldApprovalHandler + PendingToolApprovalState 把 approval 事件化进入 actor inbox，这部分语义已经落到 Actor-level，而不仅仅是 hook。
• (iii) 如果未来有人把 IToolCallMiddleware 写成"返回 Deny → 直接 throw"，它就成 hard gate 了。
• (iv) Hooks 失败不阻断主流程是设计 bug，应该改为 fail-closed。

5.3（3 分）loning 的 "Hooks 跟 GAgent 基类绑定"

loning 的 reply 原文："所有的 agents 在定义过程中会定义自己的 harness, 只需要提供继承关系或者 tools 就可以, 不需要有包含语义的 Hooks. 即便是有, 那也是对于某一个 GAgent 基类, 有一些专门的 Hooks、Gates. 也就是说, 这些都应该跟某些有语义的 GAgent 基类绑定."

请回答：

• (a) 把这条主张翻译成 CLAUDE.md 的语言，应该是哪条原则的延伸？给出 CLAUDE.md 中的小节标题。
• (b) 当前 RoleGAgent 的工具 / 中间件 / Hook 注册路径违反或部分违反了 loning 这条主张吗？给出一处具体证据（一行 file::line 或一句源码引用）。如果你认为没有违反，也要给出反证。
• (c) 如果接受 loning 这条主张，第一步最该改的是哪个文件 / 注册点？写出完整路径并给一句改法。

答题区

---

题 06 — 读写分离 + Memory 模块去留

满分：10 分
必读：

• 根目录 CLAUDE.md §"权威状态 / ReadModel / Projection（强制）"
• docs/canon/cqrs-projection.md
• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §3 "Memory 作废"全文（含 loning 的两条 reply）
• agents/Aevatar.GAgents.UserMemory/UserMemoryGAgent.cs
• src/Aevatar.Studio.Infrastructure/ActorBacked/ActorBackedUserMemoryStore.cs

题面

6.1（5 分）读写分离的应用题

新同事 A 在 review 中收到这样的需求："前端要展示当前会话的最近 10 条消息，给我一个接口。" 他写出下面三个候选：

候选 1

public interface IConversationGAgent : IGAgent
{
    Task<IReadOnlyList<ConversationMessage>> GetRecentMessagesAsync(int limit);
}

候选 2

public interface IConversationQueryService
{
    Task<RecentMessagesDto> GetRecentAsync(string conversationId, int limit, CancellationToken ct);
}
// 实现里：先 IEventStore.LoadAsync(conversationId) 拿到所有事件，
//        ConversationState.ReplayFrom(events)，
//        再裁剪后映射成 DTO 返回。

候选 3

public interface IConversationQueryPort
{
    Task<RecentMessagesDto> GetRecentAsync(string conversationId, int limit, CancellationToken ct);
}
// 实现里：调用 IProjectionDocumentReader 读 conversation_messages readmodel，
//        附带返回 readmodel 的 stateVersion。

请回答：

• (a) 三个候选各自合规 / 不合规，每一个写一句 ≤ 30 字 的判断。
• (b) 对最不合规的那一个，引 CLAUDE.md 中两条以上不同的强制规则证明它"不止违反一条"。
• (c) 假设产品再加一条："要返回"当前 LLM 是否还在思考"这个布尔值。" 请分两种语义回答（两段加起来 ≤ 80 字）：
  • 情形 1：把它当作最近消息列表 DTO（候选 3 的返回值）上的字段。它该不该挂在这里？依据什么规则？
  • 情形 2：把它作为独立的 run 当前态查询字段（例如 run_current_state readmodel 上的 is_sampling 布尔）。这样合规吗？如果合规，对前端"瞬时流式态"的需求是不是合适？
  • 两种语义可能结论不同。请明确每种情形依据 cqrs-projection.md / CLAUDE.md 哪条规则（"权威源版本 / 刷新戳 / 弱读"等）。

6.2（5 分）UserMemoryGAgent 是不是 #568 §3 反对的"Memory 模块"？

打开 agents/Aevatar.GAgents.UserMemory/UserMemoryGAgent.cs。Discussion #568 §3 的最终结论是 "Memory 作为独立 Harness 模块作废"，理由摘录：

"Memory" 作为独立 Harness 模块是 trivial 抽象——它只是给已有结构（GAgent state + committed event log + projection / readmodel）起了个新名字...

但是仓库里真实存在 UserMemoryGAgent、UserMemoryState、MemoryEntryAddedEvent 等命名包含 "Memory" 的对象。这是不是与 §3 矛盾？

请按下列结构作答（每段 ≤ 60 字）：

• (a) 类比论证：§3 给出过一张"看起来像 memory 的需求 vs Aevatar 已有结构"的映射表，请把 UserMemoryGAgent 放入这张表对应的某一行；说明它对应的是哪一行的"需求"和哪一行的"已有结构"。
• (b) 结构性判断：UserMemoryGAgent 的状态类型（UserMemoryState）是 protobuf message，事件通过 PersistDomainEventAsync 走 ES。从这两点判断它是不是 §3 反对的"旁挂式 sidecar memory（vector DB / chat history / sidecar）"。
• (c) 命名 vs 抽象：§3 把 trivial 抽象的代价之一描述为 "新词覆盖已有结构，认知负担 +1"。UserMemoryGAgent 这个命名有没有犯这个错？如果有，建议改成什么名字、或者改成什么继承关系来淡化"Memory 是独立模块"的暗示？
• (d) 结论：在 1 分（"完全是 §3 反对的对象"）到 5 分（"完全合规、命名也无可指摘"）之间，给 UserMemoryGAgent 一个整数评分并说明理由。

提示：这是开放题。结论本身不计分（1～5 都可能被接受），评分点是 (a)(b)(c) 是否言之有据。

答题区

---

题 07 — Multi-Agent 组织拓扑现状

满分：10 分
必读：

• Discussion [Aevatar Harness] 核心能力边界讨论 #568 §5 "Multi-Agent"（重写后版本，含 loning 的"按公司组织架构设计"reply 串）
• docs/adr/0006-multi-agent-evolution.md
• src/Aevatar.Foundation.Core/MultiAgent/TaskBoardGAgent.cs
• src/Aevatar.Foundation.Core/MultiAgent/TeamManagerGAgent.cs
• test/Aevatar.Foundation.Core.Tests/MultiAgent/*

题面

Discussion #568 §5（重写版）的核心结论：

1. Aevatar 平台层只需要 3 个 primitive：GAgent、parent/child link、消息。
2. TeamManagerGAgent / TaskBoardGAgent 不再是平台 primitive，应"退回 application-level example pattern"——具体到代码上 §5 写过一行明确建议："TaskBoardGAgent → 同上，作为'分发部门'的具体实现示例 ... 移到 examples/ 或 samples/，命名改为业务名"。

但如果你 find . -name "TaskBoardGAgent.cs"，会发现它当前还住在 src/Aevatar.Foundation.Core/MultiAgent/ ——这是平台基础层，不是 examples。

7.1（4 分）现状盘点

• (a) 用 1 行 find 或 rg 命令证明 TaskBoardGAgent 当前的位置。把命令和输出第一行贴在答题区。
• (b) Aevatar.Foundation.Core 这个项目在 CLAUDE.md / docs/canon/architecture-vocabulary.md 的语境里属于哪一层？请引一句原文。
• (c) 把 TaskBoardGAgent 留在 Foundation.Core 而不挪到 examples/，与 §5 重写后的结论之间存在几条矛盾？逐条列出（不少于 2 条），每条 ≤ 25 字。

7.2（3 分）平台 primitive 三件套是否当前已足够

§5 主张："GAgent + parent/child link + 消息" 已经够用，多 worker / reviewer / 任务分发都是这三件套的运行时编排。

• (a) 在仓库里至少给出 1 个（最好 2 个）当前已经实现的、能证明 "parent/child link" 是平台一等概念的 API 入口（写出 路径::方法名）。如果给出 2 个，请说明它们是抽象 + 实现（interface ↔ impl）的一对，还是两个独立入口。
• (b) loning 的反问："我通过 workflow 已经明确定义了我处理什么消息, 我如何处理. 那我等着消息来就可以了. 然后有 StreamProxy 把外部的事件传进传出系统. 我为什么还要关心去哪里拿任务?" — 用一句话翻译这条反问对应到 CLAUDE.md 中哪条强制约束（§"Actor 设计原则" 或 §"Actor 执行模型" 里的某条）。
• (c) 反方向：列出一个仅靠 "GAgent + parent/child + 消息" 不容易表达的需求，并简述需要补什么（典型例子可在 §5 "主要缺口" 段找到）。

7.3（3 分）StreamProxy 的命名歧义

Issue #560 提示了一个命名警告：

Auric 提到的 StreamProxyGAgent 不等于现存的 agents/Aevatar.GAgents.StreamingProxy/StreamingProxyGAgent.cs（那是群聊房间 broker，做 Messages[] / Participants[] 状态机）。

请回答：

• (a) 当前 StreamingProxyGAgent 的真实职责是什么？用一句 ≤ 30 字 的话概括（先打开它的 State 类型看字段）。
• (b) Issue RFC: 统一外部长连接流为 actor 一等抽象（SessionStreamGAgent 方向）— 求团队讨论与互评 #560 RFC 里讨论的 SessionStreamGAgent 真正想抽象的是什么？用一句 ≤ 30 字 的话概括。
• (c) §5 的 loning reply 中提到："StreamProxyGAgent 未来支持多模态的话, 那么 RoleGAgent 现在不能处理多模态. 整个体系感觉是要用策略模式之类的." — 把这条话转写成：当前 RoleGAgent 的输入 / 输出契约面向多模态需要补什么？给一个具体改造点（一句话即可，可以是新 proto field、新 message、新 sub-state）。

答题区

---

题 08 — 综合论述（≤ 300 字）

满分：10 分
必读：

• 根目录 CLAUDE.md §"架构哲学"
• Discussion [Aevatar Harness] 核心能力边界讨论 #568 主帖 "总体判断" / "外部边界"

题面

请用≤ 300 字的中文，向一位刚入职、有通用 agent harness（如 LangChain / OpenAI Assistants / Claude Agent SDK）经验的工程师，回答：

为什么 Discussion #568 主帖说 "Aevatar 不应该简单复刻一个通用 agent harness"？这个不复刻的代价和回报分别是什么？

要求作答时：

1. 必须至少点到下面 4 个底座中的 3 个（漏掉 2 个或更多直接 -3 分）：
   • Orleans 上的 GAgent / actor runtime
   • 基于 EventEnvelope 和 stream 的 message plane
   • event sourcing 的 actor-owned state
   • CommittedStateEventPublished → projection / readmodel 的观察链路
2. 必须显式指出通用 agent harness 的什么习惯（典型如 in-stack while-loop / 旁挂 vector memory / 中心 policy config）在 Aevatar 这个底座上是结构性多余而非 "也能做"。
3. 必须至少给出一个具体的代价——也就是这条不复刻路线让 aevatar 现阶段做不了什么 / 比通用 harness 慢在哪里。鼓励诚实回答；这一项给出空泛"成本可控"会扣分。
4. 必须至少引用一句 CLAUDE.md 或 Discussion [Aevatar Harness] 核心能力边界讨论 #568 中的原文（≥ 8 个汉字），并标注出处。
5. 不要用项目符号 / bullet / 编号；用连续的散文段落。

评分时会按上面 5 条逐一打钩。每漏一条扣 2 分。300 字以内的限制不是建议，是上限：超过 320 字（中文计，不含标点）按超界扣分。

答题区

---