为什么做 TraceWise：从逐条日志到可解释、可审阅、可恢复的 AI 分析系统

返回 TraceWise 项目总览 · 交互图：端到端 · 工作流 / 系统 · 架构 / Foundation · 集成

如果一个项目的问题只发生一次，日志通常够用：找到报错时间，查看调用栈，修复异常，再验证结果。

但复杂项目的真实问题往往不是“哪个接口报错了”，而是：某个判断为什么形成、当时参考了哪些事实、这些事实后来是否变化、谁批准了由此产生的变更，以及半年后还能不能还原当时的推理条件。

这类问题很难靠逐条日志回答。日志记录事件，却不天然保存事件之间的业务关系；搜索能找到相似文本，却不等于知道哪条 Evidence 支撑了哪项结论；模型可以生成解释，却不能自己获得修改权威 Graph 的权限。

TraceWise 就是在这个压力下形成的项目调查产品。它把项目资料、Graph、Evidence、实体版本、规则、推演、AI 提案、人审决定和历史回执组织到同一个工作流里。目标不是让模型“更像一个自主团队”，而是让知识工程师和项目分析人员能够回答四个问题：

1. 这次分析使用了什么上下文；
2. 结论引用了哪些 Evidence；
3. AI 建议是否经过人审才改变权威状态；
4. 历史结果能否在不偷换当前状态的前提下被恢复和解释。

这一定义也划出了受众和非目标。TraceWise 服务的是需要调查项目事实、审阅 AI 建议和解释历史决定的人，而不是把所有团队沟通自动替代掉；它当前证明的是本地受控工作流，不是市场采用、模型准确率或生产治理。

从产品判断上看，GOV.UK 的用户需求指南强调从用户试图完成的事情出发，并把缺少用户证据的意见视为待验证假设；Martin Fowler 对 Outcome 与 Output 的区分也提醒，功能数量不是用户结果。TraceWise 没有据此宣称已经完成正式用户研究，而是把它们用作约束：Graph、Agent、版本或平台能力只有在帮助用户完成上述四项判断时，才值得进入产品主线。

用 5W2H 定义项目，而不只描述实现

5W2H 对 TraceWise 最有用的地方，是迫使项目在 How 之外继续回答六个问题：

这张表也解释了为什么本文不会只展示架构图。架构回答 How，但项目价值还依赖 Why、Who、When 和 How Much。

真实产品截图：工作台同时呈现 Agent 调查、Graph 关系和实体状态版本。画面使用合成项目数据，只证明该产品界面和交互状态被实际渲染。

为什么不是再做一个日志检索工具

从当前产品契约和开发演进回看，TraceWise 需要解决的不是“日志数量太多”，而是三类更难的问题。

1. 上下文问题：同一句答案可能来自不同事实集合

项目状态会变化。实体今天是 at-risk，明天可能是 on-track；规则会发布新版本，Evidence 也可能新增、撤回或被替代。如果分析只保存最终文本，后续无法判断它使用的是当前事实还是历史事实。

TraceWise 因而把 Graph 邻域、Evidence、实体版本、规则快照和字符预算一起纳入上下文。模型拿到的是一份受限输入，不是任意数据库访问权；输出仍需通过结构化 schema 校验。

2. 权威问题：AI 输出只能是 Proposal

模型可以建议新增一个节点、修改实体状态或补充关系，但建议不能等于写入。AI 输出首先成为 GraphChangeProposal，经 schema、Graph 基线和 Evidence lineage 校验后进入人工审阅。

Reviewer 看到差异和依据，填写业务理由，再批准或驳回。批准才进入执行路径；驳回形成终态记录但不改变提案目标。Graph、Evidence、Policy 或身份在审阅期间发生变化时，旧决定失去对当前状态的授权效力。

3. 时间问题：恢复历史不等于用当前规则重新运行

