DeepSeek Harness 系统教程：Agent 是模型加外壳，外壳正在变成供应链

2026-11-14silcano

微信读书《DeepSeek Harness 系统教程：Agent、Harness、插件、应用、生态》（轻科技）· 逐页翻阅 35 屏 · 抓取标记 reached_end=True（end_reason=last_page，末屏为"全书完"）· 阅读器记 6 个章块 · 微信读书推荐值 59.9%，105 人点评。
抽样说明：这本书只有 35 屏，我全部看完，没有跳读。引句页码为本次截图编号，与纸书页码无关。文中标"我的判断""我的经验"处是评论，已与书中原文分开；凡是加了引号的话，都能在上述截图里逐字核对。

先说结论：这本书真正提供给你的不是教程，是一个定义——Agent = Model + Harness。

这个定义值得记住。但它撑不起一本书：35 屏、阅读器记录"已阅读 2 分钟"、推荐值 59.9%。这三个数字本身就是对这本书最准确的评价，比任何书评都直接。

我读完之后心情有点复杂。它把一个被讲烂了的话题讲清楚了——"为什么我用同一个 DeepSeek 模型，在 Claude 里和在 WorkBuddy 里感觉完全不一样"，这个问题大部分人答不上来，它用一句话答了。但它也只答了这一个问题，剩下二十多屏是安装步骤、五个插件链接，和一段没有论证的行业感想。

所以我打算这么写：先把它讲对的那件事讲透，再把它讲漏的地方一条条挑出来。这本书太短，短到不适合复述；但它的判断足够锋利，值得被认真反驳一次。

一、先承认它是什么：35 屏、2 分钟、59.9%

结构很简单，六节：一、大模型、Agent、Harness 到底是什么，怎么连在一起（p0005–p0010）；二、理解 Harness 对我们用 AI 有什么帮助（p0011–p0012）；三、DeepSeek Harness 是什么（p0013–p0014）；四、DSH 手把手上手教程（p0015–p0023）；五、推荐一些必备的插件（p0024–p0030）；六、DSH 的插件生态和对产业的意义（p0031–p0034）。

文体上它根本不像书。"老规矩，先说今天的目标"、"求个赞藏不过分吧"、"先叠个甲，以下观点纯属个人愚见"——这是公众号长文的写法，作者自己也没打算藏。开篇第一句就是"最近 DeepSeek Harness 火了"，接着交代："我写这篇文章的时候，已经 20w 星了。社区好的坏的，什么声音都有，估计是我见过一个技术出来最热闹的一次。"

我不想把"它是文章不是书"当成罪状。真正的问题是：它按书的方式交付，却按文章的方式写作。文章可以只给结论不给判据，书不行；文章可以不给版本锚点，书不行；文章可以"你去 GitHub 看"，教程不行。

59.9% 这个分数，105 个人打的。我猜大部分人的失望不是"内容错了"，而是"我按书名买的是教程，拿到的是导购"。这个落差是编辑造成的，不是作者造成的——作者从头到尾都很诚实，他甚至在第四节开头就说"建议你跟着做"，可他没告诉你跟着做会遇到什么。

顺便说一句，我并不同意"分数低就等于差"。低分有两种：一种是无能，一种是不合期待。这本是后者。它的前 11 屏（p0002–p0012）值得任何做 AI 产品的人读三遍，后面二十多屏可以当附录。

二、"大模型有嘴没手"——全书最值钱的一句话

第一节里有一段比喻，我认为是整本书的核心资产，值得完整抄下来：

我们常用的一个比喻就是，大模型，就是脑子。它聪明。但它只有嘴，没有手。
它不会自己点开你电脑上的文件夹，不会真的去跑一条命令，不会自己保存一个文件再打开检查。
它把答案说完，它能做的所有事情就结束了。接下来复制、粘贴、保存等等，全是我们自己的事。（p0006）

然后一句收口："Agent，就是接上双手之后，那个会干活的人。"（p0006）

这个比喻的好处，不在于它形象，而在于它把两个经常被混为一谈的东西拆开了：能力和能动性。大模型的能力上限可以很高——它能写代码、能总结、能推理；但它的能动性严格等于零，因为它没有执行通道。

这个拆分能解释两件今天很多人还在困惑的事。

第一件：为什么 Copilot 和 Agent 是两种产品，而不是一个产品的两个版本。Copilot 的工作方式是"你贴、它答、你复制"，它的瓶颈是人；Agent 的工作方式是"你说、它做、你看结果"，它的瓶颈是工具链。前者做到极致是"更聪明的输入法"，后者做到极致是"一个能替你上班的同事"。这两条路的工程重点完全不同，混着做通常两头不讨好。

