从 AI 运行日志到内部评审应用
面向需要排查 AI 回答的小团队，介绍如何用 1flowbase 的运行记录、业务数据模型、API 与 React 界面构建一条可验证的评审流程。
同事反馈 AI 助手回答不对。截图只展示了结果，关键问题仍然没有答案：执行了哪个工作流？工具返回了什么？最终回答是否使用了这些证据？
原型阶段，可以人工查看一次日志。团队开始反复处理类似问题后，还需要负责人、处理结论，以及回到原始运行的链接。这时，AI 网关可以成为一个内部应用的起点。
1flowbase 将模型和工作流执行、运行检查、PostgreSQL 业务数据模型、API 和 React 界面放在同一应用基础中。本文说明如何用这些已文档化的能力，设计一个小型运行评审工具。这是建议的实现模式，不是现成评审模板，也不是已经完成部署的案例。
适合谁？
这个模式适合 AI 产品开发者、内部工具工程师，以及需要不定期调查助手回答的小团队。直接目标是回答“发生了什么，我们决定改什么”，同时避免把整段对话反复复制到表格和群聊。
第一版只需支持三件事：
- 找到需要评审的运行
- 检查可获得的执行证据
- 保存关联该运行的人工评审结论
如果内置日志页面已经足够，先用它。若你需要全公司的遥测体系、正式合规控制，或有保证的崩溃恢复引擎，应单独评估这些要求，不能从本场景推导出这些保证。
把执行证据与人工结论分开
已有的 Token BOM 指南解释了如何检查模型调用、工具回调和用量。应从这些记录中寻找证据，而不是仅凭最终回答猜测原因。
为内部应用增加一份自己的评审记录。例如：
评审记录（你创建的业务数据）
应用引用
运行引用
评审状态：待处理 / 调查中 / 已解决
问题分类
评审备注
创建时间与更新时间这些是建议创建的业务字段，不是产品预置列名。尽量保留原始运行的引用，不要复制完整提示、工具输出与回答。这样可以减少敏感内容的重复存储，也能明确区分人工判断和原始执行证据。
当前的日志结构说明记录了一份开发环境结构快照，包含任务、运行、消息和 trace 投影，并明确区分执行状态、是否观察到最终回答，以及 trace 投影是否就绪。其中任务级分组晚于 v0.4.1，不能假定该稳定版已经具备。这是三个不同问题：存在日志行不等于任务成功，展示内容暂不完整也不一定代表模型执行失败。
不要通过直接写入内部日志表来构建新应用。先确认安装版本支持的接口，并使用经过授权的读取路径。v0.4.1 控制台日志处理代码使用控制台授权，应用 API 密钥不等于读取管理日志的权限。如果需要的引用或字段暂时无法通过受支持接口取得，就先保留人工处理，不要把缺口隐藏起来。
先做一条最小闭环
1. 确定证据来源
使用非生产部署和合成提示，记录版本与模型配置。发出简单请求，确认回答能关联到日志和 trace。网关评估清单覆盖了这个前置步骤。
检查实际能看到什么：输入、输出、状态、模型调用、工具结果和用量。缺失字段应标为未知。token 数不自动等于金额，空输出也不自动等于成功回答。
2. 建立业务数据模型
使用 Data Model 能力定义小型评审记录，其生成的 CRUD API 用于管理这个应用自己的业务数据。需要在实现中校验必填字段和允许的状态转换。
v0.4.1 README记录了 Data Models、自动 CRUD API 和工作流 API。这说明基础能力存在，不代表无需配置就会出现完整的读写评审队列。
3. 增加一个精简界面
用 React/TSX blocks 构建评审列表和详情页。先提供按评审状态筛选，以及查看原始运行证据的入口。界面应清楚区分人工备注、模型输出和执行状态。
权限验证与布局同样重要。隐藏按钮不能代替后端授权。能够修改评审备注的人，不应因此自动获得所有对话或其他应用的运行数据。
4. 人工流程跑通后再引入 Agent 工具
文档中的 MCP Gateway 采用 mcp_list、mcp_get、mcp_call 渐进发现能力，可以帮助 Agent 发现并调用已暴露的功能。
只暴露当前任务需要的能力。核对调用身份与权限边界，区分只读检查和业务数据修改。即使第一版只在内部使用，也不应因此给 Agent 过大的写权限。
MCP 工具与应用模板仍在完善。构建复杂应用，目前应给 coding agent 提供 1flowbase 项目上下文。本文不承诺无需源码上下文即可自动创建任意应用。
什么才算这个工具有用？
用运行评审检查清单验证一条完整流程：
- 合成请求产生可识别的运行
- 评审者能通过授权路径查看相关证据
- 评审记录关联该运行，不重复复制不必要的敏感内容
- 修改评审状态后，可以重新读到保存结果
- 无权限用户不能取得其他应用的证据
- 对缺失、仍在处理或不可用的证据如实展示
完成界面的截图只能证明界面渲染出来了。以上检查才帮助你判断它能否支持实际调查。
存储记录的边界
保存对话和运行记录，有利于后续检查，但不能据此证明 worker 或进程崩溃后会自动恢复执行。恢复、重试归属、幂等性和外部副作用，需要按具体版本单独设计与验证。
数据保留也带来维护责任：保存哪些内容、谁能查看、保留多久、如何备份，都应提前决定。原始运行被清理后，评审记录可能仍然存在，需要明确保留安全摘要，还是标记证据不可用。即使应用和数据库自托管，云模型仍会接收到路由给它的数据。