“重新运行一次”看似可以重现历史，实际上当前实体、规则、Evidence 和 Host Model 都可能已经变化。TraceWise 将历史 inference 的实体版本选择、规则快照和 Evidence 绑定持久化；SimulationRun 则保存 input、timeline、output 和完整性指纹。

恢复一个已完成 run 是读取已保存事实，不重新调用 Host Model，也不把一次新执行伪装成历史重放。

一条完整用户路径

TraceWise 的主流程不是围绕某个模型能力组织，而是围绕一次项目调查组织：

1. 用户进入一个业务项目，确认项目身份和 Graph；
2. 从关键词、类型、关系和邻域中检索相关上下文；
3. Agent 在受限 Graph/Evidence 上形成回答和引用；
4. 需要改变 Graph 时，AI 只形成结构化 Proposal；
5. Reviewer 检查差异、Evidence 和业务理由；
6. 批准进入受控执行，驳回保持 Graph 不变；
7. Inference、Simulation、ReviewDecision 和 receipt 进入历史与报告路径。

技术解释图：调查与回答、提案与人审、Inference/Simulation 和历史恢复属于同一个产品闭环。该图解释系统关系，不是运行截图。

这个闭环有意把“形成解释”和“改变权威状态”分开。回答可以展示引用；Proposal 必须等待审阅；执行只能消费满足当前 lineage 的批准；历史恢复必须说明恢复了什么、没有恢复什么。

Graph 和 Evidence 分别解决什么

Graph 解决的是关系。它让系统能表达项目、人员、技术组件、依赖、风险、规则和影响路径，而不是只返回一组相似文本。检索阶段可以综合关键词、确定性向量语义、类型、关系重合和邻域信号，并在增强路径不可用时退回原始 Graph 搜索。

Evidence 解决的是依据。它记录来源、摘要、关联实体和置信字段，并在 Proposal、ReviewDecision、Inference 与 Foundation authority 中以 ID、revision 或 fingerprint 参与绑定。

两者缺一不可：只有 Graph，系统能画关系却无法说明关系凭什么成立；只有 Evidence，系统有很多引用却难以解释这些事实如何共同影响项目判断。

真实产品截图：项目 Graph 将模型、检索、事实核验和方案关系放在同一画布中。数据为合成示例，不代表真实客户项目。

真实产品截图：选中实体后可以查看关系数量、Evidence 缺口、版本状态和档案内容。界面中的 Persona 是产品档案字段，不代表自治 Multi-Agent 编排。

Planner、Verifier 与 Persona 的串行分析

TraceWise 代码中存在 Planner、Worker、Verifier 和 Synthesizer 等责任名称，但它们是一个进程里的串行责任段，不是可以独立调度、独立持久化、拥有各自上下文预算和故障恢复能力的多个 Agent。

因此，项目对外使用“可解释子图分析流水线”而不是“多 Agent 自治协作”。这不是降低项目价值，而是把价值放回真实机制：

• Planner 规划要处理的问题和上下文；
• Worker 在限定信息上形成候选结果；
• Verifier 检查 Evidence 缺口和启发式差异；
• Synthesizer 组织最终可读输出。

Verifier 的 confidence 不是经过校准的正确率，也不能因为 Evidence 数量增加就自动证明语义更可靠。模型质量仍需要独立数据集、基线、指标和可复现实验；TraceWise 当前证明的是上下文、治理和证据链机制。

产品边界如何被拆出来

TraceWise 最初来自一个模块化单体。随着 Graph、Evidence、Memory、上下文和治理能力增长，一个问题越来越明显：哪些能力属于具体产品，哪些应该成为可复用平台？

物理拆分后的 TraceWise 明确保留：

• 项目身份、路由、授权与历史；
• Graph/Evidence 产品工作流；
• Host Model 配置、凭据查找、OpenAI-compatible transport 和产品 prompts；
• Reviewer 选择、AI 变更面板、Simulation、报告和用户体验。