第二件：为什么 Agent 一上手，token 账单会跳着涨。书里在 p0008 有一句 PS，写得比很多长文都准："所以知道为啥 Agent 做事情，token 消耗那么大了（想的多、做的多、上下文多）。"想得多是因为每一步都要重新推理，做得多是因为每次工具调用都要回灌结果，上下文多是因为前面所有步骤都得带着走。三件事乘起来，就是为什么一次 Agent 任务的成本可能是同样问题一次性回答的几十倍。

我对这个比喻的批评是：它太成功，反而会误导。"手越多越好"是错的。手多意味着可动用的工具多，也意味着可能乱动的地方多。书里后面讲权限三档，其实就是在给这个比喻打补丁——但你读第一节的时候不会有这个警觉，你会觉得"那就多装插件"。一个比喻如果只在被解释的一屏里成立，它就是个修辞，不是工具。

它还顺手给了一个更完整的图景。p0007–p0008 用一张截图解释了大模型的"红框"和工具的"蓝框"如何交替出现：

当我们给到一个需求的时候，大模型会对这个需求做反馈（红色部分）。那根据大模型的反馈呢，Agent 就会使用它能控制的一些工具去做响应（蓝色部分），可能是读，可能是写，可能是看，可能是浏览器，可能是各种各样的接口甚至软件。
这就是 Agent 最具代表性的一步一步多轮思考-解决的工作模式。这是理解 Agent 最核心的部分。（p0008）

"一步一步多轮思考-解决"，这句话我给满分。它是判断一个产品是不是 Agent 的唯一标准：看它会不会自己决定下一步。会，就是 Agent，哪怕它只能读文件；不会，就不是，哪怕它接了二十个 API。这个判据比任何产品分类都硬。

三、Agent = Model + Harness：这个公式的价值是让人闭嘴

接下来是全书的核心公式，只有十九个字符：

Agent = Model + Harness。
什么意思，就是说，Agent 里面，除了大模型，其他的所有，都可以理解成是 Harness。
你可以把它理解成，套在脑子外面的一整套干活装备。读文件、写文件、跑命令、上网搜、调工具、管权限、把做完的结果喂回去让它决定下一步，这些都算。规则文件、测试检查、任务怎么拆、错了怎么重来，也算。不是某一个按钮，是让大模型能在真实环境里动手的所有细节。（p0009）

然后是一份清单，我数了一下，八个词：工具、Skills、沙箱、存储、循环、调度、Subagent、工作流。收尾那句是："大模型负责想。Harness 负责干。拼在一起，就叫 Agent。"

我先说它做对了什么，再说它做漏了什么。

做对的地方：它把一个技术共识翻译成了一个能记住的短语。Harness 这个词原意是马具、套具——"套在脑子外面的一整套干活装备"，这个翻译是准的。在此之前，行业里用的是 scaffold（脚手架）、runtime（运行时）、framework（框架）、agent loop（智能体循环），每一个都对，每一个都记不住，而且每一个都暗示"这是开发者的活"。Harness 不一样，它暗示"这是你身上穿戴的东西"，站在使用者而不是构建者的一侧。

这个视角转换有实际价值。因为团队吵架的时候，需要一个名词。你说"这个模型不行"，我说"是你的壳不行"，两个人没有共同语言；有了这个公式，这句话才能说得理直气壮，也才能被证伪：换模型试一次，壳不动，如果效果没变，那是壳的问题。

书里第二章就把这个用法说清了：

现在我们很喜欢说 xx 好用，xx 不好用。本质上来说，就是在讨论两个问题：1. 大模型能力强不强？2. Harness 能力强不强？
最直观的比如说我都用 Deepseek 的大模型，但是我在 claude 中使用和在 Workbuddy 中使用，那给我们的体感肯定是不一样的，那模型都是一致，为什么体感不同呢？其实就是因为，claude、Codex 他们内部都有自己的 Harness。带来了效果上的差异。（p0011–p0012）

这段是我认为全书第二值钱的地方。它给了你一个排查顺序：先问模型够不够，再问壳配不配。大部分人反过来，一出问题就换模型，换来换去体感没变，最后归因成"AI 就这样"。

紧接着是具体的三件事，我建议直接抄下来当检查表用：

