melech-buy-vs-build

买还是自建

当 Agent 被要求“添加后台任务”时，它会很乐意编写一个 tasks 表、一个轮询工作进程、一个重试列和一个死信标志。它能正常工作，但它本质上就是 BullMQ、Trigger.dev、Cloud Tasks，或者已经放在 package.json 里的队列库——只是重新实现得很糟糕，而且从此就得由你负责维护。

没人会刻意做出这个决定。仓库级审查只会问 “这在我们的代码里已经存在了吗？”，而模型记忆在回答外部问题时，则会给出自信却过时、有时甚至凭空编造的包名。这个代价高昂且难以逆转的决定——自己负责实现，还是把这项能力交给第三方——不是基于证据做出的，而是默认就这样决定了。

melech-buy-vs-build 负责做出这个决定。它会向外寻找世界上已有的相关能力实现，并根据实时来源进行验证；同时先执行一次向内检查：采用还是重建，确认这项能力是否已由现有依赖或供应商提供。随后，它会给出一份候选清单和结论：采用，或继续自建。

可以把它理解为 “这件事有 AI 能做吗？”——只不过针对的是自建还是购买的决策，而且依据的是证据，而不是直觉。

---

两种意图

两种意图都会开展向外调研，为同一个自建还是购买的结论提供依据。无论触发哪种意图，都要先进行一次向内的采用还是重建检查（步骤 2）——已有的能力总是胜过另找方案或自行构建。

意图	触发条件	目标
拦截	已有代码、计划或差异，可能正在重复造轮子。	指明已（重新）构建的内容，找到现有方案，并决定采用还是继续自建。
探索	开放式问题：“X 有哪些现成方案”“X 有什么新工具”“现在大家怎么做 X”。	梳理这一领域，找出值得关注的方案和近期动态，帮助用户做出选择。

如果根据输入就能明确判断意图，不要询问适用哪种意图。有差异或提案时，使用拦截；只有关于某项能力的问题时，使用探索。

---

决定一切的唯一规则

搜索能力，而不是名词。

这类调研失败的唯一原因，就是搜索用户自己的用词。如果 Agent 在网上搜索 "postgres polling table worker"，找到的会是博客文章；如果 Agent 识别出这项能力是持久化后台任务执行，找到的就会是整个相关领域。

因此，在进行任何搜索之前，先把实现方式转换成行业使用的规范术语。

Agent 构建的内容	实际应搜索的内容
表中的行 + 轮询工作进程 + 重试次数	作业队列、后台任务、持久化任务执行
自定义事件总线和处理程序注册表	发布/订阅、消息代理、事件总线
手写的带抖动重试封装	重试库、弹性/退避库
专门编写的角色/权限匹配器	授权/策略引擎、RBAC / ReBAC
类似 Cron 的 setInterval + 锁文件	作业调度器、分布式 Cron、工作流编排
为向导实现的差异对比并应用的状态机	状态机库、工作流引擎
自定义 CSV/Excel 导出器	电子表格/序列化库

如果不确定规范术语，首先搜索该术语本身： “……叫什么？”。先确认正确用词，再展开搜索。

---

工作流

1. Name the capability  ─►  2. Read the ground truth  ─►  3. Fan out lanes  ─────────►  4. Reduce  ─►  5. Shortlist + verdict  ─►  6. Hand off
   (canonical vocabulary)     (stack, constraints)          adopt-vs-rebuild (inward) ┐   (dedupe, kill dead)   (ask_question)
                                                            outward lanes (web)       ┴─ same concurrent batch;
                                                                                          inward hit short-circuits

1. 明确能力

用一行话说明这项功能做什么，不提本地实现方式。列出 2–5 个规范搜索词和任何明显的同义词。在展开搜索之前先展示给用户——能力名称弄错会浪费整个流程。

2. 阅读实际情况（内联，必须首先进行）

这项快速检查留在主线程中，因为没有它就无法向外部调研通道交代情况。收集决定适配度的约束：

• 语言和运行时，以及清单文件中已有的内容 （package.json、requirements.txt/pyproject.toml、go.mod、Cargo.toml、 Gemfile、pom.xml）
• 已付费的基础设施：云服务提供商、Postgres/Redis/Kafka、 已列入账单的供应商
• 硬性约束：仅限自托管、数据驻留、许可政策、 隔离网络、不得引入新供应商、预算
• 实际规模：每天 100 个任务和每秒 100k 个任务对应的候选工具名单并不相同

如果这项低成本检查已发现明显符合的选项——所需能力就是某个直接依赖，或显然已启用的供应商功能——就到此为止并报告。不要再去购买已经拥有的东西。否则，将这些约束带入第 3 步，并让深入的采用还是自建检查并发进行。

3. 并行展开各调研通道

并发派发相互独立的调研通道——每条通道由一个子代理负责，各自沿着自己的路径运行多次网络搜索（采用还是自建通道除外，该通道主要进行本地检查）。各通道搜寻不同类型的答案，而非不同关键词。内部通道与外部通道在同一并发批次中启动，因此内部检查不会产生串行延迟。

通道	搜寻目标
采用还是自建 (内部，拥有特权)	深入进行第 2 步检查：传递依赖、框架/标准库内置功能、现有供应商方案已涵盖的功能、内部单体仓库库。主要是本地工作，加上有针对性的文档查询。短路权限——见下文。
主流选项	该类别的标准名称，以及每份对比都会列出的 3–8 个选项。Awesome 列表、类别页面、“X vs Y”对比文章。
生态系统	本项目所用语言的库和开源软件。软件包注册表、GitHub、框架原生方案。
商业方案	托管服务、开发工具、SaaS、云基础服务。包括那个没人提及的普通云方案。
实践评价	从业者的真实看法：HN/Reddit 讨论、“我们已从 X 迁移”的文章、事后分析，以及人们后悔选择各个方案的原因。
反方论据	为什么在此情境下自行开发有时是正确选择，以及现有方案的已知故障模式。确保候选名单经得起检验。