Agent Foundation 作为精确版本依赖，只能通过 agent_foundation.public.* 类型契约被调用。TraceWise 不导入 Foundation container、store、repository、provider 或内部数据库实现；Foundation 也不会拿到产品的模型凭据。

技术解释图：产品 API、Host Model、Graph/Evidence、Inference/Simulation 和 Foundation 公共边界由明确所有者负责。

与 Agent Foundation 的关系：采用方，而不是平台外壳

TraceWise 与 Agent Foundation 是直接的运行时关系，但不是“前端套壳”。采用方仍拥有业务真相和用户决策，平台只接收冻结的 typed input，并返回 binding、decision 和 receipt。

当前正式版本为 tracewise-product==0.2.0a12，精确依赖 agent-foundation==0.1.0a20.post10。权威切换按项目显式进行，默认 cutover registry 为空，不存在全局环境开关把所有项目同时切换。

受控本地基线已经覆盖两个真实 Foundation authority projects。第二个项目在切换前完成备份，迁移 107 条 Evidence，建立独立 Registration，并从可复现 a12 wheel 重新打开；原 Pilot 身份和受保护产品行保持不变，未 opt-in 项目继续走产品内置权威路径。

技术解释图：TraceWise 保留产品身份和 Authority Selector；显式 opt-in 项目通过公共 API 进入 Foundation Proposal、Review、Outbox 与 Executor。

这项证据证明的是“两个受控本地项目可以按项目切换并保持未切换项目不变”，不是全量迁移、自动回滚或生产就绪。

开发讨论如何改变了产品

TraceWise 的含金量并不只在最终功能。几次关键讨论让系统从“功能看起来存在”变成“说法与证据能够对上”。

“graph_id 能不能算租户隔离？”

不能。graph_id 和 Scope 可以组织逻辑分区，但没有统一生产 IAM、tenant/RBAC、owner-member enforcement 和端到端隔离验证时，不能把它们描述为企业级安全边界。

“Snapshot import 能不能叫备份恢复？”

早期导入只覆盖部分知识结构。当前产品将它明确称为“创建核心知识副本”：复制 Entity、Relation、Evidence 和规则，保留源项目，执行前进行 schema、引用、Scope、冲突和 fingerprint preflight，并保存 applied 或 partial receipt。

Simulation、Agent interactions、报告、活动和时间线不会被表述为已恢复。完整备份、生产迁移和灾难恢复仍是不同问题。

“恢复 timeline 是否等于 deterministic rerun？”

不等于。GET /api/simulations/{run_id}/timeline 恢复已经持久化的 run；新的 POST /api/simulations 是一次新执行。产品没有因为能读取历史记录，就声称拥有通用确定性重跑。

“Graph 成功而 Foundation 失败，是否整体回滚？”

没有真实跨存储事务时不能这样说。产品权威路径保留 Graph 已成功的事实，将 Foundation 状态标记为 pending/degraded，并使用同一个冻结决定显式重试；AF-X01 路径则使用 Proposal、Outbox、Executor 和 recovery state machine。两条路径都不静默回退到旧 authority。

“等待 24 小时是否可以证明稳定？”

在没有生产流量的情况下，空等不会增加稳定性证据。项目最终取消了把无流量时长当完成门槛的说法，保留真实完成的 controlled operations、重启、不可用/恢复、clone rehearsal 和浏览器验收，同时把生产流量、long soak 和 canary 明确留在未来认证范围。

这些调整都保留历史记录，同时更新当前状态与验收条件，便于后续追溯决定为何改变。

与 MemoryBear、MindMemOS 的关系

TraceWise 仓库保留了对 MemoryBear 和 MindMemOS 固定版本的机制审计。它们提供了有价值的研究参照：实体消歧、图形成、遗忘与摘要、反馈、Dreaming、Schema 和混合检索都值得研究。