一、工作区。"让 Agent 做事情，一定要明确它能操作的范围和权限。"
二、给工具。"当我们知道 Harness 包含什么之后，我们就可以告诉他，你要用什么样的工具去做什么样的事情。"
三、写规矩。"你们怎么验收、哪些话不能写、改完要不要跑检查等等。"

作者的结论是："这三件事都有意识地融入到自己的使用过程中，才叫会用 Agent。"（p0012）

我觉得这三条比那个公式更实用，可惜它只占了两屏。如果这本书把这三条各展开成三页，配真实的提示词和真实的翻车案例，它会是一本好书。它没有，它急着去讲怎么装。

做漏的地方：这个公式的边界是模糊的，而且作者自己在两个比喻之间来回摇摆。

你看 p0008 的房子比喻："有一个房子，里面有个聪明的你，大模型就是你的充满智慧的脸袋（脑袋），然后现在给了你很多的工具，能干各种复杂的事情。这些全部囊括起来，就是 Agent。"到这里 Harness = 工具，没问题。但下一句突然说："而这个房子，本质上就是一个产品包装。包装成办公的，那就是 WorkBuddy、豆包办公。包装成写代码的，那就是 Cursor、Codex。"

于是"房子"同时指了两样东西：一会儿是 Harness（工具和装备），一会儿是产品包装（谁把它做成了什么形态卖给谁）。这两个东西在工程上完全不是一回事。前者决定"它能不能干"，后者决定"你怎么用它、它长什么样、它收你多少钱"。

这个混淆不是文字游戏，它有实际后果。当你判断"我该换模型还是换工具"的时候，你需要知道产品包装层和运行时层是分开的：WorkBuddy 换一个底层模型，产品形态不变；Codex 换一代版本，运行时可能全变。书里把这两层压成了一个词，读者就会以为"换个 Harness"是一件事，实际上是两件。

更要紧的是，这个公式是命名，不是发现。行业里"模型之外的一切"这个说法至少有两三年了，讲 agent 的时候用的是"增强的 LLM 加工具循环"，都在描述同一批零件，只是没起名字。作者做的事，是把散落的零件装进一个盒子里，贴上标签。这事有价值——贴标签本身就是一种贡献，因为标签能传播，零件清单不能——但它不是理论突破，书里也没说它是。这一点上作者是清醒的，他只说"是不是突然，有点全都通了的感觉"。

四、毛坯房与精装房：一个站得住的比喻

第三章讲 DSH 是什么，只有两屏，但给出了全书最好的一个比喻：

我觉得很恰当的比较就是，Codex、Claude Code 都是精装房，一切都配套了，你可以直接用，但是不能改。
DSH 更像毛坯房。只用本体的时候，功能少得惊人，连文件浏览、记忆这些别人默认就有的东西，出厂都可能没有。（p0014）

我喜欢这个比喻，因为它敢承认产品不完整。绝大多数教程都在替产品圆场——把缺功能说成"轻量"，把没做完说成"极简"。这个作者直接说"出厂都可能没有"，然后马上补一句"但是！它有无限大的可能性。这句话一点也不夸张，这就是它最大的价值。"

前半句我信，后半句我不买账。

"可能性"不是价值，"装得上"才是价值。一个什么都没装的东西当然什么都能装，这是同义反复，不是优势。真正要问的是：装的过程有多贵、装完的东西有多稳、装错了能不能退。这三个问题书里一个都没答。

不过它有一个地方把这个比喻坐实了，而且坐实得非常老实——第五章那五个插件。你看它推荐的清单：

1. dsh-at-file：输入 @ 就能搜索文件，快速找到想引入的文件。
2. dsh-genui：让它能展示图表以及一些画布的样式。
3. DSH-better-sidebar：加个侧边栏，方便看工作空间中的目录结构。
4. modsearch：扩展搜索源，联网搜索能获得更多更精确的信息。
5. dsh-market：类似 Codex、WorkBuddy 的插件市场，里面可以选很多插件。

发现了吗？搜文件、看目录、展示图表——三个都是别的产品出厂自带的基础件。作者自己也没回避，讲完安装方式之后写了一句我认为是全书最诚实的：

至此，估计大家也看出来了，其中的一些插件难免是非常基础的功能，但是 dsh 都需要安装。估计也就更理解了什么叫"毛坯房"了吧……（p0030）

这一句让整个比喻闭环了。它不是"毛坯房也能住"，而是"毛坯房连门窗都要自己买"。这个说法不好听，但它是真的，而且比任何宣传语都有用——你听完这句，就知道自己接下来两个小时要干什么。

