试遍 AI 写作工具之后，我决定从 0 手搓一个写作agent

过去一年，我试了你能想到的几乎所有 AI 写作工具。

它们都有一个共同点：第一次打开，上头。特别上头。你啪一个主题丢进去，标题、大纲、正文哗地出来，还能顺手给你捎几条小红书文案。

爽感拉满。

然后呢？

用到第三次、第五次、第十次的时候，那种感觉开始往下掉。不是因为它不会写了。老天，它太会写了。它能把一句“用户增长遇到瓶颈”扩成三段，引经据典，丝滑得像抹了油。

真实的问题不是写作能力。

是它每次都像第一次见你。

你得告诉它我是谁、写给谁看、不喜欢什么风格、上次删掉过哪种表达、这条号的读者更吃哪一路、哪些话看着漂亮但放在我这里就是不搭。

一遍一遍说。

这就很扯了。一个工具如果每次都得我重新介绍自己，那它更像一个临时外包，不像长期搭档。

所以我准备从 0 手搓一个写作 Agent。

不是“帮我生成一篇文章”的那种工具。是一个能逐步理解我内容业务、记住我的判断、参与内容生产流程的 Agent 工作台。

这篇是这个系列的第一篇。我想先讲清楚一件事：为什么我不想再做一个普通写作工具，而是想从一个很朴素的闭环开始，慢慢搭一个真正能长期工作的写作 Agent。

一句话版：我要解决什么问题

如果只看表面，AI 写作工具解决的是“写得快”。

但我真正想解决的是：

内容生产里那些反复出现、很难说清、但又决定质量的判断，能不能被系统记录下来，并在下一次写作时继续发挥作用？

这句话有点长。拆开看，其实是三个问题：

也就是说，我不只是想要一个更会写的模型。

我想要一个更懂流程的系统。

写作工具的问题，根本不在写作

大多数 AI 写作产品有个默认假设，很直接：

用户缺的是一篇文章。

所以产品路径也特别直接：

这个路径本身没毛病。它确实能让人更快地从空白页面里出来。

但它只擦到内容生产最表面那层皮。

真实的内容工作，我指的是稍微认真一点的那种，不是从“写正文”开始的。也不是在“生成正文”结束的。

写之前，你脑子里转的东西其实比正文本身多得多：

• 这篇文章到底想解决什么问题？
• 它是观点文、教程、案例，还是产品记录？
• 读者为什么要点开？
• 标题要锋利一点，还是稳一点？
• 哪些话题得绕开？
• 哪些表达虽然漂亮，但会让人觉得油？
• 发完之后，什么反馈才算有效？

这些东西搁在平时不一定会被写下来。但它们确实在。

一个老练编辑的核心能力，不只是写句子，而是做这些判断。

所以，如果 AI 写作产品天天只盯着“生成正文”，它本质上解决的是打字速度。不是内容经营。

我想做的写作 Agent，目标不是把一段话拉得更长，而是把内容生产里那些隐性的判断流程，放到产品里去。

一步一步来。

写作 Agent 到底该是什么

我先给一个定义，可能有点重：

写作 Agent = 内容生产流程的决策系统。

听着挺唬人的对吧。

但如果它只是一个“生成器”，我只需要关心 Prompt 怎么写、模型怎么选、输出怎么润色。

如果它是一个决策系统，问题就全变了。

它得知道一次写作任务的目标是什么，得能判断从哪个角度切入，得区分清楚公众号和小红书不是一种写法，得能嗅出哪些表述有风险，得记住用户的长期偏好，得从发布后的反应里学到东西。

问题就从“怎么调 Prompt”，变成了“怎么设计一个内容生产闭环”。

这个闭环我在脑子里转了很久。它至少有七个环节：

正文生成只是其中一环。

它很重要。但不是全部。

如果只优化“写作”这一环，工具会越来越像一个高配文本生成器。可如果把整个闭环串起来，它才有机会从一次性工具，长成一个持续变好的工作台。

为什么先搞公众号

我没一上来就做全平台。

原因是公众号文章这件事，在一个特别巧的位置上：既够复杂，又没复杂到离谱。

它不是短文案，不是一句钩子定生死的玩法。公众号要主题、要结构、要论证、要节奏、要收束。但它也不是一个完整的商业内容系统，不用一上来就接入发布平台、数据分析、CRM 还有各种权限。

它刚好是中间点。

如果一个 Agent 连公众号文章都稳定不下来，策划、生成、审稿、复盘这条线跑不通，那更复杂的场景也白搭。

第一阶段的靶子我收得很窄：

给定主题、目标读者、文章目标、语气和约束，让 Agent 稳定产出一篇能编辑的公众号文章。