但研究关系不等于运行依赖。TraceWise 没有部署这些项目，也没有把它们的完整实现复制进产品。审计采用的方式是：固定源版本，确认真实机制，找出最小反例，再决定是否只采用一个有明确所有权和恢复语义的子集。

例如，存在 reinforcement_count 字段不等于已经形成可信的检索策略；存在 Schema 保存接口不等于系统已经自动学习并发布新 Schema；跨 PostgreSQL、Neo4j 或向量库的写入也不能因为最终都成功过一次，就被描述成分布式事务。

这些外部研究最终强化了 TraceWise 的同一原则：模型或研究项目可以提供候选机制，产品仍要独立定义审批、权威、证据和失败边界。

我在这个项目中负责什么

我在 TraceWise 中的主要设计与实现工作包括：

• 将项目调查收敛为 Graph、Evidence、版本、规则、Simulation 和报告的一体化产品工作流；
• 设计受限上下文与结构化 AI Proposal，避免模型直接获得数据库写权限；
• 建立 ReviewDecision、Evidence lineage、stale fail-closed、幂等回放和显式恢复语义；
• 把产品与 Agent Foundation 物理拆分，并限制集成在精确版本和公共 API；
• 用最小反例、focused tests、真实 ASGI/数据库读取、浏览器验收和可复现 wheel 校准项目声明；
• 根据反例调整分析流水线、复制范围和跨存储恢复的合同与验收条件。

Foundation 提供的是平台公共契约和它所拥有的权威执行能力；Host Model 提供的是候选输出。TraceWise 项目负责把这些能力放进一个用户可理解、可审阅、可追溯的产品闭环。

当前做到哪里

当前正式基线已经验证：

• Graph/Evidence 检索、上下文组装和产品工作台；
• 历史 Entity version 真实驱动 inference；
• SimulationRun 持久化恢复且不重复调用 Host Model；
• 核心知识副本的严格 preflight、隔离身份、partial receipt 和响应式 UI；
• 不可变 ReviewDecision、Graph/Evidence drift、批准/驳回、回放冲突和 Foundation pending/retry；
• 两个受控本地 Foundation authority projects，以及未切换项目的兼容边界；
• 独立 TypeScript、ESLint、Vitest、Vite、Python regression、wheel parity、fresh install 和浏览器检查。

仍待完成的生产接入与验证：

• 生产 IAM、TLS、Secrets、tenant security、HA/DR；
• 生产流量、长期 soak 和 canary；
• Foundation Relation lifecycle 的完整产品消费；
• 通用 deterministic rerun；
• 模型准确率提升、benchmark 或效果归因；
• 自动跨存储回滚。

这里还有一个重要的时间边界：什么时候应该停止继续扩张。当前切片在用户工作流、最小反例、关键负例、真实 Authority 状态和交付身份都有相称证据后结束；生产 traffic、long soak、canary、HA/DR 和效果评估需要新的目标和环境。无流量地等待更久不会自动升级当前证据。

最后：TraceWise 真正想留下什么

TraceWise 并不试图证明“模型已经能独立理解整个项目”。它试图建立一套更可验证的合作方式：模型负责生成候选分析和 Proposal，人负责业务判断，系统负责冻结依据、限制权限、记录决定，并在依据变化时拒绝旧授权继续生效。

从逐条日志走到 Graph，从 Graph 走到 Evidence，从 Evidence 走到 ReviewDecision、版本和恢复，项目不断回答的是同一个问题：

当一个 AI 结论会影响真实项目状态时，我们如何知道它为什么成立，又如何在它不再成立时安全地停下来？

这也是 TraceWise 最值得长期保留的工程价值：它不以功能数量取胜，而是把“解释、权限、历史和失败”都变成了可以被检查的产品契约。

延伸阅读

• GOV.UK Service Manual：Learning about users and their needs
• Martin Fowler：Outcome Over Output
• NIST AI Risk Management Framework Core
• pdai.tech：问题分析——5W2H 分析法