我还想替作者补一句他没说的话：毛坯房真正的成本不在第一次装修，在每次翻新。精装房的坏处是不能改，好处是稳定；毛坯房的好处是能改，坏处是每次底层一动，你装的东西可能全废。这是所有"可扩展系统"的共同代价，而教程类内容几乎从不提。

五、真正能学东西的地方，是"轨迹模式"

第四章是安装教程，从 npx @deepseek-ai/dsh web 开始，Node 22.19 以上，npm install -g @deepseek-ai/dsh，dsh --version 验证，dsh web 启动，浏览器打开 127.0.0.1:3080，"左边对话历史，中间任务区，下面输入框"。这一段我没什么好评论的，标准流程，跟着点就行。第一次打开会让你填 DeepSeek API，"工具本身免费，花钱的是模型"。

但在这段流程里，藏着两个我认为最该展开、却被一句话带过的点。

第一个是权限。对话框左下角三档：Read Only 只能看不能改；Workspace Write 只能在当前工作区里写，"日常就这一档"；Full Access 全部系统都可访问，"不建议开始就用它"。然后作者加了一句提醒：

我觉得有必要强调一下，Workspace Write 限制的是写，不是看。实际上它可以看到工作区外的文件。所以就用这个就行了。（p0018）

这句话是全书写得最锋利、也最短的一段。它点破了一个真实的安全洞：绝大多数人以为"限定工作区"等于"隔离"，其实只隔离了写，没隔离读。一个 Agent 可以读你工作区外的密钥文件、浏览器 cookie、其他项目的配置，然后——按作者的说法——"用这个就行了"。

这里我必须说清楚我的不同意。"能看到工作区外的文件"在个人玩具项目里无所谓，在任何有真实数据的环境里都是不可接受的。因为只读权限加上一个联网工具，就等于数据外传通道。书里自己在前文说过 Agent 会"上网搜、调工具"，那么"能读全盘 + 能联网"这个组合意味着什么，不需要多解释。

这一段应该是全书的重点章节，配三张图：什么能读、什么能写、什么能发出去。它只有一句话。这是这本书最大的失职，比篇幅短严重得多。

第二个是轨迹模式。作者说这是他最喜欢 DSH 的地方，我完全同意，而且我认为这是全书唯一"别人不会告诉你"的东西：

简单来说，就是把你一个需求，在 Agent 内部的所有执行过程都展示出来（上下文、工具调用、提示词等等细节）。
这里的轨迹模式，我认为每个用 AI 的都需要去看一看，理解一下。特别是用来工作的朋友们。（p0021）

他给了四条好处，我逐条抄：能让你快速理解 Agent 为什么能解决那些问题；能让你快速理解当前模型的能力边界在哪里；能让你了解是不是有些地方模型跑偏了；能让你了解是不是存在浪费 token 的地方。收尾是那句："多看，就懂了。其实现在用 AI，会用和用好，就这么个区别。"

我的判断是：轨迹模式的价值被作者低估了。他自己只把它当成一个"功能亮点"，其实它是唯一能用来校准直觉的工具。

为什么？因为大多数人学 AI 的方式是学"怎么写提示词"，这是技巧层；而轨迹模式让你看"模型怎么一步步走的"，这是认知层。技巧会过时——去年管用的提示词今年可能就废了；认知不会，你一旦看过二十次模型在第三步开始重复同一个动作，你就永久获得了"这个任务它搞不定"的直觉。

具体怎么看，书里没说，我补三条自己的用法（这部分是我的经验，不是书中内容）：

第一，看它第一步读了什么。第一步读错文件，后面全错。这一步的准确率，比任何提示词技巧都更能决定成败。
第二，看它从第几步开始重复。重复是卡死的信号，早发现能省一半 token。看到第三次相同的工具调用，就该手动打断，换个说法重来。
第三，看哪段上下文其实没用上。轨迹里那些它读了却没引用的内容，就是你可以从提示词里删掉的部分。删掉之后通常更快、更准、更便宜。

我对这一节的批评是：四条好处全是"能让你了解"，没有一条给判据。什么叫跑偏？偏多少算偏？浪费 token 浪费到什么程度该管？一个教程如果只告诉读者"要去看"，不告诉"看到什么算异常"，那它还是文章，不是教程。这一节本来是全书最有可能立住的地方，它差的就是三个具体的反例。

