多数系统先设计功能，再补审计。我反过来做——先确定系统在出事后需要回答哪些问题，再倒推每一层应该记录什么。这个思维倒置改变了整个架构。
一个倒过来的设计顺序
搭系统的自然顺序是：先让功能跑起来，再加日志，最后补审计。
我在设计 AI 编排系统时把顺序倒过来了：先列出系统出事后需要回答的问题，再倒推每一层应该记录什么，最后才设计功能如何运行。
这不是因为我更"严谨"。是因为我在早期吃过一次亏——AI 自动迭代了 15 轮优化，最终产出了一个 Sharpe Ratio 很高的策略。但当我想回溯"第 8 轮为什么从动量因子切换到了均值回归"时，发现什么记录都没有。AI 做了决策，但决策过程消失了。
一个无法解释的好结果，比一个可以解释的坏结果更危险。因为你不知道它是真的好，还是刚好过拟合了。
问题的结构
这个问题的本质不是"日志不够多"。而是一个更根本的设计缺陷：系统的信息流是为"执行"设计的，不是为"回溯"设计的。
执行优先的系统长这样：
输入 → 处理 → 输出 → （可选）记个日志
回溯优先的系统长这样：
输入 → 记录输入 → 处理 → 记录决策依据 → 输出 → 记录输出 → 关联到同一条链
区别不在于记录多少，而在于记录的东西是否能被串成一条因果链。散落的日志条目不是审计——它们只是噪音。审计是能回答"谁在什么时候基于什么信息做了什么决定，结果是什么"的完整链条。
这和数据库事务日志的设计思路是同源的。数据库的 WAL（Write-Ahead Log）不是事后补的调试工具——它是架构的一部分，在写数据之前先写日志。先记录，再执行。顺序不能反。
我考虑过的方案
方案 A：事后补日志
在现有代码里加 logger.info，把关键节点的状态打到日志文件里。需要回溯时 grep 日志。
这在运维排障中是标准做法。出了问题看日志，定位到时间点，找到错误信息。
为什么在 AI 编排场景下不够：AI 的编排循环不是线性的。它是一个迭代循环——生成代码 → 执行 → 评估 → 决定继续或停止 → 回到生成。每一轮的"决定"依赖上一轮的"评估"，而"评估"依赖"执行结果"。如果只有散落的日志行，你能看到每一步发生了什么，但看不到步骤之间的因果关系。“为什么第 8 轮切换了方向”——这个答案分散在三个不同的日志行里，而且没有任何东西把它们关联起来。
方案 B：终局倒推设计（我的选择）
先定义"事后需要回答的问题"，再倒推系统需要记录什么。
我列了五个终局问题：
- 这个任务是谁发起的，在什么上下文里？
- 每一轮迭代生成了什么代码，得到了什么指标？
- 每一轮的评估决策是什么，基于什么理由？
- 最终结果的数据依赖是什么版本？
- 如果用同样的输入重跑，能得到同样的结果吗？
从这五个问题倒推，每个问题对应一个必须记录的数据结构：
- 问题 1 → 任务提交记录（用户 ID、session、objective、时间戳）
- 问题 2 → 迭代快照（每轮的完整代码 + 执行结果 + 指标，不是摘要）
- 问题 3 → 评估记录（决策 + 决策依据，作为结构化字段，不是日志文本）
- 问题 4 → 数据版本哈希（输入数据的 SHA256，记录在任务元数据里）
- 问题 5 → 可复现性校验（代码哈希 + 数据哈希 + 引擎版本，三者组合可唯一确定结果）
设计出来之后，信息流变成了：每次状态转换不是"执行完了顺便记一下"，而是"记录是状态转换的一部分——不记录就不算完成"。
关键判断点
做出这个选择的转折点不是技术考量，而是一个认知转变：审计不是系统的附加功能，是系统的设计约束。
这个认识来自金融行业的一个惯例。在合规严格的金融机构里，交易系统的审计需求不是上线后由合规部门"提需求"加进去的——它从第一天就是架构的一部分。交易记录的完整性、时间戳的不可篡改性、决策链的可追溯性——这些是和"能下单"同等重要的系统需求。
AI 编排系统面临同样的问题。当 AI 自动做出影响资金的决策时，“这个决策是怎么来的"不是调试需求，是生产需求。
这引出了一个更一般的原则：任何会被问"为什么"的系统，都应该在设计阶段就把"回答为什么"作为约束条件。 不是加日志能解决的——是信息架构需要为回溯而设计。
实施效果
终局倒推设计带来的一个意外收获：它大幅简化了调试过程。
以前排查问题的流程是：看日志 → grep 关键词 → 拼凑时间线 → 猜测因果关系。
现在的流程是：查任务 ID → 拿到完整的迭代序列 → 每一步的输入、输出、决策、理由都是结构化字段 → 直接定位到出问题的那一步。
从"在非结构化文本里搜索"变成"在结构化数据上查询”。这不是审计系统的副产品——这是终局思维自然导致的结果：为回溯设计的数据结构，天然适合被查询。
另一个效果更微妙：当系统强制要求每次评估决策都记录理由时，评估逻辑本身被迫变得更清晰。“通过/不通过"不够——你必须写出"因为 Sharpe < 1.0 且连续 3 轮无改善所以终止”。这种强制记录倒逼了决策逻辑的明确化。
这个决策教会我什么
我从这次实践中提炼了一条设计原则：
设计一个系统时，先问：这个系统出事后，需要回答哪些问题？然后确保架构本身能回答这些问题——不依赖事后 grep 日志。
这条原则的适用范围远超 AI 系统。任何系统只要运行时间够长，最终都会面临"为什么会变成这样"的追问。区别在于：有些系统的架构能直接回答这个问题，有些系统需要工程师花三天翻日志才能拼出一个不确定的答案。
差别不在于谁的日志更多。在于谁在设计阶段就把"可回溯"当作了和"能运行"同等的设计约束。
终局思维的本质是：不要只设计系统在正常运行时的样子，也要设计系统在被审查时的样子。后者往往决定了前者的架构。
系列第四篇。上一篇：AI as Operator, Kernel as Law。第二篇：MCP 的问题不在协议层。第一篇：为什么我没有用多智能体架构。