Marico's space
最近折腾小红书创作者分析智能体（Agent），踩了几个坑才明白一个道理：Agent 写出来的报告看着挺流畅，但能不能这么写才是关键问题。
如果 Agent 读取了三篇可见的帖子，然后悄悄把它们描述成"完整的账号策略"，问题不在于文字功底，而在于隐蔽的范围扩张。
做开源技能的过程中，我发现最有效的设计改进是把"覆盖账本"放在每个结论之前。
账本把四个计数明确下来：
同时还记录停止条件、重复项、低信息量条目、失败或跳过的条目，以及仍未覆盖的素材。
这个区分很重要——一次成功的 HTTP 响应不等于一篇可读的帖子，可读的样本也不等于完整的账号。
工作流使用三种模式，作用域刻意不同：
模式不仅仅是实现选择，它定义了最终报告被允许说什么。
工作流分离了三层证据：
这防止了一个常见偷懒：用标题、时间戳或互动数来"证明"写作风格、作者意图或受众反应。
对于内容机制类的结论，中等或高置信度的声明必须回溯到多个独立的 Nxx 条目。冲突和反例保持可见，而不是被平均掉。
系统只暴露两种顶层状态：
HOLD 不是要隐藏的错误。当继续下去需要猜测或绕过访问控制时，HOLD 是正确答案。
举个例子，一次真实的小红书短链边界测试到达了一个通用页面，但产生了：
预期和实际结果都是 HOLD。Agent 没有登录、没有用 cookie、没有绕过边界，也没有声称完成了成功的账号分析。
仓库目前包含：
五篇文章测试通过了每个适用的评分项，包括证据可追溯性、范围诚实性、不确定性、用抽象而非模仿、以及数据安全。
局限性同样重要：这些是维护者的自我测试。不是独立采用案例，不是正向的小红书端到端结果，也不能证明跨模型语义质量。语义评估仍然是手动的或由独立智能体执行的。
覆盖账本不只对创作者分析有用。当智能体总结部分可见的语料时，同样的模式都适用：
在问"智能体发现了什么模式？"之前，值得先问：
没有这四个事实，置信的答案难以审计。
实现以 MIT 许可证发布在 xhs-creator-distill 仓库。真实世界的测试产物与合成示例刻意分开，标注了第三方归属和离线策略门控。
目前正在决定先做哪个确定性导出适配器。如果有人愿意在两点上给技术反馈会很感兴趣：