顺便说一句四种模式。标准、PTC、极简、创造，作者的态度很干脆："别当成四个产品。就是四套开箱模板，这一局里给它装了哪些手，不一样而已。"标准是"完整干活套装，文件、命令、搜索、Skills、计划、子 Agent，都给你预设好了，第一次用，无脑选它"；PTC 是"让模型通过写一段代码的方式，把多步工具压成一次跑，步骤特别碎的时候才用，小白先别碰"；极简"只留终端和改文件，官方拿来测模型裸能力的"；创造"标准能力都有，还能改自己，没错，就是改自己"。

四种模式里，"创造"是唯一能和别的产品拉开差距的——让 Agent 改自己的界面，这在精装房产品里做不到。但作者只给了它四行字，然后建议"无脑选标准"。这个建议对一个赶时间的人是负责的，对一个想搞清楚这产品为什么值得存在的人是不负责的。

六、插件是零件，不是装饰

第六章是全书唯一有"观点"的一章，也是我读得最认真的一章。作者的论证路径是这样的：

先摆两条现有的落地路线。第一种是直接用现成的 Agent 产品（Claude Code、Codex、WorkBuddy）："好用。但产品是人家的。界面、流程、能不能接你们内部系统，都得等官方优化、更新。你是用户，不是产品的主人。"第二种是自己从零写一套："贵、慢，技术一更新，你的框架还得跟着改。"

然后是那句我觉得最精准的概括："第一种就是'精装房'，只能住，不能改。第二种就是'从地基开始建'。绝对是大工程，而且任何纰漏都得重来。"

DSH 走的是第三条：Harness 开源，"给到我们几乎所有的基建能力（Agent、Harness），但是任何的应用层都不提供。纯纯的'毛坯房'"。接着是数据：社区插件"已经 1w+ 了"，GitHub 的 dsh-plugin 话题下显示 "11,842 public repositories"。作者自己先泼了盆冷水："水分有，蹭标签的也有。但速度是真的快。"

然后是我认为全章最有信息量的一句，因为它不是从产品出发，是从人出发：

内测时就有人说，大家都不怎么正经测产品了，闷头写插件。而且，我身边，是实打实有很多朋友，从做 Skills 转向了做插件。（p0032）

这句话解释了插件为什么涨这么快，而且解释得比任何官方说法都实在：不是产品好，是人往摩擦力低的地方走。Skills 是文件驱动，写起来简单，但能力有天花板；插件是代码驱动，能做的东西多一个数量级。当同一批人发现第二种方式能做出更多东西时，迁移是必然的，跟产品经理的规划没关系。

再往下是这一章的结论，两句我很认同的话：

"所以，毛坯不是没做完。是把产品层让给你。"
"所以，插件生态的产业意义，不是热闹。插件不是装饰，插件是零件。Agent 产品第一次有了供应链。"（p0032）

我要给"供应链"这个说法点个赞，因为它比"生态"准确得多。生态讲的是繁荣，供应链讲的是分工。繁荣是个结果，你没法管理；分工是个机制，你可以参与。说"Agent 有了供应链"，意思是这个行业从"每家公司自己造一台机器"变成了"有人专门造螺丝，有人专门组装"。这个转变在软件史上发生过很多次——包管理器、容器镜像、建站插件——每一次都伴随着开发成本的量级下降。

作者还补了一个很现实的推论："对于公司，不用从零造轮子，也不用求大厂排期。缺哪块零件，装哪块。没有的，创造模式里说清楚，现场造。如果你擅长交付，有人一天、几十块钱，就能搓出三个插件开源出去。"（p0032）

"不用求大厂排期"这六个字，是写给所有被 IT 部门拖过的人看的。它比任何技术论证都有说服力。

但这个论点有一个作者没提的前提，我必须补上：供应链成立的前提是接口稳定。

包管理器生态能长成今天这样，是因为清单文件的格式十年没大改；容器镜像能通用，是因为镜像规范早早冻结。反过来看 DSH：它现在"连文件浏览、记忆这些别人默认就有的东西，出厂都可能没有"，说明内核还在剧烈变动。在这种系统上建供应链，风险不是"插件不够多"，而是"插件半年后集体失效"。

这不是唱衰，是给读者的风险提示：如果你打算在公司里基于插件搭一套东西交付，第一件事是把插件的版本锁死，并且准备好自己维护那份分支。作者的论证止步于"插件涨得快"，没走到"你的插件能不能活过两次大版本"。这一段的缺失，让整章的乐观少了一个支点。

