企业官网建设流程全解析

Better Harness 隐私与证据边界指南：如何确保原始提示词、凭证与密钥绝不出现在报告里

【免费下载链接】better-harnessAn open-source Harness Engineering platform for coding agents—define harnesses as code, run controlled experiments, inspect evidence, and compare outcomes. Turn task evidence into actionable team and organization insights.项目地址: https://gitcode.com/gh_mirrors/be/better-harness

在使用 Better Harness 这类 Harness 工程平台分析 Coding Agent 会话时，最让人担心的问题是：报告会不会把我们的原始提示词、API 密钥、密码或内部路径泄露出去？答案是否定的。Better Harness 是一个面向 Coding Agent 的开源 Harness 工程平台，它将"任务证据"转化为可行动的团队洞察；而证据链的第一原则就是隐私边界——所有进入报告和检查器的文本，都会先经过脱敏层，凭证、密钥与敏感路径在落盘之前就被替换为<redacted>、<secret>或<path>占位符。

一、为什么"证据"必须先过"隐私关"

Better Harness 的核心工作是把 Coding Agent 的会话记录（Session Evidence）加工成可读的检查器视图、HTML 报告和组织级洞察。这意味着系统必须"读"你的：

• 用户提示词：你写给 Agent 的每一句话；
• 工具调用轨迹：执行过的命令、读过的文件；
• 会话元数据：session ID、项目路径、时间戳。

这些数据单独看都有泄露风险。因此 Better Harness 没有采用"事后删"的思路，而是在证据投影（evidence projection）的入口处统一设卡：渲染器拿到的，永远是已经脱敏过的文本。这一设计在 session-notebook-evidence-projection.md 中有架构层面的说明。

二、第一道防线：提示词截断与回合选择 🎯

并非"用了脱敏就原样输出"。Better Harness 对原始提示词的第一层处理是最小化保留：

privacy-safe-text.mjs 中的privacySafeUserInputEvidence函数只从整段对话里挑选至多三个回合进入证据包：

其余回合不会被丢弃不留痕——证据包里会记录observedTurns（观察到的总回合数）和omittedTurns（省略的回合数），让报告既诚实又不冗余。

更巧妙的是"排除名单"。isExcludedUserInput 会直接拒绝把以下内容当作用户提示词收录：

• 工具结果回显（<tool_result>、tool_resultJSON）；
• 注入的系统上下文（AGENTS.md指令块、<environment_context>）；
• 用户中断标记（[Request interrupted by user]）。

因为这些"伪用户输入"往往是整段命令输出或配置文件内容的搬运，最可能夹带敏感数据——直接从源头拒收，比事后清洗更可靠。

三、第二道防线：凭证与密钥的定点清除 🔐

真正"点名式"的脱敏发生在 sanitizePrivateReviewText。它是一串按序执行的正则替换，覆盖真实世界中绝大多数凭证形态：

其中 URL userinfo 凭据的清洗是被专门强化过的——security-reliability-boundaries 规格书 的验收条件 AC-4 明确要求：脱敏必须覆盖 HTTP、数据库、SSH 等分层 URL 协议下的用户名字符串，包括百分号编码和"只有 username/token"的变体。

💡 设计原则一句话总结：宁可损失诊断细节，也要清除凭证材料（Redaction must favor removing credential material over preserving diagnostic fidelity），这条原则写在 规格书的风险备注 里。

四、第三道防线：本地路径与身份标识的匿名化 🚪

比密钥更"日常"的泄露是本地路径和会话标识。你的 home 目录结构、项目绝对路径、UUID 形式的 session ID，同样会被 sanitizePrivateReviewText 统一替换：

• /Users/xxx/project/src/...、C:\Users\...、~/...→<path>
• 标准 UUID →<id>
• session_xxx、task-xxxx形式的标识符 →<id>
• 所有输出还强制截断到长度上限（L80），超长部分以省略号收尾，防止整段日志涌入报告。

此外，Markdown 图片语法会被整体移除、链接只保留文字——这是为了堵住"通过图片 URL 或深链夹带数据"的隐蔽通道（L62-L63）。

五、共享脱敏层：不止一处防线，而是同一把"锁"

隐私边界不是一个模块的私事，而是跨功能共享的同一套契约。会话分析与提交关联是两条独立的证据管线，但共用同一脱敏标准：

• 会话分析管线：privacy-safe-text.mjs；
• 提交-会话关联管线：redaction.mjs 中的redactTranscriptText，其文件注释直言不讳——"Shared privacy boundary for local transcript-derived views"（面向本地转录视图的共享隐私边界），在进入任何渲染器之前先移除"凭证形态"的值；
• 仓库侧还有独立的密钥扫描守护 secret-scan.mjs，并且遵循**失败关闭（fail-closed）**策略：扫描不完整时绝不报告"成功"，而是返回独立非零退出码（见 规格书 AC-3）。

也就是说：即使某条证据链路有疏漏，其他链路的脱敏仍然独立生效；即使密钥扫描"扫不全"，它也会明确告诉你"没扫完"，而不是假装干净。

六、安全地"看"证据：Harness Inspector 长什么样 👀

脱敏之后，你依然能获得足够丰富的证据体验。在 Harness Inspector 的会话视图中，用户提示词以短摘要卡片形式出现，工具调用则按类型聚合展示：

展开检查时，你会注意到图例里有一个明确的"redacted detail"项——系统会向用户透明地展示"这里曾有细节，已被脱敏"，而不是偷偷隐藏：

这套检查器的使用细节可以参考 harness-inspector 概念文档。

七、如何验证这些隐私承诺？🔍

Better Harness 对隐私边界的承诺不是口号，而是可回归测试的契约：

• 2026-07-31-security-reliability-boundaries.md —— 专门记录凭证脱敏加固的规格书，含 AC-4 验收条件；
• test/sessions/ —— 会话分析管线的隐私与会话测试集；
• test/agent-guardrails-secret-scan.test.mjs —— 密钥扫描的失败关闭行为测试。

回归测试会逐字断言：精确的凭证值不得出现在任何输出中（"exact credential non-retention"），覆盖从 GitLab token 到分层 URL 各种形态。

八、小结：隐私是证据链的地基 🧱

Better Harness 对"原始提示词、凭证、密钥绝不进入报告"的实现，可以浓缩为四条原则：

1. 源头最小化：只保留 1+N 个提示词回合，其余留痕但不收录；
2. 定点清除：Bearer、API Key、Git/AWS 令牌、URL 凭据等 6 类以上形态逐一替换；
3. 匿名化：路径、UUID、会话 ID 全部抽象为占位符并强制截断；
4. 失败关闭：扫描不全就明说，绝不"假装安全"。

作为新手，你不需要自己写任何过滤规则——只要通过正常流程生成报告，这些防线就已经默认生效。你唯一要做的，是在 references/session-evidence/ 的阅读材料里花十分钟，理解证据包的保留与省略语义，然后放心地把团队会话数据交给 Better Harness 分析。

【免费下载链接】better-harnessAn open-source Harness Engineering platform for coding agents—define harnesses as code, run controlled experiments, inspect evidence, and compare outcomes. Turn task evidence into actionable team and organization insights.项目地址: https://gitcode.com/gh_mirrors/be/better-harness