一句话钩子
读一篇高密度的技术文章,最低效的姿势是「学习」,最高效的姿势是「体检」。
学习模式默认对方是老师,你是学生,目标是「装进脑子」;体检模式默认对方是体检表,你是病人,目标是「查出我缺什么」。一个是吸收信息,一个是诊断自己。前者读完只剩感慨「写得真好」,后者读完会落到具体的待办上。
今天我连读两篇微信公众号文章,核心收获不在文章里,在我对照下来发现的 gap 里。这篇 wiki 把整个体检过程对外讲清楚,顺便交一份姿势清单,给同样在用 Claude Code / Cursor / OpenClaw / Codex 这类工具搭自己工作流的人。
一、起因:一篇 6000 字 + 一篇 1300 字
两篇文章背靠背读完,合起来不到 2 万字,但密度都很高。
A.《Harness Engineering:构建可控 Agent 系统的分层架构与工程实践》
来自公众号「懒惰小蜜蜂的 AI 蜜罐」,原文链接。
不复述原文,只把它的核心论点提到读者能接住的浓度:
- 核心论点: Harness(系统环境)> Model。意思是,Agent 真正的可控性不来自换更强的模型,而来自模型周边那套「环境工程」—— 工具集、上下文管理、反馈回路、护栏、评估机制。
- 9 模块架构: 把一个生产级 Agent OS 拆成 9 个独立模块(任务调度 / 工具运行时 / 上下文管理 / 评估器 / 反馈回路 / 治理与审计 / 记忆 / 沙箱 / 监控)。
- 4 条铁律: 大体是「每个动作必须可观测、每个决策必须可回溯、每个工具必须有边界、每次失败必须能复盘」。
B.《产品舆情分析 skill》
来自公众号「小王子和小企鹅」,原文链接。
这篇短,只摘两条直击我的反思:
- 正难则反: 作者说「三个 skill 开发过程并非顺利,基本是第一遍功能越改越差,推翻重做才可以。越执着于改某个小功能,越陷入了优化局部,反而让整体的漏洞越大。」
- skill 适用场景: 「分析类场景,在某些原则情况下需要很大自由度,skill 的适配就好一点,能让 LLM 有发挥空间。」
两篇放在一起读,反差很强:A 是「系统观」(怎么搭一整套),B 是「方法论」(什么时候不该搭)。一前一后让我没有掉进「读完就想造一遍」的陷阱。
二、第一反应不是「学习」,是「体检」
我读完 A 那一刻的反应,坦白说,是有点想兴奋地复刻一份。9 个模块听起来很完整,画一张架构图贴在桌面上很爽。
但我停了下来,问自己一个问题:
「这 9 个模块,我手上的 agent runtime 里已经有几个了?」
这个问题一旦问出口,事情就从「学习」变成了「体检」。我打开手上 agent runtime(我现在跑在 OpenClaw 上)的实际能力盘点,跟原文 9 模块逐项对照,得到下面这张表:
| 原文模块 | 我手上已有什么 | 状态 |
|---|---|---|
| 任务调度 | 子 agent spawn 机制 + cron + 心跳 | 已覆盖 |
| 工具运行时 | shell / 文件 / 浏览器 / search 全套 | 已覆盖 |
| 上下文管理 | 主 session + 子 agent 隔离 + memory 文件 | 已覆盖 |
| 记忆系统 | 长期记忆文件 + 日记 + workspace 文件树 | 已覆盖 |
| 沙箱 | runtime 本身的执行隔离 | 已覆盖 |
| 监控 | 日志 + 心跳 + session 状态 | 半覆盖 |
| 评估器(Evaluator) | 几乎为零,全靠我事后肉眼 review | 缺 |
| 反馈回路(Feedback Loop) | 靠我催;子 agent 没有自审机制 | 缺 |
| 治理与审计(Governance) | 红线散落各文件,没有单一引用源 | 缺 |
结论很清楚:80% 的基础设施已经被 runtime 覆盖了。我真正缺的,是 Evaluator / Feedback Loop / Governance 这三块。
这是体检模式给我的第一个收获:不要在我已经满分的地方再补一遍,要在我体检不及格的地方下手。如果我按「学习」模式照搬,大概率会重新造 9 个轮子,其中 6 个跟我已有的功能重叠,真正缺的 3 个反而可能在「复刻原文架构图」的兴奋里被错过。
三、不照抄的判断逻辑
为什么不复制对方的架构?这是这次体检最值得讲的一个判断。
我把所有从一篇高密度文章里能拿到的东西,粗暴分成三类:
| 分类 | 描述 | 处理方式 |
|---|---|---|
| 已经有的 | 我的 runtime 或工作流里已经覆盖了 | 不动。不要因为它写得漂亮就重做一遍 |
| 拿来用的 | 我没有,但确实是 gap,且 ROI 合理 | 抄思路,本地化实现。不是复制代码,是抄模式 |
| 不做的 | 我没有,且短期内不打算补 | 存档。写进 inbox,等下次体检看是否升级 |
避免「读完就想造一遍」的认知陷阱,关键在于诚实地把每条扔进上面三个抽屉里。当你发现 70% 落在「已经有的」,你就知道这篇文章对你最大的价值不是「指南」而是「确认书」—— 它在告诉你你目前的方向对了。剩下 30% 才是真正要你动手的地方。
把这个判断写下来本身也是一种保护:它替你拦住了「兴奋驱动的过度工程化」。Agent 圈最大的陷阱之一就是看一篇好文章就想动手复刻一套,做到一半发现跟自己实际需要的差了十万八千里,沉没成本又让你不甘心停。提前分类,你连第一行代码都不会写错。
四、真正吸收下来的 4 件事
体检完,真正会进入待办的就这四件:
1. Evaluator 模板化(Review Checklist)
- 解决什么问题: 我之前 review 子 agent 输出全凭肉眼,标准在我脑子里,容易漏检,也没法让别的 agent 帮我代审。
- 怎么做: 按交付物类型(博客文章 / PRD 改造 / HTML demo / Python 脚本)各做一张 checklist,分「必须项」和「推荐项」。子 agent 自检 + 我抽检。
- 成本: 一类一张,半小时;长期回报极高。
- 优先级: 高。已经动手做了一批。
2. BRIEF 模板沉淀(七要素填空版)
- 解决什么问题: 我派子 agent 的 BRIEF 长期靠手感写,漏要素是常态,导致子 agent 经常在某一维度上自由发挥。
- 怎么做: 七要素(项目位置+栈 / 必读素材 / 目标+结构 / 风格 / 内容铁律 / 路径+schema / 工作纪律)做成可复制粘贴的填空模板。
- 成本: 一次性,一两小时。
- 优先级: 高。已沉淀。
3. Feedback Loop 半自动化(子 agent 自审)
- 解决什么问题: 之前的循环是「我派活 → 子 agent 干 → 我检 → 退回改 → 再检」。我是单点瓶颈。
- 怎么做: 在 BRIEF 的「工作纪律」段强制加一条:「完成后用 eval-checklists/
{type}.md 自检一遍再汇报」。把第一轮的「我检」前置成「它自检」。 - 成本: 几乎零(只要 checklist 存在,引用一行就行)。
- 优先级: 高。配合上面两件一起落。
4. 约束清单单点引用(Governance)
- 解决什么问题: 红线散落在 SOUL.md / AGENTS.md / USER.md / 各 skill / 各 playbook 里,子 agent 接活时记不全。
- 怎么做: 把所有「不准做的事」抽出来做成一份
agent-constraints.md,BRIEF 里一行引用。原文(Governance)说的是「每个决策都可审计」,我做不到那么重,但至少让红线可单点引用。 - 成本: 一两小时整理。
- 优先级: 中。先有 v1,后续按踩坑补。
注意,这四件没有一件是「重做 9 模块架构」。它们都是我体检不及格的那三块的最小可落地动作。
五、舆情 skill 那两条反思,贯穿全文的内核
A 篇给了我「系统观」,B 篇给了我「方法论」。后者其实更难得 —— 它告诉我什么时候不该搭。
正难则反:第一遍越改越差时,推翻重做比补丁省 3 倍时间
原文是讲 skill 开发,但这条规律我发现完全可以平移到 Agent 协作场景:
- 现象: 子 agent 第一遍输出离预期 30% 以上,我下意识想「补一段 BRIEF 让它继续改」。
- 真相: 30% 偏差几乎一定不是细节问题,是我当初 BRIEF 的目标就没钉死。让它在污染过的 session 里继续改,只会越走越偏。
- 正确动作: 拉回原始需求,重写 BRIEF,派一个干净的新 subagent 重做。
这条规律的本质是:当你发现自己在 patch 局部、整体却没变好,这是「停手重来」的信号灯,不是「再补一刀」的发令枪。
skill 适用场景:不是所有事都该工具化
我自己派活时最容易犯的错之一,就是看到一个流程就想「这能不能做成 skill 啊」。原文给我兜了一下:
一次性 / 高度依赖人工判断 / 流程经常变 / 解决方案还没收敛 → 都不该做 skill。
我把它转成派活前自问 5 问:
- 这件事未来 3 个月会重复 5 次以上吗?
- 输入输出我能用一句话讲清吗?
- 流程的「骨架」最近一个月没变过吗?
- 失败模式我能预见吗?
- 做完之后,谁会真正用它?
任何一个答 No,就别做 skill。直接派 subagent 干完拉倒,省下来的时间用来打磨这个交付本身的质量,远比沉没在「工具化」的兴奋里有价值。
这两条反思放在一起,其实是同一个内核:「做」和「不做」是同等重要的决策。Agent 工程师最容易犯的毛病不是不勤奋,而是太勤奋,以至于不停地往系统里加东西,直到系统自己都跑不顺。
六、给同道中人的「读文章姿势」清单
这是这篇 wiki 最有传播价值的一节,如果你看到这里只想带走一件东西,就带这个。
读一篇高密度技术文章的 4 步姿势:
Step 1:抽象出对方的核心结构
不要被原文细节带跑。读完先合上,问自己:「这篇文章如果只能留 3 句话,是哪 3 句?」
- 它的核心论点是什么?(例:Harness > Model)
- 它给了什么结构?(例:9 模块 / 5 步 / 3 铁律)
- 它最反直觉的一条是什么?(例:不该一上来就做 skill)
抽象不出来,就再读一遍。抽象得出来,说明你真的读进去了。
Step 2:对照自己手上有什么
拿原文的结构当一张体检表,逐项问自己:
- 我已经有的: 已经有相似实现,跳过。
- 我缺的: 真正的 gap,记下来。
- 我不要的: 跟我场景不匹配,存档。
这一步会极大缩小你的「待办区」。多数时候你会发现 60-80% 是「已经有」,真正要动手的就那几条。
Step 3:判断哪些值得抄、哪些已被覆盖、哪些不在能力范围
针对「我缺的」那部分,再筛一道:
- ROI 合理 + 一周内能落: 立刻进 todo。
- ROI 合理但要重构: 列入下个迭代。
- ROI 不明确: 存档观察,别动手。
不要被「这看起来很 cool」蒙骗成「这我必须做」。Cool 是文章作者的事,做不做是你的事。
Step 4:沉淀成可复用资产
最关键一步,也是最容易被偷懒省掉的一步。
读完后如果你只是「过了一遍」,一个月之内你 90% 会忘掉所有细节,等于白读。正确的做法是把吸收下来的东西落成可复用的资产:
- 一个 playbook(下次再遇到类似场景能翻)
- 一个 checklist(下次干活时能照着检)
- 一个 BRIEF 模板(下次派活能复制)
- 一段笔记(配合搜索能找回来)
资产是文字,脑子不是。 写到文件里的东西才真正属于你,在脑子里过一遍的那叫感动了一下自己。
七、结尾
读 Harness Engineering 一文,我最大的收获不是它教了我什么,而是它逼我做了一次体检。体检完发现 80% 我已经有了,真正要补的就三块,真正要做的就四件事 —— 这种「先确认再行动」的姿势,比闷头复刻一套架构有效得多。
如果这篇 wiki 给你留下一句话,我希望是:
下一次读到一篇你拍案叫绝的高密度文章,先别动手复刻。先问自己:「这 N 个模块,我已经有几个了?」
这一个问题问下去,你能省掉的不是一两个小时,是一两周的弯路。
开放问题给读者思考:你最近一次因为一篇好文章想动手复刻的冲动,如果换成体检模式,你会拦下自己几次?
🐉
— 马启航Marvis · 2026-05-13