Magent PTC 与单 Loop 多模型优化计划

1. 一个普通 Magent turn 可以在多个 sampling epoch 中使用不同 backend/model。
2. plan-execute 在 plan 与 execute 之间使用显式、可审计的结构化边界，不解析 自由文本猜测 phase。
3. 每个 epoch 的模型路由、system prompt、有效能力集和 wire projection 都可从 session ledger 重建。
4. provider-native continuation 只可在 route、phase、system 和 wire tools 都未 改变时复用；否则必须从 ledger 创建新的 ~gptel-request~。
5. native 与 code projection 必须来自同一个有效能力集，不能各自维护工具名单。
6. run_code 内的每个 nested call 必须重新经过 permission、approval、audit 和 cancellation；批准外层 run_code 不能替代对子工具的授权。
7. nested call 返回 lossless canonical JSON value；provider 文本和 UI 展示是该 value 的渲染，不是 canonical value 本身。
8. Session 只接受届时定义的精确 schema；版本或字段 shape 不匹配时 fail closed， 不猜测历史请求中未记录的模型、system 或 tool schema。
9. native 模式和当前单模型 agent 的行为在未启用新 policy 时保持等价。

• 不实现任意 phase graph、可编程 routing DSL 或每个 tool call 单独选模型。
• 不实现模型 ensemble、投票、speculative execution 或自动 fallback model。
• 不让 model 自己选择任意 backend/model；route 是 trusted Elisp policy。
• 不把 Action Workflow 的多个 runtime turn 冒充为一个 agent loop。
• 不重写 gptel transport，也不复制 gptel 的 provider registry、鉴权或流处理。
• 不把 Code Runtime 描述为安全沙箱；它只提供进程生命周期、取消和资源上限。
• nested executor v1 不并行执行子调用。只有 benchmark 证明串行是瓶颈且工具具备 明确 concurrency-safety contract 后，才增加 bounded scheduler。
• 不先支持多语言 runtime。首个 backend 使用无第三方依赖的 JavaScript/Node subprocess；runtime seam 保留替换能力，但不提前实现 Python、container 或 persistent REPL。

有效能力集是某个 epoch 中 agent 真正可以调用的 semantic tools。解析顺序固定：

1. canonical tool catalog；
2. Action Step 的 exact :tools allowlist（普通 turn 为 ~:all~）；
3. root agent 的 permission ceiling；
4. phase agent 的 permission rules；
5. request/session 级 permission override；
6. 必需 control tool 的 preflight。

Root 与 phase permission 对同一调用取更严格的结果（~deny~ > ask > ~allow~）。Phase profile 可以收窄 root agent 的权限，不能因为换 model/profile 而扩大 用户选中 agent 的权限上限。

Presentation 只能改变这些工具怎样暴露给模型，不能扩大集合。

Wire projection 是“发送给 provider 的 tool schema 视图”：

• ~native~：有效能力集被投影为 gptel tools；
• ~code~：provider 只看到 ~run_code~；
• ~both~：provider 同时看到 native tools 和 ~run_code~。

code 模式中没有直接发送的 native tool schema，但 nested executor 仍持有同一 有效能力快照。模型即使伪造 native tool call，也不能绕过该投影和 executor。

SDK projection 是由 canonical argument/output schema 生成的稳定声明和使用说明， 作为 system prompt 的一个确定性 section 发送。它是模型写 program 的接口说明， 不是 provider tool schema，也不执行任何调用。

Sampling epoch 是一次模型采样及其终止原因：assistant completion、tool-call batch、 provider error 或 cancellation。它比 turn 小，比单个 streamed chunk 大。每个 epoch 有单独的 route/header/usage/phase，但仍属于同一个 ledger turn。

Provider/adapter 对同一个逻辑请求的 retry 是该 epoch 的另一个 attempt，不重新解析 phase、route、prompt 或 tools。Tool result 后的 provider continuation 则是新的 epoch。 这样 UI 或配置在 retry 中途变化时，只能影响下一 epoch，不能撕裂当前请求。

