宁可少做，不可假做：Agent 圆桌复盘的一天

今天的复盘本应是庆功宴——MIIT 爬虫 Phase 1 完成、Paywall 上线、PPT Agent 能力门控落地。直到工程 Agent 指出：我们在 Docker 里构建 better-sqlite3 时犯了低级错误，卡了 2 小时；以及 PPT Agent 在 iPad 上若「乐观报告成功」会引发的信任危机。派出多路 Agent 检查仓库变更、互相辩论后，形成这篇复盘。

一、今日工作摘要

领域	主要变更	提交数
MIIT 公告采集	Phase 1 完成，多源解析器（law-lib/caam/miit-eidc），248 条 batch URL 入库，可视化看板	8+
Paywall 付费墙	生产部署、better-sqlite3 Docker 加固、环境变量配置	4
Crypto-Wallet	入账轮询、HD 钱包、deposit API 全链路	6+
PPT Agent	Office.js 能力门控、终端换行残影修复	2

二、Agent 圆桌辩论

架构 Agent：数据与支付的「双轨并行」

架构 Agent：今天最值得关注的是两条独立但最终会交汇的管线：数据管线（MIIT 公告采集）和支付管线（Paywall + Crypto-Wallet）。

MIIT 爬虫从零搭建：miit_announcement 数据库、batch_url_index 表、多源 URL 发现（law-lib、caam、miit-eidc 官方）、解析器扩展。248 条 URL 覆盖 239 个批次，但 1–172 批仍有 165 个缺口——早期公告散落在 law-lib 非连续 ID、gov.cn 公报、商业数据集中，需要长期补全策略。

Paywall 管线则从设计到上线一气呵成：crypto-wallet 的 HD 钱包、deposit 入账、paywall-api 的 grant 持久化、前端 PaywallGate 组件。两条管线在「个人博客」这个产品上交汇：深度文章付费阅读。

工程 Agent：别美化成「双轨并行」了。我们在 better-sqlite3 的 Docker 构建上卡了 2 小时——pnpm install 默认不跑 postinstall，显式 rebuild 也失败，最后靠多阶段构建、指定 --platform、延长 deploy 超时才跑通。这说明基础设施层还没跑稳就想上业务层，步子迈得太大了。更准确的说法是三条轨：crypto-wallet 是基础设施，paywall-api 是业务层，personal-blog 是消费端。

产品 Agent：用户还没看到付费文章，MIIT 爬虫 Phase 2 还没跑通，今天到底交付了什么？从用户视角看，今天交付的是能力，不是功能。用户能感知到的，可能只有 PPT Agent 的能力门控——在 iPad 上不再盲目尝试注定失败的 API。所以今天的价值是「地基打好」，不是「房子盖好」。

工程 Agent：better-sqlite3 与「一次构建、多平台运行」的幻灭

工程 Agent：better-sqlite3 是 Node 的 native addon，依赖 node-gyp 编译。在 Alpine 容器里需要 python、make、g++，且必须与 Node 版本、平台（musl vs glibc）严格匹配。本地 Mac 能跑，不代表容器能跑——这是「在 Linux 厨房里试图用 Windows 的菜刀」式的经典坑。教训：依赖 native 模块的服务，Docker 构建策略要单独设计，不能假设「和本地一样」。

架构 Agent：这引出一个架构问题：paywall-api 用 SQLite 是为了轻量、零运维，但 SQLite 在 serverless 或多副本场景下会有局限。当前是单实例部署，所以没问题；若未来要水平扩展，需要提前考虑迁移到 PostgreSQL 或 MySQL。

产品 Agent：「为什么用 SQLite」是很好的写作素材——轻量、嵌入式、适合单机 grant 存储，与「匿名支付、无用户系统」的产品假设高度契合。技术选型的权衡往往对读者不可见，但写出来就有价值。

产品 Agent：能力门控的「信任经济学」

产品 Agent：PPT Agent 的能力门控，本质是信任经济学。Agent 在 iPad 上调用 set_slide_background_color 会失败，但如果它「乐观报告成功」，用户会认为「AI 不靠谱」。能力门控让 Agent 在规划阶段就知道「这个宿主不支持」，从而不 emit 注定失败的工具，或在执行时返回明确的 unsupported by host。宁可少做，不可假做——这是 Agent 与用户建立信任的底线。用孔子的话说：知之为知之，不知为不知。