章末作者给了自己的组合方案："Codex 做系统级别的大项目。DSH 搭配 Kimi K3 和 Deepseek Flash 做知识数理类任务。以及，尽情用 DSH 实现脑子里天马行空的想法。"然后列了一串场景："看板、游戏、桌宠、自媒体工作台、外贸团队、微信机器人、自动销售……"最后一句挺动人："不知道这是不是梁圣心里通往 AGI 的路，但现在已经至少是。"

这段我读的时候笑了。它诚实得有点不像产品文——一个推荐自家工具的人，第一节就说"Codex 做大项目"，把最难的部分让给了别人。这种"知道自己边界在哪"的推荐，比"我们什么都能干"可信十倍。

七、它的短板

前面已经散着批评了几处，这里集中说。我认为这本书有六个问题，前三个是硬伤。

第一，35 屏、2 分钟，它不是书。微信读书在书末直接标了"已阅读 2 分钟"。一节是一个 npx 命令加一段说明，五个插件是五个 GitHub 链接加一句介绍，第六章是一篇千字感想。这样的体量按单行本卖，读者的失望是可以预期的。我不认为这是作者的错——他本来写的就是一篇公众号文章，是出版方把它装订成了书。

第二，只有顺风路，没有一次翻车。全书零报错、零装失败、零成本账单。安装那节写"电脑里已经有 Codex、Claude Code 或者 workbuddy 的，命令看不懂也没事，整段丢给它就行"——这等于承认读者可能看不懂，但仍然不给失败路径。而所有真正用过 Agent 的人都知道，时间全花在失败上：密钥填错、代理连不上、工作区选错、插件装了不生效、模型回了但工具没调。这些一个都没写。

第三，权限那一段点破了洞，却给了个错补丁。这是我最不能接受的地方，前面已经说过：作者明确指出 Workspace Write "限制的是写，不是看"，然后一句"所以就用这个就行了"。在一个 Agent 可以联网、可以读文件的产品里，这句话是有风险的。至少应该补一句"别把密钥放在工作区外还能读到的路径"——他没写。

第四，没有版本锚点。Node 22.19、@deepseek-ai/dsh、127.0.0.1:3080、五个个人仓库（omdsh-dev、liustack、2BingLing）。这类教程的保鲜期大概三个月。书里没有任何"截至某月"的说明，也没有"如果命令变了过去哪查"。对一本纸书来说这是致命的，对一篇推文来说无所谓——它再一次暴露了自己的真实身份。

第五，论证责任被一句"愚见"推掉了。第六章开头："先叠个甲，以下观点纯属个人愚见……"这句话在网络语境里是自嘲，在书里是免责。因为这一章的全部内容——供应链、企业落地、Skills 转向插件——都是判断，不是事实。判断需要论证，而它用一句话把论证的义务转给了读者。

第六，结构上有断点。第一章讲 Agent 是什么，第六章又讲一遍"两种落地思路"，中间隔着四节安装教程。读者从第一节读到第六节，中间要经历一次从"概念"到"点按钮"再到"谈产业"的落差，回来的时候概念已经凉了。这不是致命的，但它说明这本书没有经过一次完整的编辑。

我把这六条摆出来，不是要否定它。恰恰相反：一本 35 屏的小册子，能被挑出六条具体的毛病，说明它至少说了六件具体的事。那些读完什么也挑不出来的书，才是真的什么也没说。

八、怎么读，谁不必读

如果你的时间只有半小时：读 p0002–p0012 这 11 屏。重点三段——p0006 的"有嘴没手"，p0009 的"Agent = Model + Harness"和那份八词清单，p0012 的三件事（工作区、给工具、写规矩）。这三段读完，你对 Agent 的理解会超过大多数天天在用的同事。

如果你准备真的上手：p0015–p0023 照着点一遍，重点是 p0018 的权限说明（记住"限制写不限制读"）和 p0021 的轨迹模式入口。装完先别急着干活，随便跑一个任务，然后去轨迹里看它第一步读了什么。这一步的价值比装十个插件大。

如果你在做技术选型：p0031–p0034 当观点看，不当结论。它的"供应链"判断我认为是对的，但"插件涨得快"不等于"插件能长久"，你得自己去核一遍那几个仓库的活跃度和维护者。

谁不必读：想系统学 Agent 工程的人。这本书不教架构、不教评估、不教成本控制，它只教"这东西是什么"和"怎么装"。你要的那套东西在这本书里没有。

一句话：它用 35 屏把"Agent 靠什么干活"讲成了一句能背下来的话，这是它的全部价值，也是它的全部野心；而它最大的失手，是在点破"外壳能读全盘"之后，只回了四个字——"用这个就行了"。