15. Final

长在业务里的 Agent：12 个零件，合起来是一台什么机器

上一篇，我们走完了最后一公里，从 Agent 的心跳出发，一路拆到用户触碰到的交互细节，前后共十四篇，把机器的每一个零件都摊开看过了。可拆解只是手段，不是目的。这最后一篇，我想退后一步，把这一地零件重新合起来，整体看看：它到底是台什么样的机器？以及从开篇以来我一直惦记着的问题，「这不就是套壳吗」，走到这里，我可以尝试更完整地作答

🪧 把散落的零件，拼凑起来整体看

动笔前，我把前面十四篇在脑子里再过了一遍，感觉自己像个拆机器的工程师，把一台发动机拆完、零件铺了一地。为了不让自己迷失在局部细节里，有必要后退一步，重新问下自己：这些东西合起来，到底是个啥？

12 个机制，拆开每一个都不新鲜，Loop、Memory、Tools、Permissions，这些在任何一份 Agent 文档里都能查到。真正难的，不是知道「有哪些零件」，而是让它们拧成一台专为写作而生的机器：每一处咬合背后，都藏有为写作这个场景而做的决策

所以这一篇不讲新东西，只做两件事：把机器合起来，看清它的全貌；再把散落在十四篇里的几条暗线，具体再讲一遍

🖥 模型是发动机，Harness 撑起了系统的骨架

先回顾下开篇的总体架构图，当时做了这样一个比喻：AI Agent 产品 ≠ 大模型 + Prompt，而是 = 模型（发动机）+ 一整套 Harness。 走完十四篇，这张图上的每个部件，现在都有了名字和面孔

如果给这台机器的每个零件做一次「角色定性」，它很像一个有机的整体，各司其职：

这张表想表达的，是那条从序章就埋下的递进因果链：它不是零件的平铺，而是一环扣一环。先得有个会转的引擎（Ⅰ），转起来自然要跨时间记住东西（Ⅱ）；能记住了，才谈得上塑造它的行为（Ⅲ）；行为得能安全地作用到真实世界（Ⅳ）；复杂任务还得能拆解分工（Ⅴ）；最后，这一切得包装成一个用户能轻松上手的产品（Ⅵ）。抽掉中间任何一环，后面就会踩空

🧬 一条「越关键，越要从模型手里接管」的暗线

合起来看，能看清几条贯穿始终的「暗线」。第一条事关「确定性」，前面好几篇里都提过：

凡是「必须发生」「绝不能发生」，或者「错了代价特别大」的判断，最后别只靠模型自觉，而是想办法用确定性的机制，把它从模型手里稳稳接管过来

把散落在各篇的类似动作收拢到一起，是这样一串：

• 写作根本不需要通用 shell，把 Bash 整个删了（第 8、9 篇），一整类风险凭空消失
• 16 个题材模型容易挑错，那就不让它挑，用一条确定性的链路单选注入（第 6 篇）
• 斜杠命令可能被 CLI 悄悄吞掉，在后端剥掉前缀、确定性地加载（第 7 篇）
• 关键环节模型会漏，用 hook 在生命周期点上焊死（第 10 篇）
• 终检容易自己给自己放水，派一个只读、绝不下场改的独立分身去把关（第 12 篇）
• LLM 吐 JSON 会散漫、上游还有 bug，叠三层防御 + schema 白名单兜住（第 12 篇）
• 画像信号天生含噪，不自动回写，让用户逐条 Review、亲自点头确认（第 4、13 篇）
• 模型爱问蠢问题，就在末端加一道澄清过滤闸（第 14 篇）

这几个看似孤立的选择，其实是同一件事：把「不确定性」这个又宝贵又危险的东西，省着用在真正需要它的地方，也就是创作本身；其余能确定的，一律用程序化逻辑接管。 模型的自由发挥，该留给「把这句话写得像你」，不该留给「这个命令该不该触发」

🔀 所有输出，最后都落在「两条通路」

模型吐出来的东西五花八门，但说到底，形式上都能归到两条通路。项目里不少产品决策，说白了就是要想清楚一件事，这东西到底是给人看，还是给代码用：

• 通路一，给人看的：你在界面上看到一个字一个字冒出来的思考和最终成文，它自由、流式、有温度，还能被你随时打断
• 通路二，给程序用的：num_turns、画像分析的结论、终检报告、plan 的 JSON、二次编辑的 diff。这些不给用户直接读，是喂给后台代码的，所以必须结构化、可校验、能落库