对于 explore 意图，添加一条 前沿动态通道，搜寻过去 6–12 个月发布的内容，因为这正是模型记忆容易过时的领域。

**短路规则：**如果采用还是自建通道确认发现了一个已拥有且能满足需求的真实有效能力，整个流程就此结束。外部通道的结果将被丢弃（这是并行运行内部和外部检查而非设置门槛所付出的计算成本）。报告已拥有的选项并停止；不要为已经付费的东西寻找替代品。

根据事项的重要程度调整通道数量：询问“有没有重试库”时用 3 条通道，询问“我们应该自建编排器吗”时用全部 6 条通道。不要按网站数量创建通道——来源是通道查找信息的地方，而不是工作单位。

如果用户提供了种子名称、来源或“也检查一下 X”，就将它们交给专门的通道，而不要稀释其他通道的工作。

通道简报、查询模式、搜索范围和候选项行结构定义见 references/lanes.md。向每条通道提供能力说明、第 2 步的约束、一个问题、来源上限和证据要求。

4. 筛选整理

合并所有通道的结果，然后依次执行：核实或剔除 → 淘汰失效项 → 去重实体 → 按方案类型（而非名称）归类 → 根据第 2 步的约束对适配度排序（受欢迎程度仅作为平局时的参考，绝不是评判标准）。完整的合并规则——失效判定阈值、实体与来源归并、硬性约束淘汰——见 references/lanes.md。

5. 交付候选清单并给出结论

最多列出 3–6 个候选项。列出二十个选项属于研究资料堆砌，不是推荐。

### ⚖️ Buy vs Build: durable background jobs (Node/TypeScript, Postgres, no new vendors)

| Option | Kind | Why it fits | Cost | What you give up | Adoption effort |
|---|---|---|---|---|---|
| `pg-boss` | OSS lib | Runs on the Postgres you already have; no new infra. | Free | Throughput ceiling vs. Redis-backed. | ~half a day |
| BullMQ | OSS lib | Mature, huge ecosystem, good observability. | Free + Redis | Requires Redis you don't run today. | ~2 days incl. infra |
| Trigger.dev | SaaS/OSS | Durable workflows + retries + UI out of the box. | Paid tier / self-host | New vendor; violates the stated constraint. | ~1 day hosted |

**Already in your stack**: none — `bull` is not installed; Redis is not provisioned.

**What no option gives you**: the per-tenant fairness rule in `worker.ts:88`.
Any adoption keeps that logic as your own scheduling layer.

**When rolling your own still wins here**: fewer than ~1k jobs/day, no fan-out,
no cross-process coordination — then your table plus a cron is genuinely less
total complexity than a queue runtime.

然后使用 ask_question 让用户作出决定：

1. 采用 <推荐选项> 并移除手写实现
2. 采用，但针对 <没有任何选项覆盖的部分> 保留自定义层
3. 保留自定义实现（记录原因）
4. 继续研究——约束条件不同或需要更多选项

绝不要擅自移除正常运行的代码。 此技能负责汇报并推荐买还是自建，由用户决定。

6. 移交

• 采用 → 通过最精简的路径集成；如果替换会重塑设计，则重新调整设计。
• 继续自建 → 继续推进，并留下一条说明原因的 WHY 注释，记录评估过哪些选项以及为何拒绝，这样下一个 Agent 就不会重新争论一遍。
• 需求本身看起来已站不住脚 → 重新审视需求是否真实存在。
• 入围选项需要经过压力测试才能决定 → 先验证选项，再编写代码。

---

证据约定

模型会一本正经地编造看似可信、实际不存在的包。如果凭空捏造出 @vercel/queue-kit，此技能就毫无价值。

务必进行网络搜索。记忆只能提出假设；只有搜索才能找到候选项。

• 每个候选项都必须附带一个本次实时搜索结果中出现的 URL。
• 每个候选项都必须提供活跃度信号：最近一次发布、最近一次提交，或当前的定价／文档页面。
• 回忆出来但未经核实的名称必须标注为未经核实，并在进入候选清单前确认。
• 版本号、定价、限制和许可条款必须引用来源，否则省略。切勿估算。
• 如实说明没有结果的领域。“在这个生态中没有找到可信选项”也是有价值的发现。

---

应做与不应做

应做：“这是一个作业队列。规范术语：后台作业、持久化任务执行、工作队列。先用这些术语搜索。”

**不应做：**搜索用户的说法（"tasks table with status column"），然后断定没有现成方案。

**应做：**先检查清单——“p-retry 已经是传递依赖；你自定义的退避封装只是用它写了 40 行代码。”

**不应做：**在所需能力已经安装或已经付费的情况下推荐新供应商。

应做：“其中有三个已经停更：上次发布于 2021 年、仓库已归档、公司被收购后产品已停止维护。将它们剔除。”

**不应做：**为了显得全面而把废弃项目塞进候选清单。

应做：“这些选项都无法处理你的租户公平性规则。无论如何，这部分都得由你自己实现。”

**不应做：**暗示某个库可以直接替换，而不说明它缺少什么。

应做：“以你的使用量来看，手写实现确实更简单。保留它。”

**不应做：**每次都得出“使用库”的结论。总是建议采用现成方案的技能不是研究，而是条件反射。

**应做：**列出候选项，让用户选择。

**不应做：**仅仅因为有更热门的选项，就开始替换正常运行的代码。