这里头有两个词我想强调一下。

第一个是“稳定”。

我不指望第一版出爆款。这不现实。我更在意它每次输出的结构是不是清楚，字段完不完整，语气控不控得住，人好不好接着改。

第二个是“可编辑”。

Agent 别装得跟能一次性交终稿似的。更合理的路子是这样：它先吐出 70 分的结构化草稿，把人从空白页面里拽出来，然后留足空间让人判断和修改。

这也是我对早期 AI 产品的基本看法。

别急着替代人。先稳定地接住人的一段工作流。

第一版不搞多 Agent

写 Agent 这事，太容易被“多 Agent 架构”勾走了。

Planner Agent、Content Agent、Review Agent、Memory Agent、Reflection Agent，光名字列出来就很有科幻味儿。画进架构图里的时候更甚。

但我不打算第一天就把它们全堆上去。

不是多 Agent 没用。是多 Agent 太容易把早期产品真正的问题盖住。

输入边界还没定清楚，输出格式还在飘，文章结构都没个定义，用户反馈也没地方记。这时候拆多少 Agent 都是白扯。除了把同一套混乱摊到更多节点里，啥也没干成。

第一版真正要紧的事就一个：把最小闭环走通。

所以我会先搞一个特别朴素的版本：

猛一看，这不像个复杂 Agent。

更像一条被约束得很死的写作流水线。

但我觉得，这正是第一版该有的样子。Agent 产品早期最值钱的事，不是“看起来像科幻”，而是每一步你都能说清楚它为什么在这儿。

真正的门槛是长期性

AI 单写一篇文章，不难。

真的不难。

难的是写到第十篇、第二十篇、第一百篇的时候，它是不是比之前更懂你了。

说实在的，这才是我最在意的事。

一个写作 Agent 如果每次只靠当前 prompt 活着，它就永远是个一次性工具。用户越认真，越得反复补背景。用得越久，越烦。

但如果它能记住这些呢？

• 你不喜欢那种太像广告的味儿。
• 你的文章习惯先讲问题，再摆产品判断。
• 你的标题可以锋利，但别标题党。
• 你的读者更买实战观察的账，不太吃泛泛的趋势。
• 你上次把过度夸张的转化话术整段删掉了。

这些记忆不需要一上来就搞得特别玄乎。真的不需要。

早期你甚至用不着模型微调。就老老实实把用户行为和反馈记下来，然后以一种可解释的方式塞进下一次生成里。这就已经能显著改善体验了。

比如你每次看到“颠覆行业”就删。系统慢慢就该知道了：这人烦那种宏大空泛的词儿。

你又每次都保留“从一个具体问题切入”那种开头。系统就该知道了：这个号好这口，问题驱动的结构。

这个才是写作 Agent 的长期价值。

不是第一次生成有多炸。是第十次的时候，它已经不像个陌生人了。

我想做的不是写作软件

光看界面，这玩意儿可能长得跟写作工具差不多：输入框、生成按钮、文章预览、导出按钮。

骨子里不是我想要的东西。

我想做的是内容运营工作台。

写作只是入口。绕着一篇文章，会慢慢长出各种模块：

这些模块拼到最后，会变成一个很奇怪的东西：一个小型内容运营团队。

只不过团队成员不是人，而是一组能协作、能记忆、能复盘的 Agent 能力。

这也是我给项目起 LatentOps 这个名字的原因。

很多运营能力平时是沉在水下面的：潜在的、隐性的、丢在经验里没人整理。Agent 的机会，不是替代人脑子里那些东西，而是把这些隐性的流程拽出来，变成能调用、能记录、能迭代的系统。

这个系列怎么写

接下来我会用一组文章，把造这个 Agent 的过程记下来。

它不会是纯技术教程。我不会每篇从“新建项目”开始，也不会把所有笔墨耗在代码细节上。技术会出现，但它要回答的是一个更大的问题：

为什么这个 Agent 需要这个能力？

我会按能力的进化来写：

我想通过这个系列试着回答一个问题：

当 AI 从一个聊天框，变成一个能参与业务流程的 Agent，产品到底会发生什么？

对我来说，答案暂时不叫“完全自动化”。

至少在写作这件事上，我不信一上来就该奔着无人参与去。

更现实，也更有价值的路是：让 Agent 接住重复劳动，让人保留判断权。让系统记录每一次判断，然后把这些判断变成下一次的上下文。

这就是我准备从 0 手搓一个写作 Agent 的全部原因。

下一篇，从那个最朴素的问题开始：第一版为什么不急着搞多 Agent，而是先闷头让它稳定写完一篇公众号文章。