AI分析Agent应内置覆盖率账本，避免隐藏的 scope 扩展

AI分析Agent应内置覆盖率账本，避免隐藏的 scope 扩展 | 前端进阶之旅

Full translation

完整中文译文

声明：本文在撰写和发布过程中得到了 OpenAI Codex 的协助。下方所有事实性声明在发布前均已对照公开的仓库资料进行了核实。

一个创作者分析 Agent 可以根据少量帖子生成一份行文流畅的报告。但更关键的问题是：这份报告是否有资格做出它所声明的那些结论。

如果一个 Agent 读取了三篇可见的帖子，然后悄然将它们描述为一套完整的账号策略，那么问题不在于文笔拙劣——而在于隐蔽的范围扩张。

在构建一个用于小红书创作者分析的开源技能时，我发现最有用的设计改进是在每个结论之前放置一份覆盖账本（coverage ledger）。

账本将四个计数明确记录：

它还记录了停止条件、重复条目、低信息量条目、失败或跳过的条目，以及仍未覆盖的素材。

这一区分很重要，因为一次成功的 HTTP 响应不等于一篇可阅读的帖子，而一个可读的样本也不等于一个完整的账号。

工作流使用三种模式，它们各自的覆盖范围是经过刻意设计的：

QUICK_SET：深度分析用户提供的 3–8 篇帖子。不进行网络访问，且提供的每个条目都会被纳入。

PUBLIC_SAMPLE：仅检查公开可读的材料，清点一个有界的范围，并透明地选取样本。它绝不能被呈现为全账号覆盖。

ACCOUNT_PACKAGE：首先清点用户提供的导出包或数据包，然后选取 3–8 个条目进行深度分析。即便如此，声明也仅限于该数据包，而非经过独立验证的平台导出。

模式不仅仅是一个实现选择。它决定了最终报告被允许做出什么样的声明。

工作流将三层证据分离：

Sxxx 标识在账号或数据包清点过程中发现的条目。

Nxx 标识被选中进行深度分析的完整条目。

Axx 标识从成功解析的清点字段中计算的聚合值，包括其分子、分母和排除项。

这防止了一种常见的捷径：将标题、时间戳或互动数当作写作风格、作者意图或受众反应的证明来使用。

对于内容机制，中等或高度置信的声明必须回溯到多个独立的 Nxx 条目。冲突和反例保持可见，而不是被平均掉。

系统只暴露两个顶层状态：

PASS 意味着报告在声明的覆盖范围内是可支撑的。

HOLD 意味着缺失的内容、模糊的身份、访问限制、不安全的输入或不足的证据阻止了一份完整报告的产生。

HOLD 不是需要隐藏的错误。当继续下去需要猜测或绕过访问控制时，它就是正确的输出。

例如，一次真实的小红书短链边界测试到达了一个通用页面，但产生了：

预期和实际结果都是 HOLD。Agent 没有登录、使用 Cookie、绕过边界，也没有声称进行了一次成功的账号分析。

仓库目前包含：

五篇文章测试通过了每一项适用的评分标准，包括证据可追溯性、范围诚实性、不确定性、以抽象代替模仿，以及数据安全性。

局限性同样重要：这些是维护者的自我测试。它们不是独立采用的结果，不是一个正面的小红书端到端结果，也不能证明跨模型的语义质量。语义评估仍然是手动进行的，或由独立 Agent 执行。

覆盖账本在创作者分析之外也很有用。当 Agent 总结一个部分可见的语料库时，相同的模式适用：

在问「Agent 发现了什么模式？」之前，值得先问：

没有这四个事实作为基础，一个自信的答案是难以审计的。

实现方式可参见 MIT 许可的 xhs-creator-distill 仓库。真实世界的测试产物被刻意与合成示例分离，包含第三方归属和离线策略门控。

我目前正在决定首先构建哪个确定性导出适配器。我对以下两点的技术反馈感兴趣：