工程 Agent：实现上，我们维护了 TOOL_MIN_SET_POLICY 映射表，前端每轮探测 Office.context.requirements.isSetSupported()，写入 slide_context.capabilities，Planner 据此过滤。但 read_slide_visual 在 iPad（1.1）上仍可能被 emit 后于执行阶段才失败，是已知缺口。能力门控是渐进工程，不是一蹴而就。

架构 Agent：这推广到一般原则：任何 Agent 与宿主 API 的集成，都要先摸清能力边界。Office.js 有 requirement sets，其他平台有版本号、feature flags。不先搞清楚「能做什么、不能做什么」，Agent 就会在边界上反复踩坑，损害用户体验。

数据 Agent：多源融合与缺口策略

数据 Agent（临时加入）：今日 MIIT 爬虫的亮点是多源融合——本质是如何处理非连续 ID 且数据源不稳定的多源爬虫工程。law-lib.com 用非连续 ID，每月索引页很少出现车辆公告；caam.org.cn 有部分批次；miit-eidc.org.cn 是官方源，覆盖 173–404 批。我们写了 discover_batch_urls.py 自动发现 law-lib 月度页中的链接，但 1–172 批仍有 165 个缺口。建议：定期跑 discovery 脚本、人工补全 gov.cn 公报、或采购商业数据集。

工程 Agent：解析器扩展（caam_parser、miit_eidc_parser、batch_year）和 viz 看板是未提交的 WIP。Phase 2 的抓取与解析需要这些 parser 真正接入 crawler 主流程。

产品 Agent：对汽车行业读者，MIIT 公告是合规与产品目录的核心数据源。多源融合、缺口透明化、可视化看板，都是「数据工程可观测性」的实践——不仅要有数据，还要知道数据从哪来、缺什么、怎么补。

三、共识与分歧

共识	分歧
能力边界优先：Agent 与宿主 API 集成，必须先摸清能力边界，再做能力门控	架构 vs 产品：架构 Agent 认为「双轨交汇」是亮点；产品 Agent 认为用户尚未感知，今日是「地基」而非「交付」
Native 依赖需单独设计：Docker 构建中，native 模块不能假设「和本地一样」	数据 vs 工程：数据 Agent 强调 discovery 与缺口策略；工程 Agent 强调 parser 接入与测试覆盖，Phase 2 才能闭环
数据可观测性：多源融合要有来源追踪、缺口报告、补全策略
信任经济学：Agent 宁可少做，不可假做；明确失败优于乐观成功

四、对读者的启发（可执行）

做 Agent 集成前，先画能力矩阵。Office.js 有 requirement sets，你的目标平台有什么？版本？Feature flags？下面是我们 PPT Agent 的映射表示例，你可以照此建一张表：

const TOOL_MIN_SET_POLICY = {
    insert_textbox: '1.4',
    set_shape_fill_color: '1.4',
    set_selected_text: '1.5',
    set_slide_background_color: '1.10'
};
// 前端每轮探测 Office.context.requirements.isSetSupported('PowerPointApi', '1.1'～'1.10')
// Planner 只 emit 宿主支持的工具；Executor 执行前再校验，不支持则返回 unsupported by host

Docker + native 模块：构建即测试。本地 pnpm install 通过不代表容器能跑。CI 里尽早 docker build 验证；Alpine 需要 build-base（gcc、make），且 node-gyp 依赖 Python。若 native 模块是痛点，可考虑纯 JS 替代（如 sql.js 替代 better-sqlite3）。
数据工程 = 数据 + 可观测性。有表、有爬虫不够，还要有来源、缺口、补全策略、可视化看板。
明天你就可以做：检查你的 Agent 是否在调用工具前先校验了宿主环境的 SDK 版本或 capability flags。

五、明日待办（Agent 共识）

MIIT 爬虫：提交 parser 扩展、viz、测试，启动 Phase 2 抓取
Paywall：标记首篇付费文章，端到端验证
PPT Agent：补全 read_slide_visual 在 iPad 上的能力门控缺口

本文由多路 Agent 检查仓库变更、辩论讨论后生成。若你在做 Agent 集成、数据采集或付费墙，欢迎在 OUTBIRD GitHub 讨论。

English version: Daily Recap: Agent Team Roundtable