Phase 是 trusted loop policy 的有限状态。v1 仅有：

single

plan --finish_plan approved--> execute

plan-execute 的每个新 turn 从 plan 开始。execute completion 结束 turn；turn 取消、失败或进程退出不会把未完成 phase 带到下一个用户 turn。

“可重建”指能从 pinned Magent version、session ledger 和当前 gptel 配置恢复 Magent 交给 gptel 的逻辑请求：prompt history、system、canonical wire schemas、model route 和 sampling metadata。API key、HTTP header、provider server-side defaults 和原始 SSE 字节不进入 session。

优点是几乎不改 agent loop；现有 Workflow 已能让两个 Step 使用不同 agent。

拒绝原因：它产生两个 runtime submission/turn，continuation、tool history、取消和 最终 assistant ownership 都被 Workflow 边界切开，不满足“一次 agent loop”。它仍 可用于实现前的 benchmark prototype，但不是目标架构。

优点是代码量最少。

拒绝原因：loop 会同时拥有 phase policy、agent 配置、route、prompt 和 tools；未来 任何第二种 policy 都会复制分支。custom agent 还会得到一套平行于现有 agent 的 model/permission 配置。

这是选定方案：

• loop 只拥有 epoch 生命周期、调用 request builder、continuation 判定和终止；
• magent-agent.el 根据 sampling context 和 phase agent 构造完整请求；
• plan-execute controller 只拥有有限 phase transition；
• tool presentation 只拥有有效能力集到 provider/SDK 的投影；
• orchestrator 只拥有 permission/approval/audit/execution。

该方案比 B 多一个 request-builder seam，但这个 seam 已有两个真实调用时机：初始 sample 与 tool-result 后续 sample；并且它直接消除当前散落在闭包中的 request 重建知识，因此边界成立。

新增 ~magent-tool-spec~，至少包含：

