构建可审计的研究 Agent：证据账本、沙箱与回放

先说结论： 可信的研究 Agent 需要两份彼此独立的契约。研究契约规定如何记录主张、来源、冲突和置信度；执行契约规定工具在哪里运行、能使用哪些凭证，以及事后如何检查每一步。本文把开源的 SandBase Skills 证据账本工作流与 SandBase Harness 的持久会话、沙箱工具、审计和回放组合起来。

为什么“答案看起来不错”还不够

一份语言流畅的报告仍然可能是错的。真正缺失的往往不是写作质量，而是证据链：

每个关键主张由哪个来源支持？
两个引用是否真的相互独立？
是否有可信来源给出了相反结论？
证据冲突时，置信度是否随之降低？
哪些工具调用生成了这些产物？
其他人能否重放本次运行？

前四项可以通过严格的研究方法改善；文件系统边界、凭证策略、持久事件日志和回放则必须由运行时保证。反过来，一个治理完善的运行时也无法自动修复薄弱的研究方法。

因此更实用的架构是分层的：

层	职责	开源组件
研究方法	来源多样性、主张映射、冲突、置信度	multi-source-search Skill
输出验证	拒绝格式错误或内部矛盾的证据账本	随 Skill 提供的离线验证器
Agent 运行时	会话、工具、权限、凭证和产物	SandBase Harness
隔离	本地、Docker、Kubernetes 或自托管 Worker 沙箱	Harness 沙箱后端
检查	持久事件、可恢复流、审计和回放	Harness 会话运行时

第一步：安装研究契约

旗舰 Skill 可以使用宿主 Agent 已有的搜索与页面读取工具；这个工作流本身不要求 SandBase 账户。

使用 GitHub CLI 官方 Skill 命令预览或安装：

gh skill preview sandbaseai/sandbase-skills research/multi-source-search

gh skill install sandbaseai/sandbase-skills research/multi-source-search \
  --agent codex --scope user

也可以安装到一个 DeepSeek Harness 项目：

npx --yes github:sandbaseai/sandbase-skills add multi-source-search

命令会在当前项目创建 .dsh/skills/multi-source-search。这份 Skill 要求 Agent 区分一手与二手证据，把主张映射到来源 ID，明确记录冲突，并在证据尚未一致时避免给出虚高置信度。

可以用一个具有明确验收边界的问题测试：

比较 GitHub、GitLab 与 Bitbucket 的分支保护能力。
尽量使用官方文档，区分观察事实与推断，记录冲突，
并返回机器可检查的证据账本。

第二步：把证据账本变成构建产物

仓库包含完整示例和离线验证器：

git clone https://github.com/sandbaseai/sandbase-skills.git
cd sandbase-skills

python3 research/multi-source-search/scripts/validate_report.py \
  examples/verifiable-research-report.json

有效报告会输出：

VALID: 3 source(s), 1 claim(s), 2 provider(s)

验证器检查的是内部一致性，包括：

引用了不存在的来源 ID；
把重复来源伪装成独立证据；
收集了证据却没有用于任何主张；
置信度与引用支持程度不一致；
存在未解决冲突，却仍给出高置信度。

这个边界很重要：验证器不会宣称某个网页必然真实。它证明的是报告遵循了自己声明的证据模型。高风险决策仍需要人工抽查或第二轮独立核验。

JSON 报告应被当作正式产物，而不是一次性模型输出。它可以进入版本控制、作为会话附件保存，或者传递给后续审查步骤。

第三步：在受治理的运行时中执行

SandBase Harness 是本地优先的 Agent 运行时，不是另一个模型 SDK。它在模型循环周围增加持久会话、凭证、权限策略、产物和沙箱后端。

从当前标签构建运行：

git clone --branch v0.3.4 --depth 1 \
  https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run build

mkdir ../my-research-agent
cd ../my-research-agent
node ../sandbase-harness/dist/index.js init
node ../sandbase-harness/dist/index.js start

打开 http://127.0.0.1:3000/dashboard，在 Settings 中配置模型，然后按风险选择沙箱：

