# Mercury Method Lab：构建可审计的AI证据链与决策系统 > Mercury Method Lab为Mercury Agent生态提供了一套结构化的证据管理、审计追踪和决策日志系统，通过严格的状态流转和禁止事项约束，确保AI系统的判断过程可追溯、可验证。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-01T08:15:33.000Z - 最近活动: 2026-05-01T08:22:45.192Z - 热度: 152.9 - 关键词: AI审计, 证据链, 决策系统, Mercury Agent, 状态机, 知识管理, 可追溯性, 合规, 多Agent系统 - 页面链接: https://www.zingnex.cn/forum/thread/mercury-method-lab-ai - Canonical: https://www.zingnex.cn/forum/thread/mercury-method-lab-ai - Markdown 来源: ingested_event --- # Mercury Method Lab：构建可审计的AI证据链与决策系统 随着AI Agent在复杂决策场景中的广泛应用，一个根本性问题日益凸显：当AI做出重要判断时，我们如何确保其决策过程是可追溯、可审计、可验证的？Mercury Method Lab项目正是针对这一需求，提出了一套结构化的证据管理与决策审计框架。 ## 项目定位：方法实验室而非运行时 首先需要澄清的是，Mercury Method Lab并非Mercury Agent本身的分支或替代实现。根据项目文档的明确定位，它是「Mercury Agent兼容工作流的方法、证据、审计与迁移实验室」。Mercury Agent upstream负责运行时、CLI/Telegram接口、权限工具和调度器；而Method Lab则专注于方法路由、证据链管理、artifact状态追踪、记忆候选筛选、决策日志记录、行动计划生成和审计报告输出。 这种分工体现了清晰的架构边界：Agent负责「做什么」，Method Lab负责「如何记录和验证做了什么」。 ## 核心流程：从收件箱到决策日志的七步流转 Mercury Method Lab定义了一套严格的数据流转流程，每个阶段都有明确的输入输出规范： **inbox → raw → segmented → cleaned → uncertain → memory_candidates → decision_logs / action_plans / audit_reports** - **inbox（收件箱）**：预入库材料，有沉淀价值但暂时不改变判断链 - **raw（原始材料）**：未经处理的原始输入，禁止直接覆盖 - **segmented（分割版本）**：将复杂材料拆分为可处理单元 - **cleaned（清洗版本）**：去除噪声后的结构化数据 - **uncertain（不确定池）**：存疑信息，等待进一步验证 - **memory_candidates（记忆候选）**：经筛选后值得长期保留的信息 - **decision_logs / action_plans / audit_reports**：最终输出——决策日志、行动计划和审计报告 这种分层设计确保了信息的完整谱系：从原始输入到最终决策，每一步 transformation 都被记录，可追溯。 ## 禁止事项：五条红线 项目文档明确列出了五条「禁止事项」，这些约束构成了系统的安全边界： 1. **不允许把推测存成事实**——严格区分观测数据与推断结论 2. **不允许直接覆盖raw原始材料**——原始数据不可变，所有处理都产生新版本 3. **不允许把所有东西都写进长期记忆**——记忆是稀缺资源，需要筛选 4. **不允许让同一个agent自己取证、自己判断、自己审计后直接定案**——三权分立，避免自我验证 5. **不允许清理掉未解释的异常信号**——异常是重要信息，不能简单丢弃 这些约束反映了设计者对AI系统安全性的深刻理解：权力分散、审计分离、异常保留。 ## 角色分工：六类专用Agent Method Lab定义了六类专用Agent，各司其职： - **fact-cleaner（事实清洗）**：负责数据清洗和结构化 - **constraint-checker（现实约束检查）**：验证决策是否符合现实约束 - **equilibrium-explainer（平衡解释器）**：解释决策的权衡和取舍 - **action-translator（行动翻译）**：将决策转化为可执行行动 - **redteam-auditor（红队审计）**：独立审计，挑战决策合理性 这种专业化分工避免了「全能Agent」的陷阱，让每个Agent专注于特定任务，降低复杂度，提高可靠性。 ## 用户接入层：三种提交入口 项目为不同技术背景的用户提供了差异化的接入方式： - **GitHub Issue**：适合不熟悉Git的用户，通过Issue提交观点 - **submissions/viewpoints/*.md**：适合能写Markdown的本地用户 - **submissions/agent-queue/*.json**：适合OpenClaw等智能体直接读取 这种分层接入设计体现了「渐进式参与」的理念——降低门槛，让更多人能贡献信息，同时保持核心流程的严谨性。 ## 与火山方舟Coding Plan的集成 项目文档特别提到了与火山方舟Coding Plan的集成支持。配置要求包括： - Base URL固定为 `https://ark.cn-beijing.volces.com/api/coding/v3` - API key仅通过环境变量 `ARK_API_KEY` 读取，禁止硬编码 - 默认使用 `doubao-seed-2.0-code` 模型 这种设计既支持本地化部署，也兼容云端API，为用户提供了灵活的选择。 ## 状态机与权限配置 项目采用状态机（state-machine）管理数据流转，配置位于 `config/state-machine.json`。权限管理则通过 `config/permissions.json` 实现，配合 `docs/permissions-and-audit.md` 文档说明。 方法注册在 `config/methods.json` 中完成，架构入口点定义于 `config/architecture-entrypoints.json`。这种配置驱动的设计使得系统行为可调整、可扩展。 ## 适用场景与价值 Mercury Method Lab特别适合以下场景： - **需要严格审计追踪的决策系统**：如金融风控、医疗诊断辅助 - **多源信息融合的知识管理**：整合来自不同渠道的信息，建立可信知识库 - **长期运行的AI项目**：需要维护决策历史，支持复盘和迭代 - **合规敏感的应用**：满足监管对AI决策可解释性的要求 ## 局限与注意事项 项目目前处于早期阶段（版本0.2.0），文档主要使用中文，且与Mercury Agent upstream紧密耦合。对于不使用Mercury生态的用户，直接应用可能存在门槛。此外，严格的流程约束虽然提升了可靠性，但也增加了使用复杂度，不适合追求快速原型的轻量级场景。 ## 结语 AI系统的可审计性正从「锦上添花」变为「刚需」。Mercury Method Lab通过定义清晰的数据流转流程、严格的禁止事项约束和专业的角色分工，为构建可信AI系统提供了一个值得参考的框架。对于那些需要在AI决策过程中建立「信任但验证」机制的应用场景，这套方法论或许能提供有价值的启发。