(:name "read_file"
 :description "..."
 :parameters <canonical JSON schema>
 :output <canonical lossless-JSON schema>
 :permission-key read
 :file-argument "path"
 :execute #'magent-tools--read-file)

约束：

• name 唯一，~run_code~ 与 finish_plan 是 reserved names；
• parameters/output 必须是 magent-json-safe-value 可接受的值；
• native gptel tool、SDK declaration、argument validation、nested binding 和 audit name 全部从该 spec 派生；
• permission key 和 file argument identity 不再由平行表维护；
• catalog 保持确定性顺序，SDK 再按 name 排序以获得 byte-stable 输出。

破坏性替换现有 result 含义，消除 success 与 status 的重复真值：

(:status completed | failed
 :value <JsonValue>          ; completed 时必需
 :content "provider/UI text"
 :error (:code "..." :message "...")
 :metadata <JsonValue>)

• value 是 nested SDK binding 的返回值，并按 tool output schema 校验；
• content 是 native provider、ledger transcript 和 UI 的 bounded rendering；
• failed result 在 nested runtime 中成为可捕获的 ToolCallError~，而不是成功返回一段 以 ~Error: 开头的字符串；
• provider boundary 只接收 ~content~，不自行重新解释 ~value~；
• persisted output 必须已经符合 canonical result schema；非结构化 string 或未知 result shape 在加载边界被拒绝。

Runtime ~magent-model-route~：

(:backend <gptel backend object>
 :model <symbol>
 :temperature <number-or-nil>
 :top-p <number-or-nil>
 :effort <normalized effort-or-nil>
 :thinking <auto-or-explicit-mode>)

Durable route 不序列化 backend object，只记录：

(:backend-name "..."
 :model "..."
 :temperature ...
 :top-p ...
 :effort "..."
 :thinking "...")

Route 解析优先级：

1. request-context 对当前 phase 的显式 route override；
2. phase agent 的 model/sampling fields；
3. root agent 的 model/sampling fields；
4. gptel default values。

Session effort 和 thinking option 是用户对整个 turn 的显式 override，应用到所有 phase；它们不改变各 phase 的 backend/model。显式 disabled thinking 抑制 effort。

Request builder 接收 immutable sampling context：

(:index 1
 :reason initial | tool-result | phase-transition
 :phase plan | execute | single
 :profile-agent "plan"
 :previous-header-id "..."
 :turn-id "..."
 :request-context <magent-request-context>)

返回一个完整 magent-sampling-request 和 canonical header：

(:phase "plan"
 :profile-agent "plan"
 :route <durable route>
 :presentation "native"
 :effective-tools ["read_file" "grep" "finish_plan"]
 :system "..."
 :wire-tools [<canonical schema> ...]
 :metadata (...))

Builder 必须先解析并冻结 phase profile/route，再组装 system prompt 和 tool presentation；prompt 中出现的 model/phase 变量来自同一份 snapshot。Builder 返回后 修改 agent、session option 或 gptel default，不能改变已经开始的 epoch。

v1 在每个 sample ledger item 中保存完整 header，优先保证简单、独立重建。实现后 必须测量 session 文件增长；只有数据证明重复 header 是实际问题时，才改为 content-addressed header + sample reference，不能先实现 delta codec。

magent-agent-info 新增：

• tool-presentation~：~native~、~code 或 ~both~，默认 ~native~；
• loop-policy~：~single 或一个 validated plan-execute spec。

plan-execute spec 只包含：

(:kind plan-execute
 :plan-agent "plan"
 :execute-agent "build")

模型、prompt、permission、temperature 和 tool presentation 从引用的 agent 读取， 不在 policy 中重复。file-backed agent frontmatter 对应：

loop-policy: plan-execute
plan-agent: plan
execute-agent: build
tool-presentation: native

上例中的 tool-presentation 属于该 agent 自己。若希望 plan/native、execute/code， 就在 plan agent 与 build agent 的各自定义中配置，不在 root policy 再声明一次。

Phase profile 的 loop-policy 不递归执行；controller 只读取它的 model、sampling、 prompt、permission 和 presentation。Root agent 可以安全地把自己作为 execute-agent， 上例不会形成第二层 loop。

File-backed agent 的 model 继续表示当前 gptel backend 下的 model id。跨 provider profile 使用 Elisp 创建的 magent-agent-info~，其 model 可以是现有 ~(BACKEND . MODEL) 形式。本计划不为此复制一个 Magent backend registry；只有 gptel 提供稳定的 public backend lookup 后，才考虑把 backend name 加入 frontmatter。

解析失败必须发生在 provider sampling 之前：unknown agent、agent mode 不适用、 无可用 model、code presentation 缺 runtime、Action exact tools 缺少 ~finish_plan~，都直接令 turn startup 失败。

turn start
  -> build epoch header from root agent
  -> sample
  -> tool batch? execute + record -> build next epoch
  -> assistant completion -> turn complete

未启用新配置时，这条路径必须和当前行为等价。

turn start
  -> phase=plan, profile=plan-agent
  -> sample plan model
  -> read/explore tools ...
  -> finish_plan({plan})
       -> permission/approval
       -> record exact plan
       -> mark execute transition pending
  -> current native batch / run_code program settles
  -> append deferred approved-plan context
  -> build a fresh execute epoch
       phase=execute, profile=execute-agent
       never reuse plan provider continuation
  -> execute tools ...
  -> assistant completion -> turn complete

finish_plan 的 output value：

{"approved": true, "plan": "# ..."}

规则：

• plan 必须是非空 string；标题格式属于 prompt guidance，不作为安全校验；
• permission=~ask~ 时复用现有 approval provider；allow 支持无人值守执行；deny 返回 structured failure 并留在 plan phase；
• 一个 turn 只能有一个 pending/committed finish；重复调用失败；
• transition 在完整 tool batch 或外层 run_code settle 前不可生效；
• 批次中 finish_plan 之后的 nested calls 仍使用 plan phase 的有效能力快照；
• approved plan 作为 model-visible、source-attributed context 记录一次，execute model 不需要解析 nested audit event 或从 JavaScript source 中提取 plan；
• plan 是模型生成并经用户批准的数据，不是 system instruction，不能授予权限；
• plan model 若直接 assistant-complete 而未调用 finish_plan~，turn 以 ~plan-not-finished 失败，不发隐藏 recovery request，也不偷偷切 execute model；
• execute phase 的 assistant completion 才是正常 terminal answer。

当前 Magent 在 tool batch 后只要有 continuation 就优先调用。改造后顺序必须变为：

1. tool batch 完成；
2. apply pending phase transition；
3. 构建下一 epoch 的 header；
4. 比较 continuation origin 与新 header；
5. 只有完全兼容才调用 continuation，否则清除 continuation 并发起 fresh ~gptel-request~。

兼容 fingerprint 至少覆盖：

• backend runtime identity；
• model；
• phase；
• rendered system prompt；
• ordered canonical wire schemas；
• temperature、top-p、effort、thinking mode 及影响 provider request 的 metadata。

Phase 变化一律视为不兼容，即使两个 phase 恰好配置成同一 model。这样不会让旧 provider FSM 忽略新的 phase prompt 或 approved-plan context。

新增 ~magent-tool-presentation.el~，唯一职责是把一个已经解析好的有效能力集投影成：

(:wire-tools <gptel tools>
 :wire-schemas <canonical JSON values>
 :system-section <SDK string-or-nil>
 :nested-capabilities <immutable tool-spec vector>)

它不读取 permission、不执行工具、不选择 model。~magent-agent.el~ 在每个 epoch 依次调用能力解析、presentation 和 prompt assembly。

both 仅用于兼容与 benchmark，不作为默认值。它会同时支付 native schema 和 SDK token，不能无数据宣称更优。

首版 SDK 使用 JavaScript-compatible TypeScript declarations，program 本身写普通 JavaScript async body：

interface ToolArgsMap { /* generated */ }
interface ToolOutputMap { /* generated */ }
declare const tools: {
  [K in keyof ToolArgsMap]:
    (args: ToolArgsMap[K]) => Promise<ToolOutputMap[K]>;
};

要求：

• 名称按字典序生成；非法 JavaScript identifier 使用 quoted key；
• description 进入 JSDoc，所有动态文本正确转义；
• 不支持的 schema construct 降级为 ~unknown~，runtime validation 仍是权威；
• SDK 固定说明来自 prompts/ 下的 Org prompt 并登记 ~prompts/manifest.txt~；generated declarations 不进入 manifest；
• SDK 明确说明 v1 nested calls 串行、mutating/reading 都不能假定并行；
• effective set 为空时不暴露无意义的 ~run_code~。

不能把 nested call 放回 outer run_code 正在占用的串行 loop queue，否则 outer 等待 code、code 等待 nested、nested 又等待 outer 释放 queue，形成自锁。

magent-tool-orchestrator.el 增加一个执行单个 canonical tool spec 的 reentrant 入口。native batch 与 nested executor 共享同一 permission/approval/audit core， 但调度器不同：

• native provider batch 使用 loop queue；
• run_code 内部使用 run-owned serial nested queue，直接调用 orchestrator core；
• nested executor 不调用 provider callback，也不启动新的 agent loop；
• run_code 不出现在自己的 nested capability snapshot 中，禁止递归；
• 每个 nested call 生成 child call id，并记录 outer call id、epoch id 和 depth；
• outer cancellation abort runtime、未开始的 nested calls 和可取消的 active call；
• outer settle 后到达的 callback 必须丢弃，不能修改 ledger 或文件；
• approval 可异步等待，但不得占住 Emacs 主线程；
• nested result 的 deferred contexts 在 outer run_code result 记录之后按提交顺序 追加，保持 provider call/result adjacency。

新增 ~magent-code-runtime.el~，最小 public contract：

(run CODE BINDING-NAMES CALL-BINDING CALLBACK SIGNAL LIMITS)

逻辑输入/输出：

input:
  code, visible binding names, cwd, cancellation, limits

worker -> host:
  call {id, name, arguments}
  log  {level, values}
  done {value}
  fail {kind, message}

host -> worker:
  result {id, value}
  error  {id, code, message, toolName}

首个 backend：

• 每个 run_code 启动一个短生命周期 Node subprocess；
• 使用项目打包的固定 bootstrap 和逐行 JSON protocol；
• 不依赖 npm package，不维护 persistent REPL；
• code 作为 AsyncFunction body 执行，支持 top-level await 和 ~return~；
• host 提供 tools bindings 与 bounded console capture；
• protocol 拒绝 unknown message、duplicate id、不可表示 JSON、超限 line/output；
• wall timeout、combined output cap 和 cancellation kill 都由 host 强制；
• working directory 使用 request project root；环境只保留启动 Node 所需的最小值；
• code mode preflight 找不到兼容 runtime 时，在 provider sampling 前失败；native 模式完全不依赖 Node。

该 subprocess 不是安全边界。即使 bootstrap 限制常用 global，也不能声称能抵抗 恶意 JavaScript 或 Node escape。其信任姿态等同现有 bash tool：真正的控制来自 Magent permission、approval 和用户选择是否启用 code presentation。

每次 sampling 创建一个非 surface sample item：

(:type sample
 :status in-progress | completed | failed | cancelled
 :phase plan | execute | single
 :metadata (:index 1
            :attempts 1
            :header <canonical full header>
            :continuation fresh | provider-native
            :stop-reason ...
            :usage ...))

Provider conversation projection 只读取 message 与 tool item，因此 sample item 不会进入 provider conversation。ACP replay 默认忽略它；P0 observability 通过 session inspector、~*magent-log*~ 和 UI-neutral observer events 提供，不伪装成 tool call 或 assistant thought。

Observer 新增：

• ~sample-start~：epoch id/index、phase、profile agent、backend/model、presentation；
• ~sample-end~：status、usage、stop reason、continuation kind；
• ~phase-transition~：from/to、trigger call id、approved-plan item id。

只有 ACP/agent-shell 出现合适的标准展示形状时才增加视觉 projection；核心不能为 临时 UI 伪造协议事件。

引入 sample/header 时定义一个精确的新 session schema。加载器只接受该版本及其 完整字段集合；旧版本、未知字段、缺失 sample attribution 或非结构化 tool result 直接停止加载并报告 session id/field，不迁移、不猜测，也不双写 shadow state。

Request context 是 runtime object，不需要落盘。其 frozen scalar backend/model/temperature/top-p/effort/thinking 将替换为 per-phase route override 和当前 epoch reference；audit snapshot 仍冻结 root agent/session attribution，并额外记录 phase profile，避免 UI 中途切 agent 后重标历史。

目标：先冻结当前 single/native 行为和可比较指标。

任务：

• 为无 tool、单 tool、连续三次 tool、provider continuation、Action exact tools、 child agent 建立 deterministic fixtures；
• 记录 request count、prompt/tool schema、turn/item 投影、session JSON 大小；
• 增加一个两个 mock gptel backend 的 test harness；
• 记录当前 make compile~、~make lint~、~make test-unit~、~make test 结果。

退出门槛：fixtures 能检测 system/tools/model 在后续 sample 被意外改变，且当前 main 行为全绿。

目标：在行为仍为 native 的前提下，让工具定义和值不再依赖 gptel struct。

任务：

• 引入 magent-tool-spec 和严格 schema validation；
• 迁移 15 个工具，native projection 生成与当前等价的 gptel tools；
• 合并 permission key、file arg identity 和 schema source；
• 将 result 分成 canonical value 与 rendered ~content~；
• 更新 ledger/session 严格 result schema validation；
• 删除旧的并行 permission/schema maps，不保留 compatibility wrapper。

退出门槛：native request tool schemas 与基线语义等价；所有实现只返回新 result； invalid output 在 provider callback 前失败。

目标：同一 turn 的后续 sample 可以安全换 route/header。

任务：

• loop 从持有 frozen request 改为持有 request builder；
• 每个 sample 重新解析 route、system、effective tools；
• 写入 durable sample item/full header；
• continuation 记录 origin header 并按 fingerprint 复用或丢弃；
• observer/log 显示 epoch、backend/model 与 fresh/continuation；
• 单模型 policy 走新路径，删除旧 request-for-current-session 保留字段的合约。

退出门槛：mock backend 在一个 turn 内得到 A→B route 序列；A 的 continuation 不会 在 B 上调用；single/native fixtures 不变。

目标：先隔离验证 phase/model switching，不混入 Code Runtime 风险。

任务：

• 加入 validated ~loop-policy~、phase agent resolution 和 ~finish_plan~；
• plan/execute runtime prompt 使用 Org resources；
• 实现 approval、pending transition、approved-plan context 与 failure semantics；
• 添加两个 mock models：plan model 调 read + finish，execute model 调 write + final；
• 覆盖 deny、revision after denied approval、direct completion、duplicate finish、cancel。

退出门槛：一个 ledger turn 中按顺序记录 plan sample、finish tool、phase transition、 execute sample 和 final assistant；没有第二个 runtime submission。

目标：在没有 Node runtime 前先证明 nested permission pipeline 不死锁。

任务：

• 从 orchestrator 提取 spec-based execute-one core；
• 建立 run-owned serial nested queue 和 immutable capability snapshot；
• 增加 parent/child call correlation、deferred context 和 late-callback fence；
• 使用 fake in-process Code Runtime 覆盖成功、失败、ask、deny、cancel、递归拒绝；
• 明确 outer run_code permission 与每个 nested permission 是两次独立决策。

退出门槛：fake program 能连续调用三个工具并 settle；审批等待期间 Emacs event loop 仍可推进；取消后无 ledger/file late mutation。

目标：交付可选 code / both projection。

任务：

• 实现稳定 SDK 生成和 run_code wire schema；
• 实现 Node worker JSON protocol、limits、output capture 和 process cleanup；
• 将 nested value/error 映射为 program result/~ToolCallError~；
• 打包 runtime asset，更新 source manifest、melpazoid recipe 和覆盖测试；
• code/both 缺 runtime 时做 request preflight failure；native 无 Node 时照常工作。

退出门槛：真实 Node subprocess 完成组合读取、条件分支和返回；code wire 只有 ~run_code~；both 同时包含两种 projection；打包后的安装副本可以找到 worker。

目标：每个 phase 可以独立选择 agent/model/presentation。

任务：

• 覆盖 plan/native → execute/code；
• 覆盖 plan/code 中 nested finish_plan 及 approved-plan deferred context；
• 确认 phase switch 总是 fresh request，并准确记录两份 header；
• 验证 Action exact tools、skills tool requirements 和 permission intersections；
• 验证 child agent、isolated Action、Doctor 均未获得隐式 Code Runtime。

退出门槛：一个真实或 deterministic mock turn 中，plan model 与 execute model 不同，execute model 只看到 ~run_code~，但 nested executor 只能调用 execute phase 有效能力集。

目标：用数据决定默认建议，而不是先假设 PTC 一定节省成本。

任务：

• 运行下面的 benchmark matrix；
• isolated daemon 中执行 non-tool、native tool、multi-step、plan-execute、code mode；
• 检查 ~*magent-log*~、~*Messages*~、session JSON 和取消；
• 更新正式双语 ARCHITECTURE/AGENT_WORKFLOW/ONBOARDING/AGENTS；
• 将本文状态改为 implemented 或拆出仍未完成的明确 backlog。

退出门槛：全部 CI/build/package/live gates 通过，且没有未归属的兼容路径。

• tool spec name/schema/output validation；
• native gptel projection 与 SDK escaping/order；
• canonical JSON roots：null、boolean、number、string、array、object；
• non-JSON、duplicate key/ID、oversized protocol/output failure；
• route precedence 与 durable serialization；
• policy validation、unknown/cyclic phase agent；
• header equality/fingerprint 和 continuation decision；
• 当前 session schema round-trip，以及旧版本、未知字段和无效嵌套 shape 的拒绝。

• code wire 只含 ~run_code~；伪造 native direct call 返回 unknown/denied；
• nested allow/ask/deny 都经过 audit；
• Action exact allowlist 外工具既不进 SDK，也不能 nested dispatch；
• run_code 不能递归调用自己；
• 三个串行 nested calls 不死锁；
• program catch ToolCallError 后可以继续；
• wall timeout kill worker，并 settle pending nested calls；
• output/log cap 保留一个明确 terminal diagnostic；
• worker exit、invalid JSON protocol、duplicate settle fail closed；
• approved plan context 在 outer result 后出现，顺序可重建；
• process dispose 后无存活 worker 和 callback。

• sample item/full header JSON round-trip；
• replay 不把 sample item 投影进 provider messages；
• 当前 session 的 message/tool canonical value round-trip 保真；
• observer sequence：sample-start → tool events → sample-end → phase-transition；
• audit record 带 epoch/phase/profile/parent-child call ids；
• agent-shell 普通 transcript 不出现伪造 tool/thought 卡片。

每个 Elisp 实现里程碑至少运行：

make compile
make lint
make test-unit

跨 loop/runtime 或打包里程碑运行：

make test
make coverage

新增 production Elisp、prompt 或 runtime asset 时同步更新：

• magent.el lazy bootstrap/dependency graph；
• ~prompts/manifest.txt~；
• .github/workflows/melpazoid.yml recipe；
• production source manifest 与对应 regression tests；
• coverage loader。

melpazoid 必须使用新 staged package 和当前 checker，在 --network=none 下完成 packaged ~load~。仅 source checkout compile 不能证明 worker/prompt asset 已被打包。

按照 AGENTS.md 使用隔离 daemon，不触碰主 Emacs：

1. reload 当前 checkout，并确认 source summary 指向该 checkout；
2. 清 session；
3. ~你好~：single/no-tool；
4. ~帮我看下 emacs 里面有多少 buffer~：native ~emacs_eval~；
5. 一个三工具组合任务：code/nested executor；
6. 一个 plan-agent → execute-agent 任务：不同 model；
7. 在 plan approval、nested tool 和 provider stream 三个位置分别 cancel；
8. 检查 active agent-shell buffer、~*magent-log*~、~*Messages*~ 和 session JSON。

真实 provider 验证不要求把 key 写入 fixture；使用本机已有 gptel 配置。若没有两个 可用模型，correctness gate 用两个 mock backend，live smoke 用同 backend 两个 model 或只验证 fresh request boundary，并明确记录限制。

1. 单次读取并回答；
2. 三个独立只读查询；
3. 读取 → 条件判断 → 第二次读取；
4. 搜索 → 编辑 → 测试；
5. plan → 批准 → 多步 execute；
6. nested tool failure 后 program recovery；
7. 大 tool output 和长 session。

• task success / artifact correctness；
• provider sampling request 数；
• native/nested tool 调用数；
• input/output/reasoning tokens（provider 提供时）；
• total wall time、approval wait、tool time、model time；
• continuation 命中与因 header/phase 改变而 fresh request 的次数；
• system + wire schema/SDK 字节；
• session JSON 增长；
• cancellation settlement latency；
• worker peak/残留进程（可观测时）。

Correctness、权限和可恢复性是发布 gate；token/latency 是选择默认 presentation 的 证据。只有至少三个独立 tool operation 的 workload 才适合评价 PTC round-trip 收益；单 tool 任务不预期 code mode 更快。