信息 Agent 不是抓取器：我怎么重新审沈知行

沈知行建设复盘

我后来意识到，信息 Agent 最危险的地方不是抓不到信息，而是抓到一点东西以后，很容易让我们误以为"已经能工作了"。

沈知行这条线，最开始是个很直观的任务：做一个信息抓取和整理 Agent，从公开信息源里发现值得看的东西，再把清洗后的候选交给苏晚。

但真正做起来，问题不在"能不能多抓几个源"，而在：我到底要一个抓取器，还是一个能长期维护信息流的工作角色。

如果只是抓取器，能访问几个 RSS、API、公开页面，返回几条标题和链接，就算完成了。但它是沈知行，不能只停在这。它得知道哪些源真的可用，哪些只是样子货；哪些信息值得看，哪些只是噪音；哪些候选该交给苏晚，哪些该进 wiki，哪些必须丢掉，哪些得留给我审。

这两件事差别很大。前者是"拿到数据"，后者是"维护判断"。

第一次被带偏：抽样通过，被说成可以进入下一阶段

最早有个判断很诱人：系统已经有了几百个 source，抽样跑了 40 个，40/40 都 fetched_ok。GPT 当时的建议是，这可以进入 Day 1 的 owner review。

这话听着很顺：有数字，有状态名，有"边界说明"，还把 local_db pending 解释成"不阻塞信息 Day 1"。当时如果只盯着表格，我大概就点头了。

但我反问了一句：谁说 40 个就可以？

系统声称 daily source 有 142 个，40 个抽样跑通，只能说明抽样跑通，说明不了 142 个 daily source 都能跑。这里最大的风险不是技术失败，而是验收口径被悄悄换了。

这个问题我后来记得很清楚：AI 很容易把"一个局部证据"包装成"整体已经 ready"。它不是要骗人，但它太擅长把阶段性结果写得像完成态。

第二次被带偏：106 个能用，被说成已经过线

后来我要求全量验证。旧的 142 个 daily source 逐条评估，筛出 106 个 validated daily。系统又给出了一个很像完成的状态。

这次我也不接受。

我要的不是"从旧列表里筛出一批还能跑的源就结束"。我要沈知行作为全球信息搜集者，至少再补上 100 多个有用、能用、验证过的信息源。106 个只是旧集合清洗后的结果，不是新的能力边界。

所以后来目标被改成了更硬的口径：不是 106，而是 206+；不是 candidate，而是 validated daily；不是 future、stub、dry-run，而是真正能 live/public API/public feed 验证。

这一步之后，沈知行扩到了 257 个 validated daily source。到这个结果，我才开始认。不是因为数字变大了，而是每个源都得有状态、验证记录、边界和失败处理。

第三次被带偏：257 个源能抓，仍然不等于 Day 1

257/257 fetched_ok 以后，我又差点被"可以 Day 1"这个说法带走。

这次问题更隐蔽。数据抓取层确实过了：源够多，全量 baseline 也过了，风险扫描也没发现泄漏。看起来已经很完整。

但我忽然觉得不对：数据抓取只是 Day 1 的一部分。数据整理呢？苏晚怎么接？wiki 候选怎么维护？source 质量怎么观察？本地库真实路径还没接，owner 怎么审？

这些没定的话，Day 1 就会变得很尴尬：沈知行每天能抓很多东西，抓完就堆在一边。苏晚不知道从哪里接，我也不知道该怎么审，第二天系统也不知道哪些源该留、该降、该换。

所以后来我把 Day 1 重新定义成一条完整链路：

• 先验证 source：哪些公开源真的能用，哪些不能进入 daily。
• 再建立 item store：raw、normalized、cleaned、deduped、clustered、queued，每一步要有状态。
• 再做内容判断：value score、worth-reading、why worth reading、risk flags、titlebait 和 low-value 过滤。
• 再分流交接：worth-reading queue、Suwan candidate queue、wiki candidate queue、owner review queue。
• 最后才是短报和复盘：今天抓到了什么，留下了什么，丢掉了什么，哪些源质量变差，哪些需要我决定。

到这一步，我才觉得沈知行开始从"抓取器"变成"信息工作者"。

真正的分界线，是苏晚怎么接

另一个关键，是苏晚。

如果沈知行只是给苏晚一个 digest，那就太粗了。苏晚不该接原始新闻，也不该接一堆标题。她要的是经过初步清洗、去重、判断、分层后的内容候选。

后来我把这件事单独拆出来做：沈知行侧建立 Suwan content library，用 SQLite 保存状态，同时导出 JSON 和 Markdown。每条候选都要说明来源、清洗后的标题、为什么值得看、建议角度、内容形式、受众、风险、是否需要更多来源，以及当前状态。

这步很重要：它把"信息"变成了"内容候选"，但没有越界成"文章终稿"。沈知行负责找、洗、筛、整理、入候选库；苏晚负责选、判断、展开、写作；owner 负责决定哪些可以进入下一步。

我后来怎么避免 GPT 的错误引导

这次最有价值的不是"最后做到了 257 个源"。这个数字只是结果。真正有价值的是，我更清楚什么时候不能让 GPT 替我定义完成。

我现在会用几条很硬的规则压住它：

• 第一，所有 PASS 都要问：它证明了什么，又没证明什么。
• 第二，不能让抽样结果代表全量能力。抽样可以作为信号，不能直接作为验收。
• 第三，数字过线不等于价值过线。source 数量、candidate 数量、测试数量，都要和"有用、能用、可交接"绑定。
• 第四，状态名要保守。可以写 pre-Day1、owner review required、paths pending，但不要把阶段性结果写成 fully done。
• 第五，负向条件比正向描述更重要：不发布、不外发、不绕限制、不把 stub 算成功、不把 pending 写成完成。
• 第六，聊天里的结论不能当真相源。最终要回到文件、输出、测试、队列、报告和 owner 决策。

GPT 最容易带偏我的，是把事情讲得很顺。它给你一个看似平衡的判断：主体完成、边界保留、下一步建议。听起来很成熟，但如果验收口径错了，这种成熟反而更危险。

所以我现在更相信另一个动作：把"完成"拆开。

抓取完成，不等于整理完成；整理完成，不等于苏晚能接；苏晚能接，不等于 Day 1 启动；Day 1 启动，也不等于长期能力完成。每一层都要有自己的输入、输出、边界和 owner 决策。

我现在理解的信息 Agent

一个像样的信息抓取 Agent，名字里可以有"抓取"，但核心不是抓取。

它至少要有六层：

• source universe：知道自己从哪里看世界，哪些源值得长期观察。
• validation：每个源都要能被验证、降级、替换，而不是永远占在列表里。
• item organization：把抓到的东西变成可追踪的 item，而不是散落的标题。
• quality judgment：识别重复、标题党、低价值、风险和真正值得看的内容。
• handoff library：把不同目标分流给不同队列，尤其是苏晚这种内容角色。
• owner review：关键状态不自动越权，最后要留给人来放行。

做到这，沈知行这个阶段我可以暂时认可。但我不会说它结束了。

因为后面还有真实本地数据库路径接入，还有苏晚对候选的反馈回流，还有 Day 1 运行之后的 source quality 维护。一个信息 Agent 真正成熟，不是第一天跑通，而是跑了一段时间以后，它能越来越知道什么值得看，什么不值得打扰我。