模式矩阵 /模式白皮书/Reflection

范围：本页说明反思子系统的整体设计。F1 至 F4 的问题、机制和验证标准仍以各模式规范为准。

反思可以发生在一次输出之后，也可以发生在一批任务结束之后。它读取产物、执行轨迹和外部结果，对照可检查的标准，决定是否修改当前输出、运行路径或可复用资产，然后再用新的证据确认修改是否有效。

“让模型再想一遍”只是最轻量的实现。缺少证据、停止条件和修改权边界时，额外一轮推理很难证明系统真的变好了。

先问四个问题

一条反思回路在上线前应该回答：

1. 什么信号触发检查？ 测试失败、规则不符、用户差评、人工标注，还是模型评分？
2. 什么证据足以判定好坏？ 编译结果、schema、业务规则、专家结论和用户行为的可靠性与到达时间都不同。
3. 这一轮允许改什么？ 改当前答案、当前计划、Skill、记忆、业务规则，还是生产代码？
4. 怎样确认修改后更好？ 原检查项重跑、回归集、对照实验、人工复核和真实业务反馈分别解决不同问题。

四个问题中任何一个没有答案，回路都应先停在观测或建议阶段。

观测、评测与反思的分工

评测给出判断，反思消费这个判断并提出改变。当改变要进入共享 Skill、记忆库、规则库或生产环境时，反思模块需要把权限交给治理门禁。

两只时钟：在线与离线

2026-08-12 的 ADPS 反思模块研讨会中，王伟和李佳奇从不同业务场景提出了同一个分界：反思有两只时钟。

这是运行方式，不是新的模式坐标。F1 和 F4 经常用于在线回路，但它们的 rubric、失败分类和停止阈值需要离线校准。F2 的加载发生在线，技能的生成、测试、并存评测和发布主要发生在离线。F3 也跨越两边：离线提炼经验，在新任务中按需回放。

结果什么时候才到

反思时钟由成功信号的延迟决定。

开放性问题并非一律不能在线检查。可以在线检查引用、格式、明显矛盾和已知风险，对最终业务价值的判定则留到反馈到达之后。

反思合同

生产系统需要把反思回路表达为可检查的合同：

reflection_id: ref_01K2...
scope: artifact              # artifact | trajectory | asset | system
trigger:
  type: test_failure
  ref: trace://run-8842/check-9
evidence:
  - type: deterministic_test
    ref: test://payroll/net-pay-balance
judge:
  policy: reflection-rubric-v4
proposal:
  target: src/payroll/net_pay.py
  allowed_change: diagnosed_files_only
authority:
  mode: auto_in_sandbox      # suggest | auto_in_sandbox | approval_required
budget:
  max_iterations: 3
  max_latency_ms: 90000
verification:
  suite: payroll-regression-v12
  rollback_on_regression: true
retention:
  disposition: candidate_lesson

一条完整回路是：触发 → 证据装配 → 诊断 → 修改提案 → 权限门禁 → 执行 → 复验 → 记录。模型可以参与诊断和提案，测试、规则、人员和业务结果共同决定它有没有权力继续。

四个正式模式怎样分工

在线/离线、硬证据/软判断、局部/全局与反馈延迟都是模式选型参数。它们不改变“认知功能 × 执行拓扑”的主框架。

生产实现的四层结构

研讨会中，周默提出了一个很实用的四层分工：

1. 硬校验层：编译、测试、schema、业务不变量和系统回执优先。
2. 反思诊断层：模型阅读证据，识别当前输出、轨迹或资产的可能问题。
3. 记忆与资产层：候选 lesson、Skill、规则和失败记录经过准入后才跨任务生效。
4. 调度与控制层：决定是否启动反思、使用哪个评审者、能跑几轮、何时降级或转人。

可自动触发、可终止、可观测、可控制成本，是所有生产回路的共同要求。“可复用”需要更细的处理：当反思结果仅修改本轮产物时，可以明确不保存；当它要跨任务生效时，就必须有准入、版本和退役机制。

三个规模化难题

局部补丁会破坏整体效率。 王伟介绍的环境构建 Agent 在长期运行中不断增加局部修复，稳定性上升，整体路径却越来越重。离线反思要能发现重复、冲突和已失效的补丁，不能只把 Bad Case 继续叠加进 prompt。

Skill 要在组合环境中评测。 单个 Skill 的触发率和任务成功率只能说明它独立可用。规模扩大后，还要检查误触发、漏触发、重叠、冲突、加载成本，以及新 Skill 是否让已有能力退化。

归因先于自愈。 陆钱春将问题分为运行时、执行过程、业务结果和体验几类。参数失效、网络抖动和步骤遗漏可能有明确修复路径；专家知识缺失、业务规则变化和团队目标差异无法靠原 Agent 自行补全。

2026 年的工程进展

截至 2026 年 8 月，主流工具已经把反思依赖的评测部件做成了正式工程接口：

• LangSmith Evaluation 区分发布前的离线评测和生产 trace 上的在线评测，并将失败 trace 回收到数据集。AgentEvals 已经直接评估 Agent 的工具调用轨迹。
• Anthropic 在 2026-01 发布的 Agent 评测方法 中建议组合代码、模型和人工 grader。其 企业 Skill 治理指南 进一步要求触发、独立运行、并存、指令执行和输出质量评测。
• OpenAI 的 AgentKit 将 trace grading、数据集和 grader 纳入 Agent 优化工作流。

这些能力首先解决“怎样看见和判断”。把判断转成受控修改，并用回归证据确认它，才进入 ADPS 所说的反思回路。

暂不增加新编号的方向

元反思检查 critic 本身是否漏判、误判或使用了有问题的 rubric。它可以先作为 F1 的高风险配置，不急于单独落牌。

审议式反思让多个评审者从不同假设出发展开辩论。它与 F1 生成评审、C3 对抗评审都有重叠，当前还缺少稳定的终止条件和成本证据。

前瞻性反思在行动前检查计划、风险和假设。这项职责已分布在 F1、A4 护栏三明治和 G1 审批门中，需要更多独立实践才能判断是否形成新模式。

还需要行业回答的问题

• 大规模 Skill 库怎样分离 Agent 质量、Skill 质量与组合效应？
• 多维 rubric 一些指标上升、一些下降时，谁有权定义交换关系？
• 哪些反思结果可以自动修改 Harness，哪些只能生成变更建议？
• 当真实结果几天或几周后才到达，怎样保留当时的轨迹、版本和责任链？
• 如何发现在线回路积累的补丁冲突，并安全地合并、删除或回滚？

研讨会记录

本总纲吸收了 2026-08-12 反思模块第一次研讨会的讨论。主持人为张海立、黄佳；核心研讨嘉宾为张栋、周默、王伟、陆钱春、赵翰、Pylon Peng、李佳奇。本页引用的观点来自逐字稿收录的六位发言嘉宾：张栋、周默、王伟、陆钱春、Pylon Peng、李佳奇。

阅读完整研讨记录 · 白皮书贡献者