可信的开发流程可使用本地进程；
需要每会话容器边界时使用 Docker；
已有集群控制面时使用 Kubernetes；
必须在独立管理的机器上执行时使用自托管 Worker。

不要把凭证值放入提示词。凭证应保存在运行时 vault 中，只附加给确实需要它的工具；变更和网络访问则通过权限策略控制。

第四步：连接 Skill 与运行时

原生 DSH 工作流可以安装完整 Skills bundle：

dsh plugin --profile web add github:sandbaseai/sandbase-skills
dsh web

对于兼容 MCP 的客户端，Harness bridge 还提供固定版本的多架构 OCI 镜像：

docker pull ghcr.io/sandbaseai/sandbase-harness-mcp:0.3.4

docker run --rm -i \
  -e MANAGED_AGENTS_URL=http://host.docker.internal:3000 \
  ghcr.io/sandbaseai/sandbase-harness-mcp:0.3.4

运行时启用认证时，通过进程环境传入 MANAGED_AGENTS_API_KEY。不要把它写入插件 manifest、提示词或提交到仓库的配置。

两部分解决的是不同问题：

Skill 教 Agent 如何研究；
MCP bridge 提供受治理的运行时操作；
Harness 事件流记录实际发生了什么。

第五步：运行前定义验收标准

机械化的“完成”定义更容易审查：

验收标准：
- 至少三个来源，其中两个是一手来源。
- 每个重要主张都引用一个或多个来源 ID。
- 冲突必须明确列出，不能静默调和。
- 证据账本通过 validate_report.py。
- 原始笔记和最终 JSON 保存为会话产物。
- 会话中不出现任何凭证值。
- 审查者可以回放会话并找到每个已使用的工具结果。

这样，评价标准就从“文字是否令人信服”转向一组可检查的属性。

第六步：审计运行结果

完成后检查三个层面。

1. 研究完整性

运行验证器，并人工抽查最重要的引用。确认 URL 可访问、转述与原文一致，并检查所谓“独立来源”是否只是同一公告的转载。

2. 执行完整性

查看工具调用、权限决策、产物写入和沙箱选择。即使答案正确，如果 Agent 获得了不必要的高权限，仍属于运行失败。

3. 回放完整性

恢复或回放会话，确认最终结果可以从记录的事件和产物重建。Harness 通过持久会话和可恢复事件流，使审查不依赖临时终端输出。

最小威胁模型

上线前至少检查以下风险：

威胁	控制措施
搜索结果包含提示注入	把检索文本视为数据，维持系统与 Skill 指令优先级
模型编造引用	强制来源 ID，并运行验证器
两个镜像页面被当作独立来源	规范化来源并检查出处
工具写出项目目录	使用沙箱边界与权限策略
密钥泄漏到提示词或产物	使用凭证 vault，并审查产物
最终文字掩盖分歧	强制冲突字段与校准后的置信度
无法复现本次运行	持久化会话事件并附上证据账本

没有任何单项控制可以解决全部问题。目标是纵深防御，并留下能够暴露失败的产物。

应该衡量什么

对于重复运行的研究流程，建议衡量过程质量，而不仅是主观答案评分：

重要主张的证据覆盖率；
一手来源支持比例；
未解决冲突率；
验证器失败率；
被拒绝或升级审批的工具调用数量；
产物完整率；
成功回放率；
每份报告的审查时间。

这些指标让改进可以被验证：更好的模型可能改善综合能力，更好的 Skill 可以提高证据覆盖率，更好的运行时策略则可以降低执行风险。

复现、检查、改进

两个组件均以 Apache-2.0 开源：

sandbaseai/sandbase-skills：88 个可移植 Agent Skills，包括证据账本工作流与验证器。
sandbaseai/sandbase-harness：本地优先的 Agent 运行时，提供会话、沙箱工具、凭证、审计、回放与 MCP 集成。

建议先运行证据账本示例，再把同一个任务放入沙箱化 Harness 会话中。像审查一位不受信任的同事那样审查 Agent：核对主张、检查动作，并要求可回放的轨迹。这就是“能生成文字的 Agent”与“工作结果可以被验收的 Agent”之间的实际差别。