用 14 个 agent 顶掉 5 个招聘名额

Sortlist 的 CEO Nicolas Finet 在 2026 年 6 月初抛了一份内部手册级别的文章：他本年计划招 5 个开发者，一个没招。预算挪给了 agent 和跑它们用的 token。14 个长跑 agent，每月 API 成本约 400 美元，scrape、写作、分析、外联全包。他把搭建方法拆成 6 步，每一步都标注了"什么是好"和"哪里会坏"。

这是一个关于"如何用一套不贵、可以复用的工具链，把公司里能自动化的工作都做掉"的真实样本。

第一个反直觉：先写连接层，再写 agent

大部分人上手 Claude Code 第一时间会想"先跑一个 agent 看看"。Finet 拦住了这步：先写 wiring，因为 wiring 是保护你将来换工具不重写的关键。

写 wiring 的核心原则：skill 文件里永远不要出现 vendor 的具体名字。不能写 pipedrive_list_deals 这种 tool 名。所有 skill 只能调四个标准名：list_deals / get_deal / list_contacts / get_contact，再用一个轻量 MCP server 坐在下面，把这四个名字映射到你家实际在用的 CRM 上。

这一步交付物：两个 Python 小文件（用 FastMCP，几行 type hints），加一个 _crm-template 模板。两组 env var、起两个 server、看到自己 CRM 的真实行回来——验收通过。

陷阱：觉得"这次直接写 pipedrive_list_deals 更快"。等哪天你换 CRM，6 个 skill 全部重写。连接层是"换 vendor 改 1 个 server、动 0 行 skill"的契约。

第一个 agent：周一早报

skill 的物理形态就是一个文件夹一个 SKILL.md。agentskills.io 规范只要求 name 和 description 两个 frontmatter 字段，其他都是你写给 agent 在乱世界里如何表现的行为准则。

挑"周一早报"作为第一个 agent 是有讲究的——它第一次跑就能回本，而且失败模式是显然的：CRM timeout 它能不能诚实地写"没数据"，而不是编一段看起来合理的"本周状态"。

在同一个 Claude Code session 里用真实数据测试，把 prompt 调到不再需要人改写的程度
提交给 runtime，用 hermes cron create 用自然语言写 cadence：Every Monday at 7am, run this skill for all active units in units.yml
验收："周一 7:01，这篇 note 已经坐在频道里，比任何人到工位都早"

最大的坑是不写 failure modes。CRM 一超时 agent 就会发明一个看起来合理的"中等进展"贴进频道——人们对一个可信频道的"自信虚构"信以为真，比"频道里空着"更糟。每一次都必须明确"数据源缺失时你怎么写"。

第二个 agent：盯外界的夜班

第一个 skill 读自家系统，第二个是夜班的雷达：扫融资、扫招聘、扫竞品。形态上和 digest 完全一样，区别只在 spec 内容。

Write a skill at morning-radar/SKILL.md following the agentskills.io spec. Read
a watchlist from memory: our company and product names, our competitors, and
the buying signals that matter to us (funding, key hires, a competitor named in
public). Every morning, sweep X, LinkedIn, Reddit, Hacker News, and the open
web for the last 24 hours. De-duplicate across sources. Rank into tiers:
in-market signals first, then competitor moves, then our own mentions. Post one
digest to #radar with a one-line suggested move on each item (reply, DM,
monitor, ignore). Suppress anything already surfaced in the last 7 days unless
its engagement has tripled.

注意里面"按互动倍数"提升老内容的兜底——没这条规则，雷达会每天早上把上周那条爆款转推一次，一周之内所有人学会滑过去。一个"大家都滑过去"的频道等于没有频道。

剩下三个 event-driven 的 skill（lead 进 CRM 自动出 brief、brief 标好自动起草、稿子进 review 自动 QA pass）不是定时跑。Hermes 自己不带 webhook receiver，你要写一个一文件的 receiver——Cloudflare Worker 或 Vercel function——接 webhook 后直接 hermes chat --skill lead-enrichment-brief --query "..." 调起。不愿意托管 receiver 就把 skill 暴露成 Slack slash command，让人手动触发。

第四步：给每个 skill 一份 memory，否则它永远是个陌生人

两次 run 之间什么都不记得的 agent，每周写出来的东西都是同一套泛泛的 note，主人改两回就懒得看，频道在第 4 周自然死亡。Memory 是 demo 和"团队信任的工具"之间的那道分水岭。

Hermes 的 memory 实现是 FTS5 全文检索 + LLM 把老 run 浓缩成稳定事实，存放在 ~/.hermes（可指向外部 provider）。给每个业务单元起一个 namespace，每次 run 顶部加载。

验收曲线很直观：

第 1 周：digest 读起来像一个聪明新人的初稿
第 10 周：读起来像 owner 自己写的，因为 agent 看过了 9 轮你的编辑并把它们折进去了

同一个 store 在你用 Claude Code 调 prompt 时也是开的——你永远在runtime 看到的那份 memory之上做编辑，不存在"我改的是一份和我运行时不同的版本"。

常见死法：团队把 memory 当 nice-to-have，不带就上。然后用冷启动的第一版输出去评判 agent，判定"平庸"，第 3 周悄悄关掉——而它再过一周就会开始像你了。

第五步：内部 agent 让它自己调，客户可见的必须过一道

挣钱的 agent 不会停在原地。Finet 在 outbound 流程里接了一个 autoresearch loop（思路来自 Ole Lehmann），10 个 campaign 之后它开始自己改 copywriter 的 prompt：写一版 → 对回复打分 → 保留或回滚。你想要的正是这个——但要圈起来。

两层结构：

内部 skill（radar、retro、self-tuner）自由改自己的 prompt
客户可见 skill 只"提议"变更并等人类

提案来了之后你打开 Claude Code 看 diff、决定、agent 自己跑实验，最终决定权永远在你手里。

危险的具体形态：让一个 customer-facing 的 skill 不经审核自己改主题行——哪天它觉得"更吸引人"等于"更激进"，整张 list 已经在你看到之前被发出去了。这就是为什么要做 tier 切分。

第六步：把失败做大声

Agent 一定会坏。但真正伤人的是沉默的失败——一个抛错然后停掉的 skill，从外面看和一个"今天没东西要报"的 skill 完全一样，没人注意到它死了，直到几周后某件可见的事崩塌。

好的失败长这样：

on failure:
  - retry
  - log 到一个专门的 channel
  - 即使拼不出 digest，也要发一个 stub

"tracker is down, here is last week's."

——你宁愿读这条"上周替代品"通知，也不想读沉默一周后默认"一切正常"，然后一个月后那个出问题的 deal 在贵十倍的地方冒头。

不带 error channel、不带 stub，agent 礼貌地失败进虚空，周一这条 note 永远到不了。

起步只需要一个

你不需要 14 个来体验这个范式的复利。先做Step 2 的周一早报，看着你的周次开始变得有组织。然后做雷达。一段时间后你的 stack 开始 compound——你写的每一个 skill 都在教你下一个 skill 的形状，而连接层意味着没有任何一个会因底层工具变动而崩。

需要"从一份能跑的开始"，Finet 把 6 个 skill 加 2 个 MCP server 全部打包到一个 repo，附模板和精确的 cron 命令。原推下评论 STACK 可获取。

写到最后