消融基础设施要回答什么问题？
- 定义: 消融（Ablation Study）就是逐一 “摘除” 某个组件，看整体性能掉多少;
- 做法: 系统内置一个总开关，可同时禁用多个主要特性（思考模式、上下文压缩、自动记忆、后台任务），创造一个 “裸模型” 基线;
- 目的: 回答 “某个特性是真的改善了用户体验，还是只是感觉有用”;
- 工程约束: 消融开关必须在启动路径的极早期注入——任何模块级常量捕获配置值之前，因此必须从一开始就设计进系统架构，而非事后加装;
- 常规化收益: 定期运行（如每次大版本发布前）可以发现 “特性债务”，即那些曾经有效但随模型进化已不再必要的特性;
- 建议实践: 每个主要特性都应是可独立关闭的，团队应定期验证每个特性的实际贡献;
AB 测试要遵守哪几条方法论？
- 定义: AB 测试即把用户随机分成两组，一组使用旧版本、一组使用新版本，通过对比两组的实际数据判断改动是否有效;
- 多臂而非二元: 不仅对比 “有” 和 “没有”，而是设计多个渐进式变体（测试不同强度的提示词约束时设置控制组和三个渐进更严格的实验组），揭示剂量-效应关系;
- 区分机制指标和目标指标: 最容易犯的错误是把你正在改变的东西当作优化目标;
- 例: 测试 “缩短 Agent 的计划文件长度” 时，计划长度是机制指标，真正的目标可能是 “降低会话级成本”；缩短计划可能降低成本，也可能因计划不够详细导致更多的编辑-检查-编辑循环，反而增加总输出量;
- 自问: 我改变的东西（机制）和我真正关心的东西（目标）是同一个吗？如果不是，以目标为准;
- 护栏指标: 即使目标指标改善了，如果用户满意度下降、操作次数增加或错误率上升，实验也应该停止；护栏指标是 “不能变差的底线”;
- 记录基线统计: 包含样本量、分布百分位数、相关性分析（如 “拒绝率随计划大小单调递增”），没有基线就无法判断实验结果是否具有统计显著性;
双层特性开关系统如何分工？
- 定义: 特性开关（Feature Flag）是可以远程控制的开关，决定某项功能对用户是开启还是关闭，无需重新部署代码;
- 三个目的: 实验、渐进发布和紧急熔断;
- 编译时开关: 在构建阶段就将相关代码从产物中物理移除，内部专用的特性在外部构建中根本不存在，即使逆向工程也无法发现;
- 编译时开关的消融含义: 关闭某个特性不是在运行时跳过逻辑，而是对应的代码在物理上就不存在;
- 运行时开关: 配置由服务端下发，并在本地磁盘缓存一份;
- 启动可靠性取舍: 宁可读取到稍旧的缓存配置，也不能让 Agent 因等待网络请求而阻塞启动;
- 分组决策: 通过实验平台（如 GrowthBook）完成 AB 测试组分配;
- 曝光记录: 每个特性的曝光事件在每个会话中最多记录一次，避免重复记录污染实验数据;
- 定位: 对 Agent 开发者来说，特性开关不是简单的调试工具，而是一等架构组件;
提示词敏感性评估的实践是什么？
- 问题: 系统提示是 Agent 行为的核心 “代码”，但往往缺少与普通代码同等的版本控制和回归测试;
- 做法: 提供专用工具，在指定的 git 版本上提取完整渲染后的系统提示，包含所有动态条件展开后的最终文本;
- 可回答的问题: 哪次提交改变了提示词？对评估集的影响是什么？
- 建议一: 系统提示应该能够确定性渲染——给定相同的配置输入，永远产生相同的输出;
- 建议二: 建立提示词的版本化快照机制;
- 建议三: 每次提示词变更都应在评估集上运行回归测试，就像代码变更需要跑 CI 一样;
隐私感知分析如何成为评估基础？
- 矛盾: 评估依赖好的数据，但 Agent 产品处理的往往是用户的敏感内容;
- 做法: 通过类型系统解决——分析接口只接受经过特殊类型包装的值，类型名本身就是审计线索，明确表明 “我已验证这不是代码或文件路径”;
- 机制: 把隐私约束从文档化的规范变成编译时强制执行的类型检查;
- 核心原则: 从一开始就把隐私约束设计进去，而非事后加装;
- 结论: 如果你的分析系统无法安全地收集数据，你就无法有效地评估；
- 附带收益: 隐私感知的设计迫使你认真思考真正需要度量什么，反而会催生更精准的评估指标;
外部评估与内部评估的分工是什么？
- 外部评估: 告诉你 “Agent 有多好”;
- 内部评估基础设施: 告诉你 “哪项改动让它变好了”;
- 五个组件: 消融实验发现哪些特性真正重要、AB 测试量化每项改动的影响、特性开关提供实验和回滚的基础设施、提示词敏感性评估把系统提示纳入 CI、隐私感知分析确保数据收集的合规性;
- 共同构成: 评估驱动的产品工程——不是偶尔做一次评估，而是将评估嵌入到每一次产品决策中;