RFC 与架构评审

评审先对齐要解决的决策

开头先写需要批准或否决的具体选择，以及不决策的代价。例如“是否让退款 Agent 在指定金额和原因码内自动执行”比“建设智能客服架构”更能约束讨论。随后给出业务目标、用户任务、当前基线、范围、非目标和不可变约束。

事实、假设、工程判断与待实验项必须可辨认。现网日任务量是事实，采用率是待验证假设，选择事件驱动是工程判断，监管要求是约束。把四者混成陈述会让评审者无法判断应该反驳数据、验证假设，还是比较设计。

架构叙事围绕运行与责任

一张组件图不足以证明架构。RFC 要从入口开始说明身份如何建立，Context 与数据经过哪些信任边界，模型在哪些节点做开放式决定，Tool 如何授权和对账，状态由谁持久化，人工何时接管，最终业务终态如何验证。

正常链之外，还要描述异步长任务、取消、超时、重试、版本固定和回放。失败分析沿传播路径展开：模型选错 Tool，策略是否拦截；Tool 超时，是否能判断副作用；控制面不可用，数据面能否使用已验证快照；恢复后，Trace 和账本是否能对齐。

替代方案必须可比且包含 Why Not

替代方案来自真实决策空间：保持人工、确定性 Workflow、检索助手、单 Agent、多 Agent、购买产品、复用平台或自研。每个方案都用相同任务和约束比较质量、延迟、成本、可靠性、安全、迁移与组织复杂度，不能拿完整推荐方案与一句话稻草人比较。

默认推荐应写适用条件和例外。例如单 Agent 是低到中等复杂任务的默认选择，多 Agent 只有在职责隔离、独立扩缩或上下文边界带来明确收益时采用；若只是为了角色名称更形象，多 Agent 会增加协调、Trace 和失败面。Why Not 记录当前不选的证据，不宣称方案永远错误。

把未知变成验证计划

每个关键未知都映射到实验方法、样本、指标、阈值、数据 Owner 和决策影响。模型质量用代表性 Golden Dataset 与分层评测，检索用权限与引用验证，Tool 用契约和故障注入，容量用生产形状负载，恢复用 GameDay，用户工作流用 Pilot。

阈值必须在看结果前定义，并包含停止或收缩条件。Google SRE 的可靠发布实践强调轻量、可重复、适应风险的检查；Agent RFC 可据风险分层，低风险变更走快路径，高风险自治、身份或数据边界变化必须补齐安全、恢复与运营证据。

未知：Tool 超时后是否会重复退款
方法：在提交前、提交中、回执后注入超时并重放
证据：幂等账本、外部订单终态、Trace、补偿记录
通过：任何重试不产生重复副作用，未知结果进入对账
停止：无法取得稳定幂等键或外部回读能力

评审是风险发现，不是权威表态

评审前异步发送 RFC，标出需要决定的章节和未关闭问题。会议从分歧与高风险未知开始，不逐页朗读。邀请业务、应用、平台、数据、安全、SRE 和前端体验角色的标准，是他们是否拥有约束、运行责任或反证，而不是组织层级。

评论分类为阻塞、需实验、建议和未来优化；每项有 Owner 与期限。主持人要主动询问反方方案和失败传播，防止职级最高者先表态造成从众。无限共识同样有成本，应提前确定 Decision Owner、截止时间以及无法达成一致时的升级路径。

决策之后继续验证

AWS 的 ADR 指南将 ADR 定义为架构重要选择的上下文、决定和后果，并建议接受后保持不可变，由新 ADR 取代旧决定。对 Agent 系统还应记录假设、影响范围、配置版本、残余风险和反转触发器，使未来团队知道为什么当时合理。

上线后按 RFC 的业务、质量、SLO、成本与风险指标复盘。若采用率低、单位成本高、失败超出上限或平台依赖改变，应触发缩小自治、回滚或新 ADR，而不是修改旧文档掩盖偏差。未达到反转门槛但出现新风险时，也要显式接受并指定复审时间。