前面的篇章里也反复提到，两者不要混在同一次调用里。第 1 篇没有拿 num_turns 去给用户当「对话轮数」；第 8 篇发现 @tool 回传不了结构化数据，索性让结构化结论另走带 schema 的查询；第 12 篇的终检、第 11 篇的 plan，都靠这条边界把「给人的」和「给程序的」明确分开

⚖️ 通用与垂直，差的从来不只是模型

写到这儿，终于能把整个专栏最想说的一件事挑明：怎么让你精心打磨的产品，不沦为「又一个通用 Agent」的套壳。 把每篇末尾的对照表收拢成一张总表，能看得更清：

⚖️ 取舍现场 · 十二处「默认怎么做 / 我为什么不那么做」

机制	「偷懒」 的默认做法	SmartWriter 的定制
Loop	参数一股脑暴露、num_turns 直接显示	只露模型和预算，轮数前端自己数
Compact	对压缩无感	盯compact_boundary，把核心立意补回来
Session	切走就丢	resume 精确恢复 + fork 试错，自建持久化
Memory	一锅粥混着，什么都记	风格 / 规则 / 事实三权分立，灵魂严防污染
System Prompt	沿用编码人格	从第一个字符起就是写作副驾，动态值全赶走
Skills	一堆 skill 丢给模型自选	高价值的题材判断，确定性单选接管
Command	功能开关	产出契约：说清这次动不动你的作品
Tools	万能 Bash + 自由发挥	确定性操作一件件固化成专用工具
Permissions	给全套，求「无所不能」	删掉 Bash，求「无所不安全」
Hooks	靠模型自觉执行关键步	在生命周期点上用代码焊死
Plan Mode	直接切 SDK 原生 plan mode	不切 mode，复用自己的审批回调拦一道
Subagent	让子任务污染主上下文	隔离噪声，理解收敛回主 agent

模型是公共的，掏钱谁都能调；真正不一样的，是这十几处「为写作场景量身定做」的取舍。它们没有一条是放之四海皆准的公式，全都是贴着业务一点点磨出来的。垂直 Agent 的护城河，不在模型有多聪明，而在于你愿不愿意为自己的业务，在每一处摩擦点上，都亲手做一遍「减法与定制」

🧭 如果你也想把某个 Agent 嵌进自己的业务

说完了「哪里不一样」，也想聊聊「怎么做到不一样」。写这一系列笔记，出发点是记录自己的所思所学，也存了点私心，想把攒到的经验分享给同路人。如果你也要把一个通用 Agent 嵌进某个垂直场景（写作、客服、法务，随便什么都行），希望我摸出来的这套「方法论」，能帮你省点弯路。拆开看就 4 步：

1. 拆解：先别急着写代码，把「Harness」拆成一个个机制（引擎、记忆、驾驭、交互、编排、业务），看清楚手上到底有哪些零件
2. 逐层裁决：对每一个机制，都逼自己问一句，「在我这个场景里，通用的默认做法合适吗？该加什么、又该狠心删什么？」这一步的取舍颗粒度，决定了它最后是「长在业务里」还是「只是套壳」
3. 组装：把裁决过的机制，串成一条你这个业务真实的动线，让它们上下游协同起来
4. 翻译成界面：最后一公里，把这套精密又晦涩的机器，翻译成你的用户（也许不懂 Agent）能一眼看懂、轻松上手的样子

这四步里，我个人经验是第 2 步「逐层裁决」最关键。所谓的「又一个通用 Agent」，大概率是这一层没想透，匆忙把默认配置照单全收了。这一步值得多花点时间琢磨，回报绝对值得

🎬 是个精心打磨的「套壳」，我是这样说服自己的

绕了十五篇，方法论讲完，也该回到那个问题了：开篇朋友无意的那句「这不就是套了个壳吗」

现在我的想法笃定多了：「套壳」这个词，我不反对，但在它前面，我想加两个字：「精心」。因为这个「壳」，从最里头那颗会自转的心跳，到最外面那块替用户消音、翻译的界面，每一层，都是实打实的功夫，都是为「写作」这一件事，重新裁剪过的取舍

但话说回来，Agent 的产品形态还在飞快演进，这套笔记，充其量是某个时间切片上，一次个人项目实践的真实记录。里面的一些判断，过一阵就 outdate 了，也很正常。但至少，这里的每一个坑，都是我真实踩过的；每一处取舍，都是我掂量再三才落子的。如果它能让你在建自己产品时，少绕一段远路，或者只是多问自己一句「这一处，我真的该照抄默认吗」？那这十五篇，就没白写

谢谢你能读到这里。咱们，下一次 Vibe Coding 见 🌈