XKC 的不定期分享

读完 Claude Code 产品负责人的方法论，我觉得 AI PM 最难的不是方法，而是判断

2026-04-05T16:00:00.000Z

最近读了 Anthropic Claude Code 产品负责人 Cat Wu 的一篇文章，讲 AI 正在怎么改变产品经理的工作方式。她总结了几条很有代表性的变化：短冲刺、把 demo 和 eval 放到文档前面、随着新模型发布持续回看已有功能，以及「做能工作的最简单实现」。她举的 Excalidraw 例子也很鲜明：从 Sonnet 3.5 开始，每次新模型发布都让 Claude Code 给 Excalidraw 加同一个功能；一开始总失败，到 Opus 4 偶尔能成功，再到 Opus 4.6 已经稳定到可以在几千人面前 live demo。

这些原则我基本都同意，而且很多也在用。但读完之后，我最强烈的感受不是「我不同意什么」，而是：她讲清楚了该做什么，却没有展开做这些事时最难的那一步，持续判断和持续选择。

我也是这么干的

先说做法本身。这部分我和她的观点高度一致。

原型先行。 我做 AI 功能，通常也是先搭一个能跑的 demo，而不是先写一份完整文档。有时候是一个可以直接上手体验的前端原型；有时候则是一个把业务逻辑跑通的脚本，里面把路由策略、工具调用、结构化输出都串起来。对我来说，这类东西既是方案表达，也是评估载体，很多时候本身就是 spec，不需要再额外写一份说明文档。当然这不意味着不要文档（PS：我甚至做了一个从 demo 反向生成需求文档的 Agent Skill），但起点一定是一个能跑的东西，而不是一份描述它应该怎么跑的文字。

而且，AI 产品里的「原型」和传统产品里的原型，本来就不是一回事。做传统产品，一个可交互页面往往足够验证流程和交互；但 AI 产品真正的不确定性不在界面上，而在模型行为上：它能不能理解输入、该不该调工具、输出是否稳定、结构化结果能不能落到预期的 schema 里。一个纯前端 mockup 回答不了这些问题。AI 产品的原型必须让真实模型跑起来，哪怕 UI 很粗糙都没关系，但关键逻辑必须是真的。凭空想象模型的行为然后画一个交互稿，做出来的东西和实际表现之间的差距可能大到让整个方案推倒重来。

评估驱动。 这一直是我做 AI 产品时最看重的事。我去年写过一篇文章专门讲这件事：AI 产品从确定性走向概率性，同样的输入可能产生不同的输出，你没办法像传统软件那样靠 if-else 的逻辑去保证正确性，只能靠系统性的评估去理解真实表现。Cat Wu 说她的团队用 eval 来量化功能效果，我的做法是把评估直接嵌入工作流。评估的不只是模型和提示词，编排策略怎么设计、工具调用怎么定义、结构化输出的 schema 怎么约束，这些都是变量，都要拿真实用例去跑。多个模型 × 多种策略 × 多组用例交叉下来，才能看到每种组合的真实表现和失败模式。这套东西搭建起来有成本，但一旦跑通，后续每一次决策都有据可依。

持续回测。 新模型出来，真正有价值的动作从来不是「试两个 prompt 看看感觉」，而是把它带回自己的业务场景，用自己的评测用例去跑一遍。通用 benchmark 上的排名和你实际场景里的表现经常不是一回事。Cat Wu 文章里也强调了每次新模型发布都值得重新审视已上线功能，这一点我非常认同。

这些做 AI 产品的人大多都在往这个方向走，并不算稀奇。真正值得展开的，是她文中提到、但没有深讲的那部分。

「做能工作的最简单实现」听起来很简单

原文里我最在意的一句，其实是：do the simple thing that works。这句话比「做最简单的实现」更准确，因为关键不只是简单，而是「能工作」。

Cat Wu 给的例子也很典型：Claude Code 的 todo list 功能刚上线时，模型不会稳定地把完成项勾掉，于是团队每隔几条消息插入一次提醒，催 agent 去更新自己的 todo list。下个模型升级之后，这个行为模型自己就会了，提醒直接删掉。她还提到，随着模型升级，system prompt 和工具描述不断被精简，到了 Opus 4.6 又削掉了大约 20%。

很顺的一个循环：加临时方案，等模型升级，删掉临时方案。之所以顺，是因为在这个叙事里，决定性变量主要是模型能力本身。

她其实也提到了成本的问题，原文说先为能力优化，用比你觉得需要的更多的 token，之后可以等更便宜的模型追上来再压成本。这个思路没错，但她没有展开的是：当你真的开始在多个模型之间做选择的时候，事情会复杂很多。

做 AI 产品不太可能只用一个模型。成本、速度、能力各有侧重，便宜的模型适合跑用户高频使用的日常功能，贵的模型留给需要强推理能力的场景，有时候还要针对不同地区或不同供应商的稳定性做备选。这就意味着你同时在用好几个模型，而它们的迭代节奏完全不同。

只依赖一个模型的时候，「做能工作的最简单实现」执行起来很顺，等模型升级，删掉旧的临时方案，收工。同时用好几个模型的时候，同一个临时方案在旗舰模型上可能一两个月就能去掉了，在便宜模型上可能半年都还得留着。你不能全切贵的，成本扛不住；也不能干等便宜的追上来，体验跟不上。

所以这条原则本身我还是认同，只是到了多模型环境里，「简单」不再意味着「等下个模型就行」，而是意味着你要不断判断：这个临时方案在哪个模型上还要留多久？什么时候该切？切了之后成本怎么变？不同模型之间要不要维护不同策略？真正难的，不是知道要做简单实现，而是知道什么阶段该简，什么阶段还不能简。

支线任务

Cat Wu 在文中用了一个很贴切的说法：side quest（按照个人习惯，翻译成支线任务，开放世界你知道吧？）。她的意思是，团队里每个人都可以拿出一小段时间，做一些路线图之外的自发实验：搭个没人要求的原型，试试模型的新边界，验证一个原本只存在于直觉里的想法。她提到 Claude Code 的一些受欢迎功能：桌面端支持、AskUserQuestion 工具、todo list 等等就是这样长出来的。

这件事我也很有共鸣。对我来说，很多真正推动决策的工作，本质上都是支线任务。有时候是把一个还停留在讨论里的功能，先做成可运行的原型，看看它到底跑不跑得通；有时候是在设计正式开始之前，先把评测框架搭起来，这样后面方案一出来就能直接测；有时候纯粹是因为新模型刚发布，我想知道它在自己的场景里到底比老模型强了多少。

这些支线任务确实推动了很多产品决策。有的原型直接改变了方案方向，有的评测结果让团队在两个争论不下的方案之间有了明确依据。

但支线任务能不能持续产出价值，不只取决于你自己愿不愿意做。 你花半天验证了一个方向，团队的注意力可能已经转走了；你证明一个方案可行，但产品重心突然调整了；你想把上次支线任务的成果接回主线，却被新的优先级覆盖掉了。这些不是例外，反而是现实里很常见的问题。

单次看，一个支线任务被搁置好像没什么大不了。但如果这种事反复发生，代价就会累积成更大的问题：你会持续错过窗口，新模型带来的能力窗口、用户需求变化的窗口、竞品还没反应过来但你已经验证过可行性的窗口。Cat Wu 说 Claude Code 的很多功能是从支线任务里长出来的，反过来说，如果那些支线任务当时没有得到团队的响应和跟进，这些功能可能就永远不会上线。

所以我越来越觉得，支线任务不是「个人是否足够积极」的问题，而是「团队有没有能力吸收个人试出来的东西」。Cat Wu 描述的 Anthropic 是一种组织级的状态：不同角色都在主动跨界做实验，支线任务是团队的默认行为，不是某个人的个人习惯。当这种工作方式只在个别角色身上发生，而不是整个团队的风格时，「角色边界模糊带来的加速」就很难带来产品上的演进。

实践里更难、但原文着墨不多的部分

原文整体是乐观的：模型更强，工具更好用，团队更快。作为方法论介绍，这没有问题。但在实际做事时，有几件事的存在感其实非常强。

AI 把瓶颈从信息获取挪到了判断与取舍。 以前难的是信息不够：搜集、整理、比较、验证，都很慢。现在 AI 几分钟就能铺出十种都说得通的方案。信息获取的成本被压得很低，但「到底选哪个」这件事并没有因此变简单，很多时候反而更难。因为你看到的取舍更多了，每个选项都不荒谬，每个选项都有道理，而最后拍板靠的仍然是你对业务的理解、对风险的偏好、对时机的判断。工具越强，判断越值钱。

最大的风险不是 AI 做不到，而是它做出了一个「看起来对」的东西。 报错不可怕，报错是诚实的失败。真正麻烦的是它产出了一个逻辑自洽、运行正常、甚至局部表现不错，但整体行为和你目标并不一致的结果。很多 AI 原型最危险的地方，不在于它跑不通，而在于它跑得太通顺，以至于你误把「能运行」当成「已验证」。

评测减少了未知，但没有替你做选择。 跑完一轮评测，你拿到的常常不是答案，而是一组取舍：这个模型准确率高但贵，那个便宜但某类场景会出错，另一个速度快但输出格式不稳定。评测当然重要，它至少让你不再在黑暗里做决定；但它并不会把复杂选择变成单选题。很多时候，数据越充分，你看到的矛盾越清楚，决策也就越难。

评估本身也越来越像一个独立的系统工程。 最早期的评估很直接：出一组问题，对一组标准答案，看对了几个。后来产品逻辑变复杂了，评估开始变成流程化的事情：定义一套 workflow，规定每一步的输入输出和判断标准，按流程跑一遍看结果。再后来产品开始用 Agent 架构，评估的对象就不再是单个回答了，而是一整条决策链路：它选了什么路由、调了什么工具、中间状态对不对、最终结果合不合理。你没办法用一个固定答案去判对错，因为合理的路径可能有好几条。这意味着评估本身也在从固定流程走向 agentic 化：你可能需要用 agent 去评估 agent，用模拟环境去复现真实场景，用运行时的行为轨迹去做判断而不只是比对最终输出。针对自己业务的评估体系会越来越重，越来越像一个需要持续投入的工程问题。

Excalidraw 这个故事成立的前提

Cat Wu 的 Excalidraw 例子之所以让人觉得理所当然，是因为这个故事里最显眼的变量几乎只有模型能力：模型弱的时候做不到，模型强了就做到了。这个叙事非常顺，也非常有说服力。

但它之所以能成立，还有一个前提：她所在的团队与模型演进之间的距离很短。原文里其实也反复在讲，团队会随着模型能力变化快速重做原型、回看功能、压缩 prompt 和工具描述，并且原型阶段优先追求 capability，再等待更便宜的模型追上来。对拥有模型、并且能更早感知模型变化的团队来说，这种节奏天然更顺。

而大多数做 AI 产品的团队，并不拥有模型，而是站在模型之上做产品。你没有办法决定模型什么时候变强、朝哪个方向变强、价格怎么改、供应是否稳定。你能做的，是持续评估、持续对比、持续适配。

当然，反过来看，不绑定一家也意味着你拥有选择权。你可以把同一个功能放到多个模型上跑，选最适合自己的那个；你可以在不同链路里搭配不同模型，把能力、成本和速度压到一个更合适的组合上；某一家涨价、波动或者退步了，你也可以换。拥有模型的一方少了一层选型的压力，不拥有模型的一方则必须把选择本身做成能力。

但选择本身也是成本。你要维护的不只是一个功能，而是一组不断变化的判断：哪个模型该用在什么地方；哪个临时方案在谁身上还能留多久；什么时候该为了能力付更高成本，什么时候该为了成本接受不完美；某个支线任务验证出来的方向，到底该不该现在接进主线。

这些问题，原型回答不了，评测也只能回答一部分。最后真正要做决定的，还是人。

所以我读完这篇文章，最大的感受不是「这些方法对不对」，而是最难的那一步始终没变。Demo 可以更快搭，评测可以更全面跑，原型可以更容易出，但什么时候该删临时方案、什么时候该换模型、什么时候该把支线任务推进主线，这些仍然是人的工作。

AI 的确改变了产品工作的成本结构：信息更便宜了，原型更便宜了，试错也更便宜了。但它没有让判断更便宜。恰恰相反，判断变成了更贵的部分。

龙虾之道：我是怎么开始认真用 OpenClaw 的

2026-03-08T16:00:00.000Z

一开始，我其实觉得 OpenClaw 没有任何存在的意义。

那时候我的日常组合已经非常顺手了：Claude Code 负责写代码，Claude 和 ChatGPT 负责聊天、查资料、写东西。既然这套工作流已经足够强，我看 OpenClaw 的第一反应自然也很直接：它还能补上什么？

直到我真的把它装起来，连续用了几天，我才意识到，自己一开始看错了方向。

OpenClaw 最有意思的地方，不是它又做了一个聊天界面，也不是它把一堆 AI 功能简单堆在一起。它真正不一样的地方在于，它试图把三件原本分散的事，做成一个连续的整体：记住我、替我执行、长期待在我最常用的聊天软件里。

这三件事单独拆开看，其实都不新鲜。记忆，很多产品都在做；自动化，也早就不是新概念；接入聊天软件，更谈不上稀奇。OpenClaw 的价值不在某一项单点能力，而在于它把这些能力缝成了一种持续的日常体验。只要配置对了，它就不再只是一个「偶尔打开用一下」的 AI 工具，而开始有点像一个真正常驻的私人助理。

但这件事有一个很硬的前提：模型必须足够强。

选模型

因为 OpenClaw 的工作环境，和你在网页上跟模型做一轮干净对话，根本不是一个难度级别。

在网页上，你问一句，模型理解一句，回答一句，任务相对单纯。但在 OpenClaw 里，模型面对的不是一个干净的问题，而是一整个混乱的工作现场：系统设定、长期记忆、当天日志、工具说明、最近几轮上下文、权限边界、外部状态……这些东西不是整整齐齐摆在它面前，而是一股脑地被塞进上下文窗口里。它必须自己判断：什么重要，什么不重要，什么该调用工具，什么只是背景噪音。

很多人对这件事的夸张程度，其实没有直观感受。前阵子我在小红书上看到一个很典型的例子：有人用腾讯云的免费额度装了 OpenClaw，以为 50 万 token 的额度够玩很久，结果跟它互动没几次，腾讯云就打电话来催欠费了。后来去后台一看，输入 token 的消耗已经超过了 1200 万。评论区里很多人都不理解：一句「你好」，怎么可能烧掉上万 token？如果自己直接调 API，发一句「你好」过去，明明也就几个 token，难道是云服务商在坑钱？

其实不是。问题出在 OpenClaw 的工作方式上。

因为它每一轮对话，都会把系统设定、长期记忆、当天日志、工具说明、最近几轮聊天记录，全部打包进同一个请求里，再一起发给模型。表面上看，你只是说了一句「你好」；但模型真正收到的，是一整份一万多 token 的「完整工作现场」，而那句「你好」只是压在最末尾的一小段。

可它为什么非要这么做？原因也很简单：大模型本身没有记忆。

你在网页上和 ChatGPT 聊天，关掉窗口，再开一个新的，它就什么都不记得了。OpenClaw 想让模型表现得像一个「认识我的助理」，唯一的办法，就是每次对话重新把这些事告诉它：我是谁，我平时怎么说话，我最近在忙什么，它手上有哪些工具可用，哪些事情做过，哪些事情还挂着。信息喂得越完整，它越有可能表现出一种「它一直都在」的感觉——接得上之前的话，知道我的习惯，该调工具的时候自己去调。代价当然也很明显：每一轮的 token 消耗都很高。

但这不是浪费，这是它能表现得像个助理，而不是像个只会复读的问答机的前提。

这也直接决定了两件事。第一，模型不仅要足够聪明，还得在成本上扛得住这样的消耗。第二，在这么庞大、嘈杂的上下文里，模型还能不能把注意力放在真正重要的信息上，变成了一个非常现实的考验。

所以后来我选模型，几乎不怎么看跑分排行榜，而是只看三件很实际的事：它能不能在一堆杂乱背景里抓到真正关键的信息；它能不能稳定地连续调用工具，而不是做到一半就走偏；它能不能在上下文不断拉长之后，依然保持一致，不开始编造内容。

这三件事，决定了一个模型到底能不能胜任 OpenClaw 这种「长期助手」的角色。闲聊的时候，很多模型都能显得很聪明；但一旦放进 OpenClaw 这种复杂环境里，差距会被迅速放大。

我试了一大圈之后，结论还是很清楚：Claude 系列总体上依然最靠谱。它在嘈杂上下文里抓重点的能力、连续调工具的稳定性，都做得最好，用起来最有那种「一直在同一个频道里」的连贯感。

但如果把成本也算进去，我现在觉得最平衡的，其实是 GPT 5.4。

在 5.4 出来之前，我一直主要用 GLM-5，备用模型挂着 Gemini 3.1 Pro 凑合着。5.4 发布之后，情况就不一样了。放到 OpenClaw 这种每天要聊很多次、而且经常要跑多步任务的环境里，它在稳定性、成本和综合体验之间找到了一个很少见的平衡。至于中文回复，虽然还是有一点互联网味，但比起以前已经顺了不少。

至于我之前用过的 GPT 5.2，我的评价非常简单：不好用，而且是那种完全不值得继续浪费时间的不好用。

GPT 5.3-Codex 则是另一种问题。它偏科很明显。调工具这件事，它也许确实会更好一点；但如果把它当成平时一直陪着聊天的主节点，它的回复会显得非常生硬，尤其是中文，几乎没有自然交流的感觉。它更像一个冷冰冰的执行器，不太像一个助理。

Gemini 也让我挺头疼。Gemini 3 Flash 表面上看起来很快，但放进 OpenClaw 里，经常会给我一种「心不在焉」的感觉——系统明明已经把记忆和设定都发给它了，它好像看了，又好像没看，聊起来很难真正进入状态。Gemini 3.1 Pro 则是真慢，慢到让人难受，而且你就算愿意等它半天，最后出来的结果也未必比 Claude 更好。

国产模型我也认真试过一轮，甚至还专门买了阿里云的套餐。最开始我对 Qwen3.5-Plus 的印象还不错：支持读图，聊天体验也不差。但任务一旦变深，问题就开始暴露，尤其是涉及初始化、记忆承接、多轮工具调用的时候，它就会变得不稳。后来我又试了 Kimi K2.5，实际感受是，很多 Qwen3.5-Plus 做不完的任务，Kimi 也一样做不完；而且在初始化阶段，Kimi 也经常不认真读记忆，没有把系统已经给它的信息真正用起来。

MiniMax M2.5 则是另一种失望。网上对它的评价普遍不错，但我自己放进 OpenClaw 之后，体验和这些评价差得很远。它在代码或者某些专项能力上，可能确实做过特化训练；但在这套系统里，问题不是偶尔失误，而是整体的稳定性和可依赖性都不够。除了响应快和不好用，几乎没有给我留下什么其他深刻的印象。

试到最后，国产模型里反而只有 GLM-5 让我觉得勉强能用。它在启动的时候，大概有六七成的概率，能正儿八经地把之前的记忆读进去并且用上。放到现在这个环境里，这已经算相当难得了。

说得再直白一点，OpenClaw 这种系统，测的根本不是模型「会不会说话」，而是它在复杂环境里有没有足够的脑容量和控制力。后来我越来越觉得，在 OpenClaw 里，一个模型的表现，很可能和它背后真正可用的能力规模高度相关。处理一个干净问题，很多模型都能及格；但一旦把它扔进一个充满设定、记忆、权限、网页和工具的环境里，能力不够的模型就会很快露怯。

这也是为什么，我并不建议把本地小模型当成 OpenClaw 的主力。

很多人从隐私角度出发，会天然觉得本地模型更放心。这种担心当然是合理的。但 OpenClaw 还有另一层现实：它不是一个只在本地陪你闲聊的东西，它很可能还要替你看网页、读信息、拿着工具权限去执行操作。这个时候，模型越弱，越容易在复杂页面和恶意提示里被带偏。表面上看，好像是在保护隐私；但实际上，你可能是在把更高的权限，交给一个判断力更差的执行者。

所以如果让我在「更弱但本地」和「更强但需要隔离」之间二选一，我会优先选更强的模型，然后把环境隔离做好。因为只有模型足够强，OpenClaw 这种形态才真正站得住；也只有模型足够强，它在面对复杂网页和潜在 Prompt Injection 的时候，才更有可能稳得住。

换句话说，OpenClaw 首先要解决的，不是「它能不能像 AI 一样回答问题」，而是「它能不能像助理一样不掉链子」。

浏览器与登录态

模型选对之后，下一步其实就是权限。

我一开始也低估了浏览器的重要性。总觉得「能上网」只是锦上添花，真正决定体验的还是模型本身。后来我发现完全不是这样。对一个长期助手来说，没有浏览器，它基本就是半残的。

没接浏览器之前，你让它帮你查个东西，它通常只能用自带的搜索工具抓几条摘要回来。听起来好像也还行，但真正用起来你会很快发现，这和自己打开搜索引擎搜一下，其实没有本质区别。它看不到完整页面，读不了评论区，也没法顺着链接一层层点进去看具体内容。

比如我问它：「帮我看看我的车最近有没有什么召回消息。」没有浏览器的时候，它最多只能拼几条搜索摘要给我，信息零零散散，我还得自己再去核实。但有了浏览器之后，它就能真的打开论坛帖子，翻评论区，点进相关链接，甚至顺手给我截个图，再回来告诉我：「我看了三个主流车友论坛，目前没有明显的召回讨论，但有人在提 XX 问题，要不要我继续往下跟？」这就不是在帮我搜索了，这是在帮我调查。

但光有浏览器还不够。更现实的问题是：AI 能打开网页，不等于它能打开「我的网页」。

很多网页，不登录根本没有意义。要看小红书，要进内网，要刷推文，能访问一个地址，并不代表它真的进入了我平时使用的互联网空间。它没有我的身份，也没有我的状态，更没有我的上下文。

所以在我看来，给 OpenClaw 配浏览器，不是让它学会上网，而是在给它装眼睛；让它进入那些需要身份和状态的页面，本质上是在给它配钥匙。

我用来配这把钥匙的，是 CookieCloud 这个插件。它可以把我在自己电脑上已经登录好的各种账号 Cookie，同步给 AI 用的浏览器。

浏览器加上登录态之后，它能做的事情就完全不一样了。

有一次，我在微信里跟它说：「帮我去小红书上看看，车主们都推荐什么隐形车衣。」因为 CookieCloud 已经把我的小红书登录态同步过去了，它就直接打开小红书，搜相关内容，翻了十几条笔记，最后把结果整理成一条很干净的总结给我：哪些品牌被提到最多，价格区间大概在哪，有哪些坑被反复吐槽。整个过程里，我只发了一句话，剩下的翻页、筛选、整理，它都在后台自己做完了。要是我自己去刷，光在小红书里翻这些内容，十几分钟肯定跑不掉。

如果只是普通人日常用用，直接连上自己电脑上的浏览器，其实就够了，没必要再额外折腾。但我自己是用 kasmweb/chrome 单独给它搭了一个专用浏览器容器，顺手把配置放进了我的仓库里：openclaw-browser。

我之所以这么做，是因为我需要给 AI 一个独立、干净、还能被远程控制的执行空间。它在里面翻网页、点按钮，不会污染我自己正在使用的主浏览器，而且这个容器里的登录态是可以长期保留的。更重要的是，它和我的主浏览器完全隔离——万一模型在外面的网页上被恶意 Prompt Injection 骗了，做了什么不该做的操作，爆炸半径也会被控制在这个容器里，不会直接波及到我自己的账号和数据。

当然，眼睛和钥匙本身也都很敏感。权限越大，风险越高。这套东西背后其实牵扯到容器部署、CDP 协议、VNC、反检测机制这些技术细节；如果并不熟悉这些东西，我非常不建议直接照抄。同样，CookieCloud 同步登录态这件事，本质上是在把你自己的网络身份交给 AI，风险并不小。一个真正可用的助手，一定不是一个权限裸奔的助手。无论你用的是本机浏览器，还是隔离出来的容器浏览器，都应该认真对待这里面的安全风险。

但即便如此，我还是会说：浏览器是 OpenClaw 从「会聊天的 AI」走到「能办事的助理」的分水岭。

记忆

而真正让它开始有「人味」的，不是浏览器，而是记忆。

很多人一开始会低估记忆这件事。但在 OpenClaw 里，记忆的效果，首先还是被模型能力死死卡着脖子。

OpenClaw 的记忆机制并不复杂。每轮对话开始时，它会把核心记忆文件直接作为上下文，注入到系统提示词里发给模型。我的偏好、我最近在忙的事、之前做过的关键决定，其实都已经写进系统提示词了。按理说，模型一上来就应该看到这些信息。

但有些模型拿到这些信息之后，就是不处理。

不是因为这些信息藏得太深，不是因为它找不到。它们就在系统提示词里，明明白白地摆在那里。问题在于，它就是不读，或者说，它看到了，但没有认真用。之前我试 Kimi K2.5 和 Qwen3.5-Plus 的时候，这个问题就很明显：系统已经把我的偏好、最近在忙什么都注入进去了，它第一句回复依然像是在跟一个第一次见面的人讲话。MiniMax M2.5 甚至更夸张，系统的 AGENT.md 里已经明确提醒它去读 memory 文件了，它还是直接跳过。这种体验非常差，因为我明明知道信息已经给它了，它只是没有认真走完初始化流程。

再说 OpenClaw 的记忆机制本身。和市面上大多数 AI 产品比起来，OpenClaw 在记忆这件事上，走的是一个几乎相反的方向：它记得太多了。

我平时聊天时随口提一句「我不喜欢长篇大论」，它会记下来；偶尔抱怨一句「别加那么多 emoji」，它也会记下来；最近在处理车险理赔、打算买什么东西、对什么事情有偏好，它都会默默记下来。它几乎是在试图记住我说过的每一件事。副作用当然也存在：记忆读取和存储都比较慢。每次对话启动时，能明显感觉到它有一个「加载」的过程，尤其是记忆条目越积越多之后，这种延迟会越来越明显。

但如果你去看那些主打 AI 陪伴的产品——星野、筑梦岛、Character.AI 这一类——它们走的其实是完全相反的路线。它们面对的是几百万、上千万用户，出于工程规模和成本的考虑，不可能给每个用户维护一份无限增长的细粒度记忆。所以它们会对记忆做大量压缩、摘要、合并，只保留「最重要」的东西。结果就是，聊了一个月，它可能还记得你的名字、职业、喜欢猫，但你上周随口提过一句「最近在看隐形车衣」，这种碎片信息通常早就被优化掉了。

ChatGPT 和 Claude 的记忆功能，则是另一种取舍。

ChatGPT 在 2025 年 4 月做过一次很大的升级。到那时，它实际上已经有两套记忆：一套是「Saved memories」，会从对话里提取关键事实长期保存；另一套是「Chat history」，可以引用你所有历史对话。OpenAI 的做法，是在每轮新对话开始的时候，把这些内容自动预加载进上下文里。用户看不到这个过程。好处是，它确实能记住很多东西；问题是，你不太清楚它到底正在调用哪些历史信息，有时候它会在一些非常意想不到的地方突然冒出来——比如你之前随口提过的某个地点，后来竟然出现在一张完全不相关的图片里。

Claude 的记忆上线更晚，到了 2025 年 9 月才推出，做法也不太一样。它同样会预加载记忆——每 24 小时对历史对话做一次摘要，生成一份记忆概览，再在每轮新对话开始时注入上下文。除此之外，它还可以通过工具调用去搜索历史对话，而且这个过程是可见的，你能看到它在什么时候、用什么关键词去翻聊天记录。它也支持按项目隔离记忆。整体设计比 ChatGPT 更透明、更克制，但也意味着它不太会主动把那些碎片化的细节串起来，除非你主动提起，或者当前上下文里已经给了它足够明确的关联线索。

OpenClaw 的做法不一样。它默认就是：能记就记。

乍一看，这种做法甚至有点不优雅，甚至有点粗暴。但在私人助手这个场景里，恰恰是这种不怎么筛选的记忆方式，才会在某一天突然击中我。

我印象特别深的一次，是有天晚上我问了它一个完全不相关的问题，它在回答末尾很自然地补了一句：「对了，你上周提过想看看隐形车衣，要不要我这两天再帮你去小红书翻翻有没有新的车主反馈？」说起来也挺有意思，这种主动把旧记忆重新串起来的行为，Qwen3.5-Plus 触发的概率反而还挺高。虽然它在别的方面不够稳，但在「会想起你之前说过什么」这件事上，它倒是有点天赋。

我当时是真的愣了一下。因为那句「想看看隐形车衣」，我确实是一周前随口提过，提完自己都忘了。它居然还记着，而且是在一个非常自然的时机提出来，不是那种硬邦邦的「根据您之前的对话记录」。就那一瞬间，我的感受很直接：卧槽，它真的认识我。

而这种体验，在那些为了速度和成本而大幅压缩记忆的产品里，几乎不会发生。因为那些被「优化掉」的碎片，往往恰恰就是让人觉得「它真的在意我」的东西。

当这些碎片记忆长期累积起来之后，我越来越明显地感觉到：它不再是一个每次都要从头认识我的陌生人。它知道我说话的节奏，知道我在意什么，知道哪些内容该提醒我，哪些内容别来烦我。它开始有连续性了。

定时任务

而定时任务，则是把这种连续性从「感觉」变成「现实」。

我越来越觉得，Cron 这类能力，其实是普通用户最应该优先体验的部分。因为它最容易把「AI 很聪明」真正变成「AI 对我有用」。

聊天当然很好玩，写代码当然也很酷，但真正能在日常里建立存在感的，往往不是这些高光时刻，而是那些总能准时出现的小事：节假日提醒、家人的农历生日提醒、每天早上抓特定 RSS 订阅源做一份简报、在我还没开口之前，就把该来的那条消息送到我面前。

我给家里几个人的农历生日都设过提醒。有一次，在提醒的前一天晚上，它在微信里给我发来一条消息。不是那种「明天是 XX 的生日，请注意」的模板句，而是结合了我之前聊天里提过的内容，说了一句带点个人感的话，顺手还问我要不要它帮忙搜一下附近评分高的餐厅。

那个瞬间，它就不再像一个「点开才存在的工具」。在我没打开它的时候，它也在替我想着事情。当一个系统开始在「该出现的时候」自动出现，它就不再只是一个软件功能，而开始成为生活秩序的一部分。

这也是为什么我一直觉得，定时任务才是普通用户接触 OpenClaw 最好的起点。你根本不需要先去理解什么 session、delivery、cron 表达式这些底层配置字段，把这些技术细节全交给 AI 去处理就够了。

你只需要用大白话告诉它：「帮我建一个所有法定节假日的提醒。」或者：「以后我家人的农历生日，记得提前一天提醒我。」从这些最简单的生活提醒开始，让系统先动起来。因为只有当它先在生活里站住脚，后面你才会真的愿意继续往下折腾它。

入口

最后一步，是把它放进一个你每天都会经过的地方。

我现在越来越觉得，最大的问题根本不是 AI 不够多，而是 AI 太碎了。一个网页，一个 App，一个终端，一个插件，功能都很强，但都要求你主动过去找它。你必须记得「去打开它」，它才会存在。

可一旦一个带着记忆、带着浏览器能力、还能定时提醒的助手，被放进你每天会打开无数次的聊天软件里，事情就会完全不一样。

我自己用的是微信，但 OpenClaw 支持的远不止微信。国外用户可以接 Telegram、Slack、WhatsApp、Discord，国内除了微信，也可以接飞书、钉钉。具体接哪个其实没那么重要，重要的是这个动作本身：把 AI 助手放进你原本就已经在使用的 IM 里。

这一步的意义，不只是「更方便」而已。它真正改变的是使用关系。

它不再需要你专门进入某个「AI 场景」才能调用。它直接进入了你原本的生活流。你不用切换心智，不用额外打开一个新的工作台，也不用在脑子里提醒自己：「对了，我还有个 AI 可以用。」它就在联系人列表里，像一个一直待命的存在。

而且聊天软件本身的交互体验，是被打磨了很多年的。消息气泡、通知推送、输入提示、未读提醒……这些你平时和朋友聊天时早就习以为常的东西，一旦放到 AI 对话里，会让整个体验比任何专门的 AI App 都更自然。你不会感觉自己在「使用一个工具」，而更像是在「跟一个人说话」。这种感觉很微妙，但它直接决定了你到底会不会真的把这个助手用起来。

当所有对话都收束在同一个地方——不是在 ChatGPT 网页上聊几句，又跑去 Claude 问另一个问题，再去别的 App 查个东西——而是始终落在同一个聊天窗口里，你就会越来越不把它当成一个「AI 产品」，而开始把它当成一个助理。

这一步带来的体验变化，很多时候甚至比模型升级本身还大。因为绝大多数人真正缺的，不是一个更聪明的模型，而是一个更容易出现在自己生活里的入口。

所以，OpenClaw 适合所有人吗？

肯定不是。

如果你的核心诉求是高强度的生产力输出——比如写大段代码、做复杂架构、写长篇专业文章——那 OpenClaw 未必是最优解。这个时候，直接打开网页版 Claude，或者在终端里跑 Claude Code，效率往往会更高。没必要为了用 OpenClaw，而把它硬塞进一个本来就不适合它的生产力流程里。

但如果你想要的，不是一个「随叫随到的问答机器」，而是一个能慢慢融进生活里的数字分身，那 OpenClaw 的价值就会开始变得非常具体。

它不一定能替我写出最完美的系统架构，但它能记住我家里那辆新能源车什么时候该续保、出过几次险；它能带着登录态，去我常看的内容平台里抓我真正关心的资讯，再整理成一份简报；它能在节假日或者家人的生日那天，准时在聊天软件里给我发来一条没有太多机器味的提醒；最重要的是，它就待在我每天都要打开无数次的聊天软件里，随时待命，我不需要为了找它，再额外打开一个新的 App。

说到底，真正打动我的，并不是 OpenClaw 有多「强」，而是它开始有了「存在」的感觉。

给它一个足够强的大脑，给它眼睛和钥匙，给它记忆，给它定时器，再把它放进我每天都会经过的入口里。做到这一步之后，它就不再只是一个冷冰冰的开源项目。

它开始有点像一个真正属于我的助理了。

为什么 Vibe Coding 让我想起了《文明》的再来一回合

2026-02-22T16:00:00.000Z

凌晨三点，对 AI 说再加一个功能，就像对《文明》说再来一个回合——根本停不下来。

最近有个越来越强的感受：vibe coding 让我上瘾的方式，跟当年玩《文明》简直一回事。

而且不是有点像——我越想越觉得，这两个东西让人停不下来的底层机制几乎一模一样。

没玩过《文明》的话简单说一下。《文明》一款回合制的策略游戏，已经出到第七代了。玩法就是从石器时代开始，一个回合一个回合地发展文明——造城市、研究科技、训练军队、跟其他文明外交或开战，一路打到太空时代。每个回合做几个决定，点一下下一回合，几秒钟就过去了。听着没什么，但它被公认为最让人上瘾的游戏之一。我主要玩《文明 6》，经常晚上点进去看一眼时间，等出来之后发现天都亮了。

然后是 vibe coding。2025 年 2 月，Andrej Karpathy 发了条后来传疯了的推文，给一种新的编程方式起了个名字叫 vibe coding——"完全投入到氛围中，拥抱指数级增长，忘记代码的存在。"说白了就是：告诉 AI 想要啥，它帮写代码，也不怎么看代码本身，能跑就行。

一年过去，这个词从一个梗变成了一种现象。社交媒体上到处是开发者在说自己停不下来：连续通宵、API 账单炸了、GitHub 上堆满做到一半的项目。有人三天半在 AI 编程平台上烧了 600 多美元，预计一个月要花 8000，然后说我甚至不生气，我被套住了。有人在 Substack 上发文：救命，我老公对 AI coding 上瘾了。

我自己也没好到哪去。但不一样的是，我脑子里一直有个挥之不去的既视感——这感觉，我在《文明》里体验过啊。

仔细想了想，发现不只是感觉，是机制层面的一一对应。

再来一个 Prompt 和再来一个回合

玩过《文明》的人都知道那个著名的坑——再来一个回合（Just One More Turn）。计划十一点睡，抬头一看凌晨三点了。也没干啥大事，就是不断点下一回合，因为总有个惦记的东西快完成了：奇观还差两回合、军队马上到、科技快研究完了。

Sid Meier 自己说过这个设计："你总是在预测接下来会发生什么，以及八个回合以后会发生什么。"

Vibe coding 就是这样。提个需求，AI 几秒就生成代码，跑起来了，新的可能性出现了，于是输下一个需求。每个 prompt 就是一个回合，每个回合都在勾着人打下一个。

游戏设计里管这叫强迫循环（Compulsion Loop）——行动→奖励→扩展→行动。对照一下：

《文明》	Vibe Coding
点击下一回合	输入一个 prompt
看到城市成长、科技解锁	看到功能跑通、代码生成
产生新目标	产生新想法
再来一个回合	再来一个 prompt

有个开发者说得特别准："每次做完一个功能，我就说再来一个小东西。五分钟变成了五个小时。"连着三个月，每个月没到月底 AI 额度就烧光了。

不确定性才是最强的毒

光有循环还不够，《文明》里明知该睡了为什么还停不下来？因为下一回合的结果不完全能预测——不确定蛮族会不会来，对手会不会宣战，奇观会不会被抢建。

这种大概率好、但不确定具体会怎样的模式，就是老虎机的核心机制——不知道下一把赢不赢，所以一直拉。

Vibe coding 也是这个节奏。有时候 AI 一次就给出完美方案，有时候折腾十五轮，有时候它冒出一个想都没想过的精妙实现。代码好了！太棒了！又坏了！什么鬼！——这种忽好忽坏的体验，跟赌博是一回事。

还有个放大器：努力折扣。传统编程得花大量精力才有成就感，vibe coding 里打一句话就出来一整个功能。投入几乎为零，回报可能巨大——比传统编程上头多了。

然后是近失效应——赌场最爱用的心理机制。老虎机两个七对齐了，第三个差一格。大脑不会觉得这是输了，而是觉得差一点就赢了。

Vibe coding 里到处都是这个：代码几乎就对了，能跑但有 bug，逻辑对但语法错。从来不会让人觉得失败了，永远觉得再改一下就好。

我见过一个特别精准的描述：AI 五分钟就能搭出个像模像样的东西，但那一点点没搞对的地方，可能花比搭起来还长的时间去修。关键是人完全意识不到这一点，永远觉得马上就搞定了，就差最后一步。

这个感觉，跟《文明》里还差两个回合就造完奇观的心态完全一样。

迷雾和科技树

《文明》开局地图大部分被迷雾盖着，每探索一块就揭开一块——可能是新资源、自然奇观、或者敌对文明。每次揭开都是一次小型多巴胺释放。

Vibe coding 一样。不知道 AI 能做到什么程度，每次 prompt 都像派出一个侦察兵，结果经常超预期——等等，它居然真能做到这个？这种对能力边界的未知感，本身就让人上瘾。

《文明》的科技树也一样。研究完一个科技就看到下一层解锁了什么——更强兵种、更好建筑、更高效政策。总有下一个好东西在等着。

Vibe coding 的科技树就是不断发现的 AI 新能力。做完登录页，突然想加个支付应该也不难吧？做完支付，又想要不再加个数据看板？每做完一个功能，就是下一个功能的广告。

暗流：感觉在工作，其实在亏

到这里为止，vibe coding 的瘾跟《文明》几乎完全对得上。但有一个地方，vibe coding 比《文明》更危险。

玩《文明》的时候好歹知道自己在玩游戏，赌博的人至少隐约觉得自己在赌。但 vibe coding？是真心觉得自己在工作。

赌博成瘾研究里有个概念叫暗流（Dark Flow）。心流大家都知道，沉浸在有挑战的事情里，忘了时间，状态很好。但心流有另一面：沉浸在一种看起来有产出、感觉很充实，但实际上没带来真正价值的事情里——这就不是心流了，是暗流。

赌博研究里还有个经典发现：多线老虎机上投 20 分钱赢回 15 分，机器照样叮叮当当庆祝。大脑登记成赢了，但其实亏了。研究者管这叫伪装成赢的输。

Vibe coding 里对应的就是：几百行看着挺厉害的生成代码，里面藏着隐形 bug、安全漏洞、和没人刻意选择的架构决策。觉得干了好多活，但可能只是生产了一堆难以维护的东西。

这不是我瞎说，有个挺有意思的数据。METR 2025 年 7 月发了一项随机对照试验：16 位经验丰富的开源开发者在自己的仓库上完成了 246 个真实任务。用 AI 工具时，他们实际上慢了 19%。但实验前他们预测 AI 会让自己快 24%，实验后还是觉得自己快了 20%。

这个 19% 本身不用太当真——样本只有 16 个人，而且测的是资深开发者在自己熟悉的大项目上改 bug 加功能，这恰恰是老手本来就快、AI 反而容易添乱的场景。换成从零搭新项目，结论很可能完全不同。

但这个研究真正有价值的地方不在于快了还是慢了，而在于那个感知差距：哪怕在 AI 实际没帮上忙的场景里，人们还是坚信自己变快了。自我评估和实际表现之间差了近 40 个百分点。连最该从 AI 受益的资深开发者都会高估效果——普通人只会更严重。

当然这里我不是说这个研究证明 AI 一定会让人变慢，而是它证明一件事：主观效率感会系统性高估。

暗流就是这样——它不只让人低效，还让人坚信自己正在高效。

Flask 框架的作者 2026 年初写了篇博客，说得特别实在：朋友第一次让我用上 AI coding 之后，我不睡觉了。花了两个月疯狂 prompt，浪费 token。造了一大堆工具，大部分没怎么用。能做不等于该做，但我花了很久才意识到这一点。

他还说了段让我印象很深的话：当我看到有人凌晨三点同时跑着十来个并行 agent 会话，告诉我他们从未如此高效——在那个瞬间，我看到的不是生产力。我看到的是一个可能需要离开电脑一会儿的人。

蛮族入侵和项目坟场

《文明》有个经典惩罚：全身心搞经济、忽视军事，蛮族突然来了。前期越忽视防御，后期惩罚越重。

Vibe coding 的蛮族就是技术债。

AI 能飞快生成项目的前 80%——框架搭好、页面渲染、基本功能跑通。这些早期胜利就是制造上瘾的钩子。但剩下 20%——边界情况、安全审计、状态管理、跨模块一致性——才是项目真正死掉的地方。

这就带来了沉没成本陷阱：项目看着完成了 80%，继续提需求总比承认剩下的活需要完全不同的方法要容易。跟《文明》里不舍得推翻 200 回合帝国一个道理。

有人管这叫 Vibe Coding 坟场——堆满了前十二天很惊艳、第十三天就没法维护的废弃应用。甚至催生了一个专门拯救 vibe coding 烂摊子的生意叫 VibeCodeRescue.com。

还有个共通点：存档即放弃。《文明》很多存档存了就再没打开过，因为新开一局永远最爽。Vibe coding 也一样——GitHub 上堆满做到一半的项目。道理是一样的：从 0 到 80% 永远比从 80% 到 100% 有吸引力。

多人模式和错失恐惧

《文明》单人已经够上瘾了，多人模式还多一层压力：对手进了工业时代我还在中世纪，被甩开的恐惧让人更不敢停。

Vibe coding 的多人模式就是社交媒体上的炫耀文化。Y Combinator 说 2025 年冬季批次里 25% 的公司代码 95% 是 AI 生成的。到处都是人展示几小时内做出的产品。没写过代码的人突然发了有几千用户的应用。

这种错失恐惧从英文圈蔓延到中文圈。知乎上到处是程序员的身份焦虑。36 氪上的热文直接管 vibe coding 叫一场幻觉和焦虑催生的行业狂欢。开发者们造了代码屎山来形容 AI 代码库。有企业团队甚至在 AI 服务宕机时报告了戒断反应——不想手动写代码了。

这不就是《文明》多人模式里的焦虑，叠加上习惯了快节奏就回不去的依赖吗？

游戏设计概念	《文明》	Vibe Coding
强迫循环	行动→奖励→扩展→行动	提需求→代码→新想法→提需求
不确定奖励	不知道蛮族来不来	不知道 AI 能不能一把过
再来一回合	奇观还差两回合	bug 差一个就跑通
近失效应	差一回合被抢建	90% 对了，再改一下就好
暗流	三小时觉得只过了半小时	觉得超高效但自我评估严重偏离现实
迷雾探索	揭开地图发现新大陆	发现 AI 居然还能做这个
科技树	研究完看到下一层	做完一个功能想到下一个
沉没成本	200 回合不舍得推翻	几十个 prompt 不舍得放弃
存档即放弃	存了档再也不打开	项目做一半就开新的
多人压力	对手进工业时代	别人一天就发产品了

Sid Meier 说过："好游戏是一系列有趣的决策。"

Vibe coding 确实有无数决策——建什么、怎么 prompt、试哪个方案——每个都有即时反馈。但问题是并不真正理解 AI 做了什么权衡，只是看到结果就接受了。感觉在做选择，但不理解选择意味着什么。

跟《文明》最高难度一个道理：以为在做战略，其实只是在对 AI 对手的行为做本能反应。

最后

Vibe coding 厉害的地方在于，它同时叠满了所有主要的成瘾机制——不确定奖励、近失效应、进度系统、沉没成本、社交压力、心流状态——而且是在一个真心觉得自己在工作的场景里。

玩《文明》的人知道自己在玩游戏。赌场里的人至少隐约觉得自己在赌。但凌晨三点的 vibe coder，盯着十个并行 agent 会话，是真心实意觉得自己从未如此高效。

METR 那个实验里，资深开发者自己觉得快了 20%，实际慢了 19%。可以质疑那个慢了多少，但很难质疑这个感知偏差的存在。

这个差异才是最让人不安的。

有意思的是，Karpathy 自己做 Nanochat 这个项目时基本选择了手写代码——他试了几次 Claude 和 Codex 的 agent 模式后放弃了，说就是不够好用，最后只保留了最基础的自动补全。哪怕是 vibe coding 的命名者，碰到具体项目也会发现 agent 并不总是答案。

写这篇不是劝谁别 vibe coding。我自己也没戒，只是想说清楚手里拿的到底是什么——它不只是编程工具，它还是一台设计精巧的老虎机，只不过吐出来的不是硬币，是代码。

起码我得知道自己在赌。

做一个 AI Agent 没那么简单，也没那么玄

2025-10-25T16:00:00.000Z

上周 OpenAI 发布了 AgentKit 的时候，我正好在思考一些 Agent 设计上的问题。看到 Agent Builder、ChatKit 这些工具的发布，我第一时间想到的不是「又多了几个新工具」，而是回想起自己之前做过的一些实践，那些踩过的坑，以及逐渐摸索出的一些心得。

这些新工具的出现让我意识到，整个行业对 Agent 开发的理解正在发生转变，从早期的「给 LLM 加几个工具」，到现在开始系统性地思考上下文管理、工具设计、评估体系这些根本性问题。

如果半年前甚至现在问一个人说「怎么做一个 Agent」，这个人可能会说：很简单啊，给 LLM 定义几个工具函数，写好调用规范，让它自己决定什么时候用哪个工具就行了。但现在如果你问我同样的问题，我会先问你：你想让它做什么？在什么场景下用？对响应速度和准确性有什么要求？因为我发现，做一个 Agent 不只是一个技术问题，更是一个系统设计和产品决策的问题。每个决策背后都是权衡，而这些权衡需要深刻理解你要解决的实际问题。

先叠个甲：我谈的 Agent 是什么

在开始讨论之前，我想先明确一下，本文讨论的 Agent 到底是什么。因为我发现很多人对 Agent 有一些不切实际的期待，或者说是误解。

有些人在谈 Agent 的时候，想象的场景是：以后公司都不用雇人了，直接雇佣 Agent，想裁就裁，不用赔偿，不用交五险一金，完美！但老实说，这根本不是目前 Agent 要做的事情，目前也根本做不到。甚至我认为，在大语言模型这个技术架构下，可能也很难实现我们想象中的那种真正的、完全自主的人工智能。

那我们谈的 Agent 是什么呢？简单来说，就是一个能自主使用工具、完成特定任务的 AI 系统。它的核心特征是：给它一个目标，它可以自己规划步骤，调用各种工具（比如搜索、读取文件、调用 API），然后一步步完成任务。这听起来很强大，但请注意我说的是「特定任务」。

目前的 Agent 擅长的是什么？是那些边界相对清晰、可以分解为具体步骤的任务。比如：

搜索多个来源的信息并综合成一份研究报告

根据需求查询数据库、分析数据、生成可视化图表

读取代码库、定位 bug、生成修复方案

根据用户问题查询知识库、整理相关文档

这些任务有一个共同特点：它们是「工具密集型」的。Agent 的价值不是它有多聪明，而是它能够灵活地组合使用各种工具，完成需要多个步骤的复杂任务。人类做这些事情当然也可以，但是很耗时间。Agent 的价值是提高效率，而不是替代人的判断。

那 Agent 不擅长什么？几乎所有需要真正理解、创造、判断的工作。比如：

理解一个复杂业务场景的深层次需求

做出涉及多方利益权衡的战略决策

处理需要同理心和人际敏感度的沟通

在高度不确定的情况下做出创造性的突破

这不是说 Agent 完全不能辅助这些工作，但它无法替代人在这些场景中的核心作用。我做 Agent 这段时间最深的感受是：Agent 是一个很好的助手，但它不是一个员工。它能帮你快速完成很多琐碎的、重复的、需要大量信息处理的工作，让你有更多时间去思考、去做真正需要人类智慧的事情。

为什么我说大语言模型架构可能很难实现真正的人工智能？因为我个人还是觉得目前的 LLM 本质上是一个强大的模式识别生成器。它能从海量数据中学习到语言的模式、知识的模式、推理的模式，然后在新的场景中应用这些模式，但是这样的他也只是基于训练数据中的模式做出了看起来合理的回答。尽管在训练中，看到了人类专家终其一生都学不完的数据，但是它们能做的很多任务依然还远不如人类专家，所以我感觉它们在泛化能力上还有非常大的欠缺。（都是我个人看法）

这不是说 LLM 不强大，恰恰相反，它在很多任务上已经非常实用了。但我们需要清醒地认识到它的局限性，这样才能正确地使用它，做出合理的产品决策。

因此，我在这篇文章里谈的是如何构建一个能够自主完成特定任务、提高工作效率的 AI 工具。

上下文管理：核心问题

假设说做一个 Deep Research，让 AI 像人类研究员一样工作，它需要搜索多个来源，阅读大量文档，综合分析信息，最后生成一份有深度的研究报告。

想象一下这个场景：让 Agent 研究一个复杂话题，比如「中国金融科技的监管演进与未来趋势」

然后你点一下，哇撒，Agent 开始工作了，它搜索了十几个相关网页，读取了好长的文档，收集了大量的政策信息、市场数据和专家观点。这时候你会发现，所有这些信息都被塞进了 Agent 的上下文窗口中。起初这不是问题，但随着研究深入，上下文开始膨胀。很快就超出了模型的上下文，而这个时候研究还远远没有结束。

比如说你可能听说过「Lost in the Middle」这篇论文，它发现模型对上下文开头和结尾的内容关注度最高，而中间部分很容易被「遗忘」。不过需要说明的是，这篇论文是针对 GPT-3.5 Turbo 那个时代的模型做的测试，现在的旗舰模型在这方面已经好很多了，而且后续也有一些论文并未完全验证当初的结论。

但这不意味着上下文管理不重要了。在我看来，最大的问题其实不是所谓的「上下文腐败」，而是上下文不够用。理论上，现代大模型都有很大的上下文窗口，几十 K 甚至 1M tokens，但实际情况是，当你真正用到一些复杂的任务上，可以很轻松把上下文塞满时。

很多时候不是模型处理不了这么长的上下文，而是你的任务还没完成，上下文就满了。就像一个研究员的笔记本，问题不是他理解不了复杂内容，而是笔记本的页数有限，研究还没做完，笔记本就写满了。

那怎么办呢？我开始思考一个本质问题：Agent 到底需要记住多少东西？是所有的工具调用结果都要保留吗？还是可以选择性地遗忘一些？当我们做一个复杂研究时，我们通常不会想着自己搞定所有的事情，而是可以分派出去一些任务，后续只需要知道结论就行了。同时我们也不会记住每一个细节，而是会记住核心问题、关键发现等等，而具体的数据和细节则记在笔记里，需要时再翻看。

多智能体

你可以把它想象成一个研究团队的工作方式。团队里有一个项目负责人，他负责理解研究目标，制定研究计划，协调团队成员的工作。然后有几个研究员，每个人负责一个特定的子课题，他们独立工作，深入研究自己负责的那个方向。最后可能还有一个写作专家，负责把所有研究成果整合成一份连贯的报告。这样的分工有什么好处？

每个人的工作范围是明确的，他们不需要记住整个项目的所有细节，只需要专注于自己的那部分工作，这样效率会高得多，质量也更有保证。

这种多智能体的思路带来的核心改善是：每个智能体有自己独立的上下文窗口，它们之间通过明确的消息传递来协作。每个智能体在接收任务时，会得到一个清晰的目标描述和必要的上下文信息，而不是整个项目从头到尾的完整历史。这样可以避免单个上下文过度膨胀，同时每个智能体也能更专注于自己的工作。

这方面 Anthropic 分享的关于他们如何构建多智能体研究系统的文章很有启发。他们构建了 Claude Research 功能，采用的就是一个 Lead Researcher（主研究员）加多个 subagents（子智能体）的架构。Lead Researcher 负责理解查询、制定研究策略并将计划保存到 Memory 中，然后创建多个 subagents 并行搜索不同方面的信息。这种架构在他们的内部评估中，使用 Claude Opus 4 作为 lead agent 和 Claude Sonnet 4 作为 subagents 的多智能体系统，在研究任务上比单一的 Claude Opus 4 提升了 90.2% 的性能。

特别是对于需要广度优先搜索的任务，比如找出 S&P 500 信息技术板块所有公司的董事会成员这种需要同时探索多个独立方向的查询，多智能体系统能够通过并行处理大幅缩短研究时间。Anthropic 提到，他们发现 token 使用量本身就能解释 80% 的性能差异——多智能体系统通过让每个子任务有独立的上下文窗口，可以处理远超单个 200,000 token 限制的信息量。

当然，这种思路也有弊端。你需要设计好智能体之间的通信方式，决定什么信息需要传递，什么信息可以省略。有时候你会发现，某些上下文信息在多个智能体之间都需要，这时候你要判断是让它们共享这部分上下文，还是通过摘要的方式传递关键信息。

而且 Anthropic 的文章也说，多智能体系统会消耗大量 tokens——agents 使用的 tokens 是普通对话的 4 倍，而多智能体系统则是普通对话的 15 倍。这意味着如果你在简单任务上使用多智能体系统，会面临高昂的计算成本。这就需要根据具体场景来决定了。

压缩、摘要与检索：其他上下文管理策略

除了多智能体的思路，还有一些其他的上下文管理策略在实践中也很有用，比如说 https://youtu.be/6_BcCthVvb8 分享的压缩和摘要（又叫上下文卸载）。

想象你的 Agent 读取了一篇很长的文档，几万字的内容。如果把整篇文档都保留在上下文中，很快就会爆炸。但如果你让 Agent 读完后提取关键信息，生成一个摘要，那么后续就只需要保留这个摘要，而原文可以暂时存放到他处。这就像人类做笔记，我们不会把整本书都抄下来，而是记录关键观点和结论。

压缩和摘要不完全一样。

压缩是可逆的，比如在对话历史中将获取到的文章保存到硬盘里面，对话历史中里包含这篇文章的路径；

而摘要是不可逆的，提取文章的核心观点到对话历史中，这样虽然会丢掉很多细节，但是不需要额外进行硬盘上的管理。这两种方法各有适用场景。

然后是检索，当信息被卸载后，Agent 需要能按需检索相关内容，这里主要有两种方法：

语义搜索和索引：像很多之前 ChatXXX 工具一样，通过向量数据库进行语义匹配

文件系统和简单搜索工具（我称之为关键词检索）：像 Claude Code 使用的方法，依靠 grep、glob 等传统工具

分享的人说 Manus 选择后者，每个会话都是新的沙盒环境，没有时间建立索引。当然我觉得不仅仅是「没时间建索引」这么简单，主要还是没必要，这是任务本质决定了检索方式。

对检索方式的思考

这个话题值得展开讲讲，因为它涉及到一个很常见的误区。很多人一提到 AI 检索，就会想到向量检索、语义搜索、RAG 这些听起来很「AI」的技术。向量检索确实很强大，它能找到语义相似的内容，即使没有关键词匹配也能工作。但问题是，它真的适合所有场景吗？

在我做 AI 产品的相关实践中，发现当你在处理研究任务时，你要找的东西往往是精确的概念。比如你想找某个政策的具体内容，某个数据的来源，某个专家的观点，这些都有明确的名称或关键词。在这种场景下，关键词检索能精确找到所有相关位置，速度极快，几乎是毫秒级的，而且成本几乎为零。最重要的是，你清楚地知道为什么找到这些结果，因为它们包含你搜索的关键词。

相比之下，向量检索在这个场景反而是劣势，它需要先把所有内容转成向量，这本身就有成本，不管是时间成本还是 API 调用成本，然后做相似度计算，又是成本。最后可能返回一些「语义相似」但实际不相关的结果。比如你搜「普惠金融政策」，它可能返回包含「金融服务创新」的内容，因为语义相似，但这可能不是你要的，而且你很难解释为什么它返回了这些结果。

让我用一个更具体的例子来说明。假设你在研究一个复杂的市场话题，Agent 在过程中收集了几十份文档，包括政策文件、行业报告、新闻文章等等。1 个小时后，撰写到订阅制商业模式的时候，这时候用关键词直接搜索所有保存的文件中包含「订阅」或「subscription」的内容，几十毫秒就能精确定位，然后 Agent 可以快速回顾相关内容给出答案。

这比建立向量索引然后做语义搜索要快得多、准得多、便宜得多。

这不是说向量检索不好。它的价值在于处理模糊的、概念性的查询。比如在一个记忆系统中，用户说「我上次提到的那个关于投资的想法」，系统需要从数百条记忆中找出语义相关的那几条。这种模糊的查询，向量检索才有价值。或者在分类场景，判断一个用户反馈是属于「功能请求」还是「bug 报告」，这是典型的文本分类的应用。情感分析也是类似，把文本映射到情感空间中的某个位置。

所以我的结论是：检索方式的选择应该基于任务的本质。如果你的任务涉及明确的概念、术语、名称，那么关键词检索往往是最优选择。如果你的任务是模糊的情感识别、文本分类或模式识别，那么向量检索更合适。

现在很多 RAG 系统都在搞混合检索，先用关键词检索保证精确召回，然后用向量检索补充语义相关的内容，最后再重排序。这种架构的存在本身就说明，单纯的向量检索是有局限性的。

比如说 Claude Code 也选择了关键词检索而不是向量检索，它们处理的是代码，从用户的任务中通常就能知道要找什么函数、什么 API，关键词检索就能精确定位。代码场景对精准性要求很高，你需要找到特定函数的调用位置，特定变量的定义，这些都有明确的名称。

比如你搜 openDatabase，它可能返回包含 connectToStorage 的代码，因为语义相似，但这可能不是你要的。

同时还有一个容易被忽视的成本问题。关键词检索扫描几十万行代码只需要几十毫秒，完全在内存中操作，没有额外成本。而向量检索首先需要调用嵌入模型把代码库转成向量，假设用 OpenAI 的嵌入模型，几十个文件可能就要花费十几美元，然后存储在向量数据库中，又是基础设施成本，查询时要算相似度，还需要维护索引的更新。对于需要控制成本的产品来说，这些都是实实在在的开销。

工具设计：从基础到抽象的分层思考

Manus 分享了一个三层抽象的结构。

最底层是原子级函数，大约只保留 10 到 20 个最基础的操作，比如读写文件、执行 shell 命令等等，保持动作空间紧凑。这一层就像编程语言的基本语句，你不会频繁修改它们，因为它们是基础。

第二层是沙盒工具，将更多能力卸载到预安装的命令行工具中，智能体通过 shell 调用它们。这避免了函数调用空间的膨胀，而且工具可以像 Linux 命令一样被发现，比如使用 --help 参数来查看使用方法。这一层的巧妙之处在于，它利用了现有的工具生态，而不是试图在函数定义层面重新发明轮子。

第三层是包和 API，智能体可以编写 Python 脚本调用预授权的 API 或库。这对处理大量数据特别有效，因为计算在运行时完成，只返回摘要到上下文中，大大节省了 token 开销。而且这给了 Agent 最大的灵活性，它可以根据具体需求组合使用各种功能。

这种设计的优雅之处在于：从模型的角度看，三层都通过标准函数调用访问，保持了接口简单和缓存友好性。也就是说，对于模型来说，调用一个基础函数和调用一个高级功能没有区别，它们都是函数调用。这种统一的接口设计让系统更容易理解和使用。

Manus 的分享还提到了一个重要原则：「少构建，多理解」（Do less, understand more）。他们说 Manus 最大的进步来自简化和删除不必要的技巧，而不是增加更复杂的管理层。这个观点我深有体会。很多时候我们会觉得加一个新功能、加一个新工具能解决问题，但实际上可能让系统更复杂。真正的改进往往来自于删除冗余，简化流程。

比如他们提到早期版本使用 todo.md 文件做规划，结果浪费了三分之一的操作在更新待办列表上。后来他们用独立的规划智能体替代了这种方式，更简洁高效。这个例子很有启发性：有时候看起来「智能」的设计，实际上可能是不必要的开销。随着模型能力提升，很多之前的脚手架变得不必要了。

Agent 需要专门训练的模型吗？

这是一个经常被问到的问题：我们是不是应该为特定的 Agent 任务训练或微调一个专门的模型？这个问题很有意思，因为它涉及到对 Agent 本质的理解。

比如说 Deep Research 这样一个经典的 Agent 实践案例。OpenAI 推出了专用于 Deep Research 的模型，这是一个专门为研究任务优化的模型。但有趣的是，从实际使用效果来看，它目前的表现并不如最新的旗舰模型好。很多时候，我发现直接使用 GPT-5-Thinking 通过连续工具调用来完成研究任务，效果反而更好，响应也更灵活。这说明什么？说明为特定任务训练模型并不总是最优解。

另一个案例是阿里巴巴的 DeepResearch 项目。他们采取了一个系统化的训练路径，提出了一个四阶段的训练范式：先构建高质量的浏览数据，然后采样轨迹，接着用监督微调来实现冷启动，最后通过强化学习来提升泛化能力。他们基于 ReAct 框架实现了这个 web agent，在 GAIA 和 WebWalkerQA 这两个信息搜索基准上取得了不错的成绩。

它展示了如何系统地构建训练数据和设计训练流程。但有趣的是，论文中的对比实验显示，OpenAI 的 Deep Research 通过端到端强化学习训练取得了更高的分数。这说明端到端训练确实有潜力，但也揭示了一个关键问题：这种方法需要大量的计算资源、精心设计的训练数据和复杂的训练流程。对于大多数团队来说，这个门槛是相当高的。

更重要的是，WebDancer 论文还发现，那些基于原生强推理模型（比如 QwQ-32B）构建的 agentic 系统，在没有专门训练的情况下也能取得相当不错的效果。这让我思考一个问题：对于大多数实际应用场景，我们真的需要训练专门的模型吗？还是说，通过更好的系统设计、提示词工程和工作流优化，就能用现有的通用模型达到类似甚至更好的效果？

我个人倾向于后者。WebDancer 和 Deep Research 这类端到端训练的 Agent 代表了一个重要的研究方向，但对于实际应用来说，用好现有的通用模型往往是更实用的选择。除非你有充分的资源和明确的场景需求，否则通过优化系统设计、改进提示词、调整工作流来提升效果，通常是更经济、更灵活的路径。而且这种方式的迭代速度要快得多，你可以根据实际反馈快速调整，而不需要每次都重新训练模型。

我的看法是，对于大多数场景，用好现有的通用模型，加上合理的提示词工程和系统设计，往往比训练专门模型更实用。通用模型的优势在于它们的泛化能力和灵活性。当你用 GPT-5 或 Claude 4.5 Sonnet 这样的模型时，你可以通过调整提示词、改变工具配置、修改工作流来快速迭代。如果某个环节表现不好，你可以马上调整。而如果你训练了专门的模型，这种灵活性就大打折扣了。

当然，这不是说专门训练永远没有价值。如果你有非常明确的、高度重复的任务，有大量的标注数据，而且通用模型在这个任务上表现确实不够好，那么训练专门模型可能是值得的。而且这里有一个很重要但经常被忽视的考量：推理成本。

假设你的业务每天需要处理几百万次 Agent 调用，如果每次都用 GPT-5 或 Claude 4.5 Sonnet 这样的旗舰模型，推理成本会非常高。这时候如果你有能力训练一个更小但在你的特定业务领域更加专业的模型，推理成本的节省可能是相当可观的。

假设你做的是电商客服 Agent，主要处理订单查询、退换货、物流跟踪这些标准化的任务。一个 70B 参数的通用模型可能可以完全胜任，但如果你训练一个 7B 或者 13B 的领域专用模型，专门针对你的业务场景和知识库进行优化，它在这些特定任务上的表现可能不输大模型，但推理成本可能只有十分之一甚至更低。当你的日调用量是十万次、百万次的时候，这个成本差异就非常显著了。

但是但是，训练和维护专门模型有前期成本：数据标注、模型训练、持续优化、版本管理等等。但如果你的业务规模足够大，这些前期投入可以通过推理成本的持续节省来摊销。反过来说，如果你的业务还在早期，调用量不大，或者任务类型经常变化，那么前期投入可能永远收不回来。

还有一个考虑是响应速度。更小的模型通常推理速度更快，延迟更低。对于需要实时交互的场景，比如语音客服、即时聊天，这种速度优势可能比成本优势更重要。用户等待半秒和等待两秒，体验差异是巨大的。

但需要强调的是，这个选择高度依赖你的具体情况。你需要考虑你的业务规模有多大？任务的标准化程度如何？你有没有足够的训练数据和技术能力？模型需要多久更新一次？这些问题的答案会决定训练专门模型是不是一个明智的投资。

对于大多数 Agent 应用来说，我还是觉得先把通用模型用好。当你发现推理成本确实成为一个显著的瓶颈，或者你的任务足够标准化、业务规模足够大的时候，再考虑训练专门模型。这时候你已经有了充分的业务数据和清晰的需求理解，训练出来的模型会更有针对性，投资回报也更明确。

产品经理与 AI 原型

说到这里，我想谈谈 OpenAI AgentKit 里的 Agent Builder 和 ChatKit 这些工具。当我看到这些工具时，我的第一反应是：这对产品经理来说太重要了。但这个重要性不是说产品经理「也可以做技术活」了，而是因为 AI 产品，特别是基于 LLMs API 的套壳产品（0.0），有一个本质特点：你必须真正体验整个流程，才能理解它到底怎么工作的。

传统产品开发中，产品经理可以通过画原型图、写文档、描述流程来传达想法。你画一个登录页面，一个数据展示页，写清楚交互逻辑，开发照着实现就行。但 AI 产品不是这样的。当你在纸上画一个「AI 分析数据」的流程框时，你可能觉得很清楚：输入数据，AI 处理，输出结果。但实际上，AI 会怎么处理？它会先做什么，后做什么？遇到模糊指令会怎么反应？什么时候会调用哪个工具？中间会产生什么样的中间结果？这些都不是你在纸上能想清楚的。

这里有一个更深层的变化，关于产品设计流程本身。在传统产品开发中，流程通常是：先做用户研究，然后画交互设计稿，接着做视觉设计，最后才是开发实现。这个流程的前提是，我们能够预先设计好产品的行为。按钮点击后会发生什么，表单提交后显示什么，这些都是确定的、可预测的。

但在 AI 产品中，这个流程需要部分颠倒。你不能先画一套完整的交互设计稿，然后期望 AI 完全按照设计稿的预期来表现。因为 AI 的行为本身就是不确定的，它是产品体验的核心组成部分。你需要先搭建一个可运行的原型，让 AI 实际跑起来，观察它在不同输入下的表现，然后基于这些观察来设计交互。

让我用一个具体例子来说明。比如说，你想让 AI 帮用户做市场研究。在原型图上你可能画一个搜索框，一个结果展示区，看起来很简单。但实际上，AI 收到用户的研究需求后，它应该先分解任务还是直接搜索？搜索到的信息如何筛选和组织？什么时候生成中间报告？什么时候需要深入某个细节？这些决策点都会显著影响用户体验。

如果 AI 一上来就给用户展示十几条搜索结果，用户可能会觉得太乱；如果 AI 埋头研究十分钟才给反馈，用户可能会觉得太慢。更复杂的是，AI 实际分析时的步骤是动态的。有时候它需要三步，有时候需要十步。有时候它会先清洗数据，有时候会直接分析。有时候它发现信息不足需要向用户提问，有时候它可以直接给出结论。这些行为模式，你在画原型图的时候是预测不到的。如果你先定义了一个固定的交互流程，然后让 AI 去适配这个流程，结果往往是别扭的、不自然的。

正确的做法是什么呢？先搭建一个最简单的原型，让 AI 实际处理一些典型的研究任务。你会发现它有哪些常见的行为模式，它在什么情况下需要和用户交互，它产生的中间结果有什么特点，它容易在哪些环节卡住。基于这些真实的观察，你才能设计出符合 AI 实际行为特点的交互界面。这些问题，你只有真正搭建一个可以运行的流程，让 AI 实际执行一遍，才能发现。

这不是说交互设计不重要了，恰恰相反，交互设计在 AI 产品中更重要。但它的时机变了。你需要先让 AI 跑起来，理解它的行为特点，然后再设计如何把这些行为以最好的方式呈现给用户。这就像拍纪录片和拍故事片的区别。故事片是先写好剧本再拍摄，纪录片是先拍摄素材再剪辑成片。AI 产品的设计更像拍纪录片，你需要先观察「演员」（AI）的真实表现，然后再决定如何剪辑和呈现。

这不是在提倡技术至上，让产品经理都去学编程。而是说，AI 产品的特殊性要求产品经理必须有能力通过这些工具快速制作可运行的原型。你需要真听、真看、真感受 AI 是怎么工作的，而不是基于想象来设计产品。这和传统产品设计有本质区别。传统产品的行为是确定的，点击按钮会发生什么，填写表单会得到什么反馈，这些都是可以预先设计好的。但 AI 的行为有很大的不确定性，它的决策路径、中间步骤、最终输出都可能随着输入的细微变化而改变。

这就是为什么我认为 Agent Builder 和 ChatKit 这类工具非常重要（Dify、N8N 等等）。它们降低了制作可运行原型的门槛，让产品经理可以快速搭建一个实际的工作流，看看 AI 真正的表现如何。你可以在几个小时内迭代多个版本，每次都能实际体验效果，而不是花几天时间写文档，然后等开发实现了才发现不对。

而且，这不只是关于效率，更是关于理解。这种流程的改变对产品经理意味着什么？意味着你需要更早地参与到技术实现中，而不是等到「设计完成」再交给开发。你需要和 AI 一起工作一段时间，真正理解它的能力边界和行为特点。当你自己搭建过一个 Agent 流程，看着它一步步执行任务，你会对 AI 的能力边界有更清晰的认知。你会知道哪些任务 AI 能做得很好，哪些任务它会卡壳。你会知道什么样的提示词能让 AI 理解你的意图，什么样的提示词会让它困惑。这种第一手的认知，是读再多文档也换不来的。

我的建议是，如果你是产品经理，花一些时间学习使用这些工具。不是为了替代开发，而是为了更好地理解你设计的产品到底会怎么运行。这会显著提升你的产品判断力，让你在做决策时更有底气。

评估体系：不只看结果，更要看过程

解决了上下文管理和工具设计的问题后，第三个大挑战是评估。做过 AI 产品的人都会面临一个很现实的问题：怎么判断做得好不好？

OpenAI 在推 AgentKit 时特别强调了一个功能：追踪评分（Trace Grading）。我注意到这个功能的时候，第一反应是「终于有人重视这个了」。因为这正是我在实践中逐渐意识到的一个关键问题。我把这种评估方式称为「轨迹评估」——不只看最终结果，更要看 Agent 的完整执行过程。

OpenAI 提到的一个观点我很认同：传统评估只关注能不能做到，但对于复杂的 Agent 任务，更重要的是理解为什么做到或做不到，具体是哪个环节出了问题。想象一下，你有一个包含五个步骤的 Agent：搜索信息、分析数据、调用 API、生成报告、发送通知。传统的评估只会告诉你最终结果是否正确。但追踪评分会检查每一步的执行情况，告诉你具体是哪个环节出了问题。是搜索的关键词不对？还是分析数据时出现了逻辑错误？又或者是 API 调用失败了？这种细粒度的评估对改进 Agent 至关重要。

轨迹评估：理解 Agent 的思考过程

让我详细谈谈为什么轨迹评估这么重要。我记得有一次，让 AI 研究一个技术趋势。它给出的结论看起来很合理，数据也有引用，参考文献列得很全。如果我只看最终报告，可能觉得还不错，可以交差了。但当我仔细看它的执行过程时，我发现了一个严重的问题：它其实只搜索了两三个来源，然后就匆忙下结论了。

这就像一个学生交作业，论文写得漂漂亮亮，格式也规范，但仔细一看发现他只查了两本书，其他全是自己编的。这份作业的质量显然是不够的，但如果老师只看最终论文，可能还会给个不错的分数。这个经历让我意识到，评估 Agent 不能只看结果，还要看过程。就像评价一个学生，你不能只看他的答案对不对，还要看他是怎么得出这个答案的，他的推理过程是否严密，他的研究方法是否合理。

轨迹评估就是关注 Agent 的完整执行过程。我开始记录和分析 Agent 的每一步：它搜索了哪些关键词？访问了哪些来源？在每个来源上花了多长时间？它是如何组织信息的？什么时候做出了关键决策？通过分析这些轨迹，我才能真正理解 Agent 的工作质量。

让我用一个更具体的例子来说明轨迹评估的价值。假设你问 Agent 一个问题：「中国金融未来的发展趋势，未来哪一个细分领域（例如投行、PE、固收等）更有上升空间？」这是一个复杂的研究问题，涉及多个维度。

首先，Agent 需要意识到这个问题本身就有歧义。「上升空间」是指什么？是指市场规模的增长潜力？还是从业者的职业发展机会？又或者是投资回报率的提升？不同的理解会导致完全不同的研究方向。一个聪明的 Agent 应该在开始深入研究前，先向用户发起问题澄清或者合理推断这个核心概念。通过轨迹评估，你可以看到 Agent 是否考虑了这个问题，它是如何处理这种歧义的。

当 Agent 开始搜索时，它很快会遇到第一个挑战：信息的时效性问题。如果找到一篇 2023 年的报告说「科技投行业务增长迅猛」，它需要判断这个趋势在 2025 年是否依然有效。中国金融市场变化很快，政策环境、市场情绪、国际关系都可能在短期内发生重大转变。Agent 必须学会优先使用最新的数据，同时又不能完全忽视历史趋势。通过轨迹评估，你可以看到 Agent 搜索的时间分布，它是否关注了信息的时效性。

更棘手的是，Agent 很可能会发现不同来源给出的答案相互矛盾。有的报告说 PE 市场前景广阔，有的说监管收紧会限制发展。有的专家看好固收业务，有的认为投行更有机会。面对这些冲突，Agent 不能简单地选择相信其中一个，它必须自行评估和理解这些观点背后的逻辑。通过轨迹评估，你可以看到 Agent 是否意识到了这些矛盾，它是如何处理的，是简单地罗列不同观点，还是做了深入的分析和综合。

在研究过程中，Agent 可能还会遇到意外的发现，而这些发现可能需要调整研究方向。比如它可能发现，中国正在大力发展绿色金融，这可能是一个重要的趋势，但最初的问题没有明确提到。一个好的 Agent 应该能够灵活调整，将这个新发现纳入研究范围。通过轨迹评估，你可以看到 Agent 的研究路径是否灵活，它是否能够根据新信息调整策略。

在某个时刻，Agent 可能会意识到，它需要找到一个分析框架。它不能简单地罗列每个领域的情况，而是需要建立一个系统的评估标准。也许应该从监管政策的方向来看？中国金融监管在收紧还是放松，哪些业务受到鼓励，哪些受到限制？或者从市场需求的角度？中国经济转型需要什么样的金融服务，哪种业态最匹配这个需求？又或者从国际比较的视角？成熟市场的金融结构能给中国提供什么启示？每选择一个框架，研究的路径就会大不相同。通过轨迹评估，你可以看到 Agent 是否建立了分析框架，这个框架是否合理。

你看，如果采用传统的静态评估方式，我们只会检查 Agent 最终给出的答案，这个答案可能是对的，但我们完全看不到它是如何得出这个结论的。它是经过深思熟虑权衡多个因素后的判断，还是只是简单地摘取了第一个看到的观点？它考虑了不同的分析框架吗？它处理了相互矛盾的信息吗？它意识到问题的复杂性和不确定性了吗？这些问题，只有通过轨迹评估才能回答。

多维度评估体系：Manus 的经验

Manus 的团队分享他们的评估体系：他们一开始使用的是像 GAIA 这样的学术基准测试，但发现在这些基准上得高分的模型，用户在实际使用 Manus 时反而不喜欢。他们用「super misaligned」（严重不匹配）这个词来形容这种情况。

问题在哪里呢？学术基准通常关注的是「能不能做到」，比如能否正确回答一个需要五步推理的问题。但真实用户关心的还包括很多其他维度，比如 Agent 的响应速度够不够快，它的解释够不够清楚，它生成的代码风格是否符合用户习惯，它创建的可视化图表是否美观易读，它在遇到模糊指令时能否聪明地理解用户意图。学术基准中的任务往往有标准答案，你可以用准确率来衡量。但很多真实任务是开放式的，没有唯一正确答案。

所以 Manus 团队建立了一个三层评估体系。最核心的一层是用户评分系统，每当一个任务完成，他们会请求用户给出评价，这是「金标准」，因为它直接反映了用户的真实满意度。第二层是内部的自动化测试，但他们不再依赖公开的学术基准，而是创建了自己的数据集，这些数据集有清晰的、可验证的答案，特别强调要测试「执行性任务」而不是「推理性任务」，因为 Agent 的价值不只是思考，更重要的是行动。第三层是大量的人工评估，因为有些东西本质上就是主观的，无法用算法来判断，比如网站生成和数据可视化的美观性。

这其实说明评估 Agent 需要多个维度的综合考量，既要有客观的指标，也要有主观的判断；既要看最终结果，也要看执行过程；既要有自动化测试，也要有人工评估。没有一个单一的指标能完全衡量 Agent 的质量。

一些实践原则

第一个是简单往往更好。我发现很多时候，简化系统反而能带来更好的效果。比如我曾经尝试过让 Agent 自己做很详细的任务规划，列出每一步要做什么，预期结果是什么。听起来很完美对吧？但实际上这个规划过程本身就消耗了大量的 tokens 和时间，而且规划往往跟不上变化。后来我简化了这个过程，只让 Agent 确定大的方向，具体步骤则在后续执行过程中动态决定。结果反而差不多，但是 tokens 消耗大幅度降低了。不要限制 AI 的能力，而是给它更清晰的方向，让它把精力花在真正重要的事情上。

第二个是持续跟踪很关键。我会记录每次任务的执行时间、token 消耗、调用了哪些工具、产生了什么结果。这样能发现很多隐藏的问题，比如某个工具调用消耗很差，非常不适合 AI 使用，需要整体进行调整。又比如我发现某类任务的效果也特别差，我开始逐步分析 AI 的轨迹，甚至逐步阅读它们的思考内容，才发现是提示词设计有问题，有一大块内容 AI 理解有歧义。

第三个是理解场景比掌握技术更重要，技术选择都是为场景服务的，比如说前文提到的检索，在不同场景下最优方案可能完全不同。只有深刻理解用户要做什么，你才能做出正确的设计决策。不要被技术的炫酷所迷惑，始终问自己：这个技术真的适合我的场景吗？

第四个是避免过度工程，这是 Manus 团队那里分享的。他们说最大的进步来自简化和删除不必要的技巧，而不是增加更复杂的管理层。确实，有时候你会觉得加一个新功能、加一个新监控、加一个新优化能解决问题，但实际上可能让系统更复杂，维护成本更高。

真正的改进往往来自于删除冗余，简化架构和流程。随着模型能力不断提升，很多之前看起来必要的辅助做法，实际上已经不需要了，要敢于删除，敢于简化。

一些思考和展望

怎么做一个好的 AI Agent 这不是一个技术问题，它涉及到系统设计、产品思维、用户体验等多个维度。当你需要管理复杂的上下文，设计合理的工具接口，建立有效的评估体系时，你会发现每个决策都是一个权衡的过程。没有完美的方案，只有适合特定场景的方案。

OpenAI 发布 AgentKit，Anthropic 分享自己基于 Multi Agents 的 Research 经验，Manus 的 Agent 构建经验，这些都说明整个行业正在从「能不能做」转向「怎么做得更好」。

总体来说，

上下文管理的重要性怎么强调都不为过。我在实践中深刻体会到，这不是一个可以事后优化的问题，而是从一开始就要认真考虑的核心设计。你采用什么样的架构思路，如何组织信息流，选择什么样的检索方式，这些决策会深刻影响系统的性能和可扩展性。

工具设计也是如此，在满足需求的情况下，给予最大的灵活性，非常重要。同时工具本身的输出质量也是重中之重。

评估体系的建立需要时间和耐心，不要期望一开始就有完美的评估方案，而是要在实践中不断调整。轨迹评估是一个很有价值的补充，它让我们不只关注结果，也关注过程。这对理解 Agent 的行为和改进系统至关重要。

产品经理对 AI 产品的参与方式也在发生变化。不是说产品经理要变成工程师，而是说他们需要有能力快速制作可运行的原型，真正体验 AI 的行为。Dify、N8N、Agent Builder 这类工具降低了这个门槛，让产品经理可以更深入地参与到产品设计中，这是一个积极的趋势。

随着模型能力不断提升，很多今天看起来复杂的问题可能会变得简单。我们现在花大力气解决的上下文管理问题，也许未来的模型能更好地处理。但我相信，深刻理解用户需求，做出合理的设计权衡，持续优化，这些核心能力会一直重要。技术在变，但好产品的本质不会变。

上下文工程：一直都存在，只是没有这么叫

2025-06-23T16:00:00.000Z

最近上下文工程（Context Engineering）成了某些人用来营销的新名词，用各种观点和文章来说明这个「新」东西的重要性，我觉得有些好笑。

我们从一开始构建 AI 应用就在做上下文工程——怎么获取更完整的上下文，上下文怎么拼接到提示词中，这些工作从使用 GPT 3.5 Turbo 就开始了，所谓的「上下文工程」，更像是对既有实践的重新包装和理论化。

提示词不重要，上下文才是王道

LangChain 将上下文工程定义为「构建动态系统，以正确的格式提供正确的信息和工具」，同时提到「很多人专注于巧妙地措辞提示来诱导更好的答案，但随着应用变得更加复杂，向 AI 提供完整和结构化的上下文远比任何魔法措辞更重要」（非常对）

现实中，有太多人花费大量时间调试提示词的措辞，试图找到那个什么所谓道，语言的本质。

完全南辕北辙，鸡同鸭讲，就像你和一个专家交流时，用词技巧远不如你提供的背景信息重要，专家需要的是完整的问题背景，而不是花哨的修辞手法，所谓的提示词工程也就是上下文工程。

完整上下文 > 一切提示词

AI Coding 应该是 AI 最火热的赛道，没有之一。

其中出现了不少的玩家，例如 Cursor、GitHub Copilot Agent、Cline、Claude Code 等，这些产品在处理上下文的策略上却截然不同。

Cursor 和 GitHub Copilot Agent 使用 RAG 和向量检索来分析代码库，将代码库分块并嵌入，试图通过语义搜索来选择「相关」的代码片段填充上下文窗口。

而 Cline 和 Claude Code 则选择了另一条路：给 AI 更完整的问题背景，让 AI 自行规划、发现和跟踪代码关系。

从我个人的使用体验来看，后者的效果要好得多，解决一些复杂的横跨非常多模块的问题成功率或定位成功率会更高。

Cline 的博客文章《为什么 Cline 不索引你的代码库》说得很透彻：当你将代码分块用于嵌入时，你实际上是在撕裂它的逻辑，想象一下试图通过听随机的 10 秒片段来理解交响乐——这就是 RAG 对代码库做的事情。

我自己曾经在一些项目中也做过一个对比实验，测试不同 RAG 策略的效果：

纯向量 RAG：用例通过率只有 12%

向量+关键词查询混合检索：能达到 60%+

让 AI 生成摘要，摘要 + 文本向量 + 混合检索：能达到 81%

数据很说明问题，纯向量检索根本不 work，它破坏了信息的内在逻辑关系，而要保持语义关系又需要过于复杂的内在工程，而且就算做了过于复杂的内在工程，也未必能达到真正的生产可用。

因此我发现只有当 LLMs 能看到完整的上下文时，才能真正理解问题的本质，这也是为什么我认为完全基于向量的 RAG 是不成立的，没有任何实际意义。

被忽视的聊天历史管理

有一个容易被忽略但极其重要的点：聊天历史也是上下文，而且是最重要的上下文之一。

构建 AI 应用本质上就是在聊天——你一句我一句的对话过程，即使是那些看起来「一键AI生成」的应用，背后也需要精心构建聊天历史，此时上下文如何管理和处理变得极其关键。

每次交互都在构建和累积上下文：用户的历史偏好、之前的决策、对话的演进轨迹——这些都是 AI 理解当前问题不可或缺的背景。

但现在大多数讨论「上下文工程」的文章都把焦点放在如何从外部数据源获取信息，却忽略了对话历史本身就是最宝贵的上下文来源。

这也有点本末倒置了。

模型上下文有限，才有了「工程」

说白了，如果模型的上下文窗口是无限的，根本不需要什么「上下文工程」，直接把所有相关信息都塞进去得了。

正是因为模型的上下文有限制，我们才需要思考：什么时候放什么样的上下文到提示词中？如何构建和管理模型的聊天历史？哪些信息是当前任务最关键的？

这才是上下文工程的核心：在有限的窗口内，确保 AI 获得最有用、最完整、最有序的信息。

我知道很多产品选择 Cursor 这样的方案，很大程度上是为了控制成本，向量检索确实能减少 tokens 消耗，降低费用。

但我们依然需要明白：如果你的目标是最佳效果，那么完整上下文就是王道，因此就算你避免不了分片，那么也尽可能保持语义最大完整性，用来达到尽可能好的效果。

重要的还是这个意识，因为我才发现很多人还是以为搞 AI 应用，就是要什么文本切分、转成向量、检索这一套才算是搞了开发，不是套壳，而且觉得这一套会比全部丢上下文里更加准确，回答质量会更佳。。。

回到本质

「上下文工程」这个词可能是新的，但它描述的实践一点都不新，从我们开始构建第一个 AI 应用时，就在思考如何给模型提供最正确的信息。

真正重要的不是这个概念的包装，而是对核心问题的理解：在当前业务场景下，AI 需要什么样的信息才能有效工作？我们如何在技术限制下提供这些信息？

在这个基础认知上，无论是调用外部 API、检索历史数据、还是管理对话状态，都只是具体的实现手段。

AI 产品的未来：评估驱动的时代

2025-05-29T16:00:00.000Z

最近有个现象很有意思：大家都在谈论 AI Agent，好像这是什么全新的概念。但实际上，任何稍微复杂一点的 AI 产品，背后都不是单个模型的简单调用，而是多个环节串联的复杂流程，可能存在 AI 的自主调用、连续调用，也有可能是各种不同的预置流程（有些人会觉得应该分为 Agent 和 Workflow 两种方式）。

问题来了：当你的产品不再是一问一答的简单交互，而是需要经过多个步骤才能给出结果时，你怎么知道它到底做得好不好？

这个问题比你想象的更致命。

评估：新时代的核心竞争力

让我直说：评估能力将决定 AI 产品的生死。

为什么？因为评估浓缩了业务的精华和流程的根本，能够设计出好的评估体系，本质上说明你深度理解了业务逻辑、用户需求和价值创造过程，这不是什么技术指标，这是需求理解的直接体现。

拿 Mapify 举例，这款产品看起来很简单——把任何内容变成思维导图，用户只需要丢个链接或上传个文件，几秒钟就能得到一张漂亮的思维导图。

但这个"看起来简单"的背后，其实有无数个决策需要做：用户上传了一个 PDF，要不要提取文字？还是先识别图表？YouTube 视频是分析字幕还是音频？不同类型的内容需要不同的处理方式。同时，看起来简单实际上复杂的还有，迭代导图、添加更多想法以至于聊天时可能触发的某些功能，每个功能背后可能都是完全不同的驱动形式。

关键问题来了：

你怎么知道这些流程哪个效果好，哪个效果差？

怎么衡量这些不同流程的有效性？

怎么定义和理解同一类型但细节不同带来的差异？

对比的标准到底是什么？

这些都需要深度的业务理解才能回答。市面上那些通用基准测试？只能作为参考。真正有价值的评估，必须来自对具体业务场景的深刻洞察。

从确定性到概率性的范式转换

这里有一个根本性的变化，很多人说是理解了，但实际上在做产品的方式上还没意识到：以前我们写代码，if-else 的逻辑，结果是确定的。现在用 LLM，同样的输入可能产生不同的输出。

这种从确定性到概率性的转换，会彻底改变产品开发的流程。过去，你知道代码逻辑正确，系统就正确。现在，你必须通过系统性地评估才能知道系统的真实表现。

更有意思的是，随着新模型发布频率越来越高，持续跟进最新进展变得至关重要——因为模型能力边界在快速变化，如果不及时测试新模型，可能会错过成本更低、效果更好的替代方案。

但真的如此吗？你有根据你的业务系统性地实测过吗？还是简单发一两个问题聊聊看？比如说我就发现在某些提炼摘要、指令遵循的场景，思考模型可能表现还不如非思考模型，按常理说，能够进行推理的模型应该在所有任务上都表现更好，这也是业界的普遍预期。

但在需要忠实提炼总结的场景下，思考模型有时候反而不如非思考模型。为什么？因为它们"想得太多"了。比如一个用例是在处理一篇关于 Apple TV 剧集 Sunny 的评论文章时，思考模型容易遗漏或捏造关键信息，多处与原文不符，出现了大量原文中并不存在的概念和分析。

这种"过度思考"导致的偏离在一篇论文中也得到了证实——DeepSeek R1 在大多数机器翻译和文本总结评估任务上表现不如一些非推理模型（当然我上面的用例测试的并不是 DeepSeek R1）。

这进一步说明了业务导向评估的重要性，我们需要根据具体任务调整评估策略——有些场景需要忠实性，有些场景需要创造性。

同时，在复杂的 Agent 流程中，不是所有环节都需要用最强的模型，关键是知道什么时候用什么模型来控制成本。

这不是技术细节，这是思维模式的根本转变。

评估的进化能力

有一个容易被忽略但极其重要的维度：评估体系本身需要具备学习和适应能力。

AI 系统在动态环境中运行，用户行为、业务场景都在变化。今天有效的评估标准，三个月后可能就过时了。所以评估体系不能是静态的规则集合，而必须是能够自我迭代的智能系统。

这意味着什么？意味着你的评估框架需要能够识别新出现的用户模式，发现原有指标的失效信号，自动调整权重和标准，甚至提出新的评估维度。

在 Mapify 的实践中，不同使用场景下用户对"好的思维导图"的定义在不断演化，需求也会发生变化。某些场景下用户更关注知识结构的完整性，而某些场景下则更看重创意的激发效果。

这种动态性要求 AI 产品团队必须具备更深层次的能力——不仅要知道怎么评估，还要知道什么时候需要改变评估方式，这可能是未来工作上最重要的差异化能力之一。

评估驱动的持续进化

未来，随着模型能力的提升，我们可以通过对业务和流程的深度理解，用评估数据来驱动模型的强化训练和优化（开个脑洞）。

这将形成一个正向循环：更好的评估 → 更精准的模型选择和优化 → 更优的模型表现 → 更丰富的评估数据 → 更深入的业务理解。这不是技术问题，这是商业模式问题。谁能建立这样的循环，谁就能在竞争中立于不败之地。

在这个过程中，经过训练的小模型和大模型的分工协作会越来越清晰。经过训练的小模型处理标准化、高频任务，大模型处理复杂推理、创新任务，通过智能编排系统实现最优配置。而这一切的基础，都是精确的、能够自我进化的评估体系。

结语

说到底，不管你叫自己 AI Agent、ChatBot 还是 Workflow 都不重要。用户根本不关心这些技术概念，他们也不知道什么是"AI Agent 产品"。

用户只关心一件事：你的产品到底好不好用？

这个"好不好用"怎么衡量？怎么持续改进？怎么确保下次更新不会让体验变差？答案就是评估能力。

从 Mapify 这样"简单"产品的复杂实践中可以看出，评估能力将成为 AI 产品时代最稀缺的核心竞争力之一。它不是一个技术问题，而是对业务本质的深度理解，以及让这种理解能够持续进化的能力。

概念会过时，技术会迭代，但对解决问题的追求是永恒的。

AI 应用的上下文窗口管理

2025-05-04T16:00:00.000Z

上下文窗口的本质及其局限性

大模型的记忆机制

想象一下，你正在和一个记忆力有限的朋友聊天，当你们的对话持续几个小时后，这位朋友只能记得最近说的几句话和最开始的几句话，而中间讨论的大量内容则被模糊甚至遗忘了。

这就是当今大型语言模型的工作方式，而最开始的几句话通常是 System Instruction，最近说的几句话就是你新发给大模型的内容。

所谓"上下文窗口"，本质上就是 LLMs 能够"记住"并处理的文本量，通常以"令牌" (token) 为单位计量。对英文来说，一个 token 大约是 4 个字符或 1 个单词；对中文则大约是一个汉字。这个窗口就像模型的短期工作记忆，决定了它在任何时刻能回顾和利用多少之前的信息。

上下文窗口大战

近年来，各大模型提供商不断在"上下文窗口大小"上打广告战，从 GPT-4 的 128K，Claude 3 的200K，到谷歌 Gemini 号称的 1M 甚至 10M。

这里也存在一个公开的秘密：标称的上下文长度与模型能有效利用的上下文之间存在显著差距。

Perplexity

在之前很长一段时间 Perplexity 曾被认为是确定长度外推上限的主要指标，但后续的研究发现困惑度并不能真正反映大型语言模型在长上下文下游任务中的实际表现，下游任务可能包括问答（QA）、摘要（Summ.）、信息检索（Retrieval）等，一个模型可能在困惑度上表现良好=能较好地预测长文本中的下一个词，但这并不意味着它能有效地理解长文本中的关键信息，回答复杂问题，或者生成高质量的长篇文本摘要。

简单来说应该说，预测下一个词做得好 ≠ 真正理解长文本，在实际应用中，模型可能擅长接着写，但在回答问题、提取关键信息或总结长文本时表现不佳。这就像是背诵和理解的区别，一个人可以很好地背诵课文（预测下一个词），但不一定真正理解课文内容（回答问题、做摘要啥的）。

Lost in the Middle

Lost in the Middle: How Language Models Use Long Contexts 提到：

原则上，大型语言模型在理论上具有全局注意力可以利用整个对话历史或文档上下文而不会遗忘。然而，在实际应用中，LLM 表现出强烈的位置偏置，偏向于输入中的某些部分而忽视其他部分。

实证研究表明，LLM 有时对最近的 token 和有时对上下文的起始部分关注较多，而对中间部分关注较少，这也被叫做首因效应 (primacy bias) 和近因效应 (recency bias) 。

其中提到了一条 U 型性能曲线：当相关信息位于长输入的开头或结尾时，模型回答效果最佳，但如果所需信息被埋在中间，性能则大幅下降

而后来也有 ∞ Bench: Extending Long Context Evaluation Beyond 100K Tokens 说并没有发现答案位于上下文中心位置时 LLMs 的准确度会下降：

当然，这篇论文的结论仍然是认为 “尽管当前 LLMs 声称擅长处理如此广泛的上下文，但在实际应用中，它们表现出显著的性能下降”

Fiction.LiveBench

另外也还有 Fiction.LiveBench，这个会更加有名一些，这主要是他们有一套内部的评估机制，同时还会及时测试最新的模型。

简单来说，Fiction.liveBench 就像是一个专门测试AI阅读理解能力的考试，特别关注AI是否能真正理解长篇故事的内容，记住所有重要角色和事件，并能回答需要深度思考的问题。而目前在他们的测试中也只有 OpenAI o3 做到了大部分上下文窗口下能达到 100 分。

上下文管理的方法

在现实应用中，当 AI 助手"忘记"用户之前提到的关键需求或限制条件时，用户体验和信任度会大幅降低。

例如，一个客服聊天机器人在长对话中忘记了用户明确表示的关键信息，或者一个法律文档分析工具遗漏了合同中间的关键条款，都可能导致非常不好的用户体验问题。

在上下文管理的产品设计方法论中，有两个最重要的方向：全上下文 (Full Context) 和 RAG (即检索增强)。

全上下文方法相对直接：将所有历史内容都塞进模型的上下文窗口中，让模型自行判断哪些信息重要。

这就像给一个学生完整的教科书，而不是精简的笔记。这种方法的好处是不会丢失任何潜在相关的信息，理论上可以获得最佳答案质量。

然而，它的代价也很明显：处理时间长、API 调用成本高，而且当对话历史超出上下文窗口时就完全失效了。

而 RAG 则像是给学生提供有针对性的笔记和参考资料，而非整本教科书；按照我个人的定义，RAG 主要是用各种方式找到相对较短但最相关的内容，只有这些内容才会塞进模型的上下文窗口中——检索合适的内容和使用尽可能少地上下文。

它有多种实现形式：文本分块会将长文本切成小段，每次只检索最相关的片段；摘要化会压缩大量信息为精炼摘要；滑动窗口则保留最近的一部分内容，扔掉更早的部分；还有重排序技术，调整文本在上下文中的位置，将重要内容放在不易被"遗忘"的位置。

实际应用中，RAG 并非单一技术，而是一系列方法的总称，不同 RAG 方案的效果可能天差地别。例如，简单地保留最近 n 条消息的方法，与智能提取关键事实并整合为结构化记忆的方法，在效果上会有显著差异。

这两种方法各有适用场景：全上下文适合对准确性要求极高且对话长度有限的情况；而 RAG 方法则更适合需要处理超长对话或对响应速度和成本敏感的场景。

在实际产品设计中，选择哪种方法不是非此即彼的决定，而是需要基于具体需求的权衡。

Mem0 的研究案例

2025 年 4 月，Mem0 发布了Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory对比了全上下文方法与他们提出的记忆管理系统。

它们创建了一个动态提取、整合和检索对话中重要信息的系统。简单来说，这个系统会在你和 AI 聊天时，自动提取重要的事实和信息（比如你提到的偏好、经历等），将这些信息存储起来，并在需要时检索相关信息：

先看看背景：

看看最近的十条消息（"刚才说到哪里了？"）
回顾最近十条消息之前的聊天摘要（它不记忆一定数量内的消息，只会存储摘要）

然后再提取重点：

AI 会思考："在这段新对话中，有什么值得记住的信息？"比如你说"我喜欢意大利菜，但对奶制品过敏"，AI 会把这两点作为重要信息提取出来

最后再整理笔记（记忆）：

检查是否与已有笔记冲突（如果你之前说过喜欢奶酪，现在说对奶制品过敏，系统会更新这个信息）
决定是添加新笔记、更新旧笔记还是删除错误信息

他们的结果表面，准确性方面，全上下文方法略胜一筹，达到了约 73% 的 LLM-as-a-Judge 评分，而 Mem0 系统则达到约 67-68%。

当然这并不代表 Mem0 的 RAG 没有用，它最大的优点是响应时间和成本，响应时间减少了85-91%，token 消耗也大幅降低。

更有趣的是，在不同类型的问题上，这两种方法的表现差异各不相同。对于需要时间推理的问题（例如"上个月我们讨论的那个项目现在进展如何？"），Mem0 的图结构增强版本甚至超过了全上下文方法。

不过上述 Mem0 论文中使用的模型只是 GPT 4o mini，而新发的 GPT 4.1 mini 根据 OpenAI 自己的文章，在长上下文的评估中均全面超越了大部分过往的模型。

但是我觉得这项研究也带来了一些启示：没有一种万能的上下文管理方法。选择全上下文还是基于 RAG 理念的各种系统，都应该基于具体的应用场景、用户需求和资源限制。

在某些对准确性要求极高的场景，牺牲一些速度和成本换取最高准确率可能是合理的（全上下文）；而在大规模部署、用户对响应速度敏感或资源有限的情况下，选择基于 RAG 理念的各种系统（比如说 Mem0 这样的记忆系统）可能是更明智的决定。

面向用户决策的上下文管理策略

上面的论文们为我们提供了一定的“事实基础”，但具体到产品决策，还需要更细致的策略。实际上，上下文管理策略的选择应该基于多维度的考量，而非简单的二选一。

对于面向专业用户的高风险领域产品，如法律文档分析、医疗诊断辅助或金融建议，准确性通常是首要考量。在这些场景中，即使付出较高的计算成本和稍长的响应时间，全上下文方法可能仍是更佳选择，同时还可以结合基于 RAG 和 Multi Agent 的重复检查。毕竟，在这些领域，一个错误的建议或遗漏的关键信息都可能导致严重的后果。

相反，对于面向 C 端用户的产品、需要处理大量并发请求的应用、移动端应用或对成本特别敏感的场景，RAG 一类的方法的优势则更为突出。想象一个客服聊天机器人需要同时服务数千用户，响应速度和计算成本可能会比极致的准确性更重要（当然这里存在一条可用性的门槛，必须要迈过那条可用性的门槛才能进一步考虑速度和计算成本）。

实际产品中，混合策略往往是最实用的。例如，在初始阶段采用全上下文以快速响应，随着对话深入、复杂度增加和上下文的累计，可以考虑转向轻量级 RAG，但是对于特别看中效果的一些关键功能，可以启用全上下文模式以确保最高准确性。

以 Deep Research 举例，想象一下你在用 Deep Research 在执行一个复杂的市场研究任务时的工作方式。它不应该是简单地一次性阅读所有资料，而是像一个专业研究员一样，先制定计划，然后在不同阶段采用不同的信息处理策略：

研究计划与核心导向：过程中肯定要将研究计划、用户的核心需求和已确认的关键事实持续保留在上下文中。这些信息是研究的"北极星"，需要在整个过程中保持清晰可见，以确保研究不偏离方向。这部分采用的是接近全上下文的策略。

细节信息与支持材料：对于大量的次要细节、背景资料和支持证据，则采用 RAG 方法按需检索。而不是始终将所有信息保留在上下文中，这种"用时取、用后放"的方式才能提高效率。

跨会话记忆管理：当研究持续数十分钟甚至更长时间时，对已处理的信息进行智能压缩，提取关键结论并丢弃原始细节，保留精华而非全部。这些压缩后的记忆会在后续会话中重新启用，使研究能够连贯进行。

这种混合方法的巧妙之处在于，它平衡了全局视角与细节探索。核心论点和研究方向始终保持在系统的"意识"中，而海量的细节则被组织成易于检索的形式，在需要时才调用。

对产品设计者而言，理解这种混合策略的价值至关重要。它不仅提高了效率和准确性，还大大降低了计算成本。如果完全依赖全上下文方法，Deep Research 将无法处理超过一定规模的研究任务；而如果完全依赖 RAG，则可能失去研究的连贯性和深度。

通过智能地决定"什么应该始终记住"与"什么可以临时查询"，才能够在有限的计算资源下处理远超其上下文窗口的复杂研究任务，同时保持研究质量和连贯性。

这正是为什么在构建像 Deep Research 这样的复杂 AI 产品时，混合上下文策略不是一种选择，而是一种必然，核心还是对于用户场景的把控，和计算资源、成本和效果的权衡。

评估需求时，可以考虑以下关键问题：

用户对响应速度的敏感度如何？

准确性对产品有多重要？

产品的使用场景是否涉及超长对话或文档？

计算资源和成本限制是什么？

用户期望是什么？

对这些问题的回答将指引你选择最适合的上下文管理策略。

一些常见的应对上下文限制的技巧

最重要的是任务分解设计，复杂对话任务应被设计成可管理的子任务链，而非单个庞大的任务。每个子任务可以有明确的输入、输出和上下文需求，这样系统就能更有效地管理每个环节所需的上下文。例如，一个旅行规划助手可以将任务分解为目的地选择、住宿搜索、活动安排等子任务，每个子任务专注于自己的上下文需求，而不是试图在单个对话中管理全部信息。Building effective agents 中就有列举不同的工作流设计。

同时在任务执行中，最好做到状态尽量显化，让用户更加明确，在长时间工作流中，关键状态（如用户目标、约束条件、已完成步骤）可以考虑显式记录并在需要时展示给用户确认，而非仅仅依赖 AI 的"记忆"。这不仅可以增强系统的可靠性，还为用户提供了校正错误理解的机会。

最后可以考虑记忆分层管理，一般认为受人类记忆系统启发，可以将 AI 的记忆分为短期记忆和长期记忆短期记忆包含最近的对话内容，直接放入上下文窗口；长期记忆则存储在外部数据库中，包含用户偏好、历史交互中的关键信息等。关键是建立智能的检索机制，在需要时将长期记忆中的相关内容重新唤起到短期记忆中。例如，当用户提到"我们上次讨论的那个项目"时，系统应能快速识别并检索相关的历史信息。

这些技巧不仅有助于解决技术层面的上下文限制问题，还能显著改善用户体验，使 AI 产品在长对话场景下更加可靠和实用。关键是认识到上下文管理不仅是一个技术问题，也是一个产品设计问题，需要从多个维度综合考虑。

尾巴

在设计 AI 产品时，上下文管理应该被视为核心设计考量，而非技术细节。产品应该尽早在规划阶段就思考：

我们的场景会产生多长的对话或文档？

用户期望AI记住什么信息？

准确性与响应速度的权衡对我们的产品有何影响？

全上下文与 RAG 的选择不是非黑即白的。全上下文方法可能提供稍高的准确性，但代价是显著增加的延迟和成本。对大多数产品来说，某种形式的 RAG 是实用的选择，尤其是当产品需要规模化部署或支持长时间交互时。但具体的实现策略需要根据产品的独特需求定制，同时也会显著增加开发成本。

随着技术的快速发展，产品策略需要灵活调整。新的研究和模型正在不断推出，例如 OpenAI最近发布的 GPT-4.1 系列在长上下文处理方面有显著改进。今天的最佳实践可能很快就会过时，因此建立对产品性能的持续监测机制，并保持对最新研究的关注，也是至关重要。

最后，我认为只有更好地理解并应对用户需求和技术限制之间平衡的产品，才能可以构建更智能、更自然、更可靠的产品体验。

随着 AI 技术继续快速发展，我们可以期待上下文管理策略也将不断演进，但无论技术如何变化，以用户为中心的设计思维和对技术限制的深刻理解，将始终是构建 AI 产品的基石。

MCP：Anthropic 想定义 AI 应用开发

2025-04-05T16:00:00.000Z

想象一下这个场景：用户向 AI 客户端提出"希望 AI 能够搜索网页"的需求。在传统模式下，这个简单请求会触发一连串复杂的开发流程，从需求收集到最终发布，可能需要数周时间才能让用户获得这项功能。

这种模式在 MCP（Model Context Protocol）出现之前，一直是 AI 应用开发的常态。

传统模式与 MCP 模式的对比

传统 AI 工具集成流程

下面的流程图展示了传统 AI 应用开发中，从用户提出功能需求到最终实现的完整过程。

在传统模式下，工具集成流程存在几个核心问题：

功能被客户端锁定：用户无法自行添加新工具，必须等待开发者实现并发布更新

重复开发：每个 AI 客户端都需要单独实现相似功能，无法共享已有实现

缺乏标准：各开发团队使用不同方式解析 AI 输出、处理参数、返回结果

更新周期长：即使是微小功能调整，也需要经历完整的发布周期

需要注意，这并非技术可行性问题。开发者完全可以让 AI 连接任何外部系统——网页搜索、数据库查询、文件操作等，但问题在于每项功能都需要客户端开发者单独实现，用户只能被动等待。

MCP 带来的流程变革

在 MCP 框架下，当用户希望 AI 能够搜索网页时，流程应该是：

用户选择并连接一个提供搜索功能的 MCP 服务器

AI 客户端通过 MCP 协议发现服务器提供的搜索工具

用户授权 AI 使用该工具

用户提问需要搜索的内容

AI 通过 MCP 协议调用服务器的搜索工具

服务器执行搜索并返回结果

AI 将结果整合到回答中

这个流程中，关键是用户可以选择连接任何兼容 MCP 的服务器，而不仅限于 AI 客户端开发者预先集成的功能。

在 MCP 架构下，整个工具集成流程被极大简化：

用户自主选择：用户可可以直接从 GitHub、Twitter、公众号、插件库或工具目录中找到并安装需要的功能

开发者与客户端分离：第三方开发者创建的工具可被所有 MCP 兼容客户端使用

即时可用：安装配置后立即可用，无需等待客户端更新周期

客户端开发者解放：客户端只需实现一次 MCP 协议适配，后续能力迭代几乎不再需要他们参与

这种模式转变带来了显著效率提升。用户可能在出现"希望能搜索网页"的想法几分钟后就能自行完成工具安装并开始使用，而不是等待数周的开发周期。

更重要的是，这彻底改变了 AI 应用的生态关系——转变为用户和第三方服务共同参与的开放生态。AI 产品只需专注于提供良好的基础体验和 MCP 支持，而不必为每个第三方服务的接入单独适配，就像 USB C 接口一样。

MCP 的野心：不只是 Function Call 的封装

很多人初次接触 MCP 时，基本都是将其视为"Function Call 的一种封装"或"工具调用的标准化实现"。我认为这种理解虽然不完全错误，但过于片面，远未触及 Anthropic 的核心野心。

事实上，在我看来 MCP 是 Anthropic 对整个 AI 应用构建过程的全面重新思考，它定义了很多概念，比如说 Tools、Prompts、Resources 等，共同构成了一个完整的 AI 应用框架，它想教所有人“你应该怎么做一个 AI 产品”。

工具（Tools）

大多数人首先关注的是 MCP 的工具系统，它确实是当前最成熟和应用最广泛的部分。但即使在这一层面，MCP 也远超传统 Function Call：

标准化工具定义：使用统一的 JSON Schema 定义工具接口，使不同开发者创建的工具具有一致性

工具发现机制：客户端可以通过 tools/list 端点动态获取可用工具，实现工具的动态发现

错误处理规范：定义了统一的错误报告格式，使 AI 能够理解并处理工具调用失败

权限控制模型：明确的授权机制和安全考量，让用户可以控制 AI 使用工具的边界

这些特性使得 MCP 的工具系统不仅仅是技术实现层面的标准化，更是创建了一个开放工具生态的基础设施。

提示（Prompts）

MCP 的提示系统，这一部分在目前的实现中较少被提及，但它可能对提升 AI 交互质量具有深远影响：

服务器定义的交互模板：MCP 允许服务器定义可重用的提示模板，客户端通过 prompts/list 和 prompts/get 端点获取这些模板

参数化提示：提示模板可接受动态参数，使服务器能提供可定制但结构化的交互方式

工作流引导：服务器可以定义多步骤交互流程，指导用户完成复杂任务

UI 元素集成：提示可以在客户端表现为斜杠命令等界面元素，提升用户体验

提示系统本质上是将 AI 交互专业知识标准化。好的提示词往往是 AI 应用效果的关键，而 MCP 的提示系统让服务器可以提供经过优化的专业提示模板，客户端可以直接使用这些模板，而无需重新发明轮子。

甚至 MCP 在文档中教客户端开发者如何展示这些提示：

Prompts can be surfaced in client UIs as:
Slash commands
Quick actions
Context menu items
Command palette entries
Guided workflows
Interactive forms

资源（Resources）

MCP 的定义中，它为 AI 应用提供了环境感知能力：

服务器暴露的资源：服务器可以通过 MCP 将各种数据（文件、数据库记录、系统状态等）暴露为资源

统一资源寻址：通过 URI 标识不同类型的资源，提供统一访问接口

资源内容访问：客户端通过 resources/read 从服务器读取资源内容，让 AI 可以访问这些数据

资源变更通知：客户端可以通过 resources/subscribe 订阅资源变化，服务器通过通知机制推送更新

资源系统的潜力在于彻底改变 AI 与用户环境的交互模式。比如说：用户打开一个 AI 编辑器，直接询问 AI 关于某个报错的信息，这个 AI 编辑器就可以通过实现一个内置 MCP 服务器，主要关注资源部分，然后结合标准化的资源访问能力和 LLMs 识别来实现仅仅通过报错信息就能快速定位到代码文件和进行修改。当然像 Cursor 或 Cline 这类集成了 AI 能力的代码编辑器或插件其实都已经是支持的了，但是现在通过 MCP 这一套标准协议去做，也会工程化的成本会更低，也许后面甚至会有专门做这个方面的 MCP Server 出来。

当然其实还有 Sampling、Roots 等等更多的元素：

Sampling 允许服务器直接通过客户端请求 LLMs 生成内容，好处主要在于安全性和减少 MCP Server 的成本消耗

Roots 是当客户端连接到服务器时，它会声明服务器应该关注的哪些内容，例如，当你使用代码编辑器时，客户端可能会告诉连接的服务器："嘿，请专注于这个项目文件夹：file:///home/user/projects/my-app”

最后总结一下 MCP 的一些概念

服务器-客户端协议：MCP 本质上是一个客户端-服务器协议，定义了两者之间的通信标准

服务器角色：在 MCP 生态系统中，服务器扮演着功能提供者的角色，它可以是各种不同形式：

开发工具插件：如 VS Code 扩展，提供代码分析功能

数据服务接口：连接到数据库、数据仓库的接口

网络服务：搜索引擎、天气 API 等网络服务

企业应用连接器：Slack、GitHub、Notion 等 SaaS 服务的接口

本地系统工具：文件系统访问、操作系统功能等

专业领域工具：金融分析、医疗数据处理等领域特定工具

客户端角色：MCP 客户端通常是用户直接交互的 AI 应用，它通过协议与各种服务器连接，整合它们提供的功能。典型的客户端包括：

AI 聊天应用

代码编辑工具

AI 写作工具

等等

用户的选择权：MCP 架构的一个核心理念是将选择权交给用户，用户可以决定：

连接哪些 MCP 服务器

授予这些服务器什么级别的权限

允许 AI 使用哪些工具和资源

这种架构带来的最大好处是解耦和专业化：

客户端开发者可以专注于提供优秀的 AI 体验

工具开发者可以专注于创建高质量的专业功能

用户可以自由组合这些组件，创建个性化的 AI 工作流

所以从我的角度来说，我认为 Anthropic 更像是在写一本《如何构建 AI 应用》的教科书，但是我认为它仍然存在很多问题。

MCP 面临的问题

1. 普通用户的门槛

MCP 将选择权交给了用户，但未必所有用户都能或愿意承担这种复杂性。

我在某社媒上看到有人在吐槽集成 Brave 的搜索能力时，卡在了配置界面前："API Key？这是什么东西？"

这正是 MCP 面临的首个现实挑战——虽然理论上将工具选择权交给了用户，但实际上创造了一个新的技术门槛。大多数普通用户既不知道如何获取 API Key，也不理解如何正确配置服务参数。他们只想使用功能，而不是成为半个开发者。

这种情况就像给普通用户一堆电脑配件（电源、CPU、GPU、主板、内存、SSD、机箱、显示器、键鼠等等），问题是他们只是想要一台能打游戏的电脑呀。

2. 配置体验碎片化

在测试不同的 MCP 客户端实现时，我发现每个客户端都有完全不同的配置方式：

某些客户端要求用户直接编写 JSON 配置（几乎等同于编程）

另一些提供了基础的表单界面，但仅限一些能适配得上的服务，字段名称和描述仍然充满技术术语

还有一些尝试让 AI 辅助配置，但这又会消耗大量的 tokens，增加使用成本

同时在使用部分服务甚至要求用户存在开发环境才能正常使用

想象一下，如果 App Store 中每个应用安装方式都不同，用户体验会怎么样？所以我目前对于 MCP 能够创造一个 “AI 工具 App Store” 是存疑的。

3. 安全与隐私

在封闭生态中，平台可以严格审核每个工具；但在 MCP 的开放世界里，谁来保证这些第三方工具的安全性和隐私保护？一个看似无害的天气工具，有可能在后台收集用户数据。

这种安全风险就像是把陌生人请进家门——没有完善的信任机制和安全保障，用户很难放心地使用这些工具。尽管 MCP 协议考虑了一些安全和权限控制，但我觉得仍然缺乏统一的安全标准和验证机制，大部分的评判工作仍然依赖用户自己。

4. 实现复杂度高

不管是 MCP 客户端还是 MCP 服务如果想要完整地支持 MCP，实现起来还是要比看起来复杂得多，当然目前大部分服务感觉似乎只提供 Tools 就够了，不过这样 MCP 的一些理想最佳用例似乎就很难真正应用了。

5. 标准还在演进

MCP 仍在快速发展中，规范可能随时变化。另外就是，Anthropic 是否真的有能力将 MCP 推广成事实标准，尽管它们最大的对头 OpenAI 似乎也说要支持，但我还是觉得还需要观察，比如说中美之间在未来可能都会都一些不太一样的地方，也有可能出现地区性标准啥的。

疑问和总结

对于从业者来说，我是存在一些疑惑的。是否应该现在就全面拥抱 MCP，还是等标准更加成熟？早期采用者可能面临更多变化和调整成本，但也有机会塑造标准和建立先发优势，但一般团队很难有这个资格，目前似乎没有太多因素能明显促进产品推广，许多产品的能力也无法简单地归纳为某个简单的服务。

未来的 AI 产品可能不再是封闭生态，而是由核心体验加可扩展模块组成，那么也许在未来产品规划需要考虑哪些是核心能力，哪些可以交给第三方生态，但是在开放生态中，如何建立对第三方工具的隐私和安全管理也相对比较重要。同时假设客户侧有内部专用的工具，是否可以帮助他们接入，也许也会影响到产品的规划。

或者也许可以不必再构建完整的 AI 产品，团队可以专注于特定领域的服务，如法律文档分析、医疗数据解读或金融数据处理等专业工具。那么是成为 MCP 客户端、MCP 服务提供者，还是连接两者的平台？每个位置都有不同的商业模式和竞争格局。

成功的开放标准往往经历了从混乱到秩序、从理想到现实的演变过程。MCP 正处于类似的早期阶段——充满潜力，但也面临挑战。它代表了 Anthropic 对 AI 应用开发的宏大愿景，一种将 AI 能力组件化、标准化、可组合的未来。无论如何，MCP 已经为我们提供了一个新的思考框架，更新了大家对于 AI 应用构建方式的认知。

提示词工程指南：从基础到实践

2025-03-03T16:00:00.000Z

提示词的发展历史

在大语言模型成为主流之前，NLP 领域主要采用"预训练+微调"的范式。这意味着我们先用海量语料训练通用语言模型，再针对具体任务（如文本分类、情感分析）进行微调。当时，模型主要学习预测被掩盖的词或上下文关系，而非理解和执行人类指令。

这些早期模型无法"听懂"自然语言指令，主要因为：

模型未对指令进行调整：它们的训练目标是预测文本片段或分析上下文关系，不是理解并执行开放式任务

缺乏少样本学习能力：这些模型需要大量标注数据和专门结构的微调，无法仅通过提示词即完成任务

转折点出现在 2020 年，当 OpenAI 发布了 GPT-3，这个拥有 1750 亿参数的庞然大物展示了惊人的能力：无需微调，仅通过自然语言描述和少量示例，就能在多种 NLP 任务上取得不错效果，这标志着"提示工程"时代的开始。

随后，通过指令微调（如 OpenAI 的 InstructGPT）和 RLHF（基于人类反馈的强化学习），大语言模型变得更擅长理解并遵循人类指令，而后来 ChatGPT 的爆火让提示词工程走出技术圈，成为大众话题。

这是一场范式的根本转变：从让模型适应任务，到用任务去适应模型（将 NLP 任务用提示词的方式写出来，然后再让 LLMs 去完成任务）。以往，每个 NLP 任务可能需要单独训练或微调一个模型，如今，同一个大语言模型通过不同的提示词就能完成各种任务。

用编程 vs 提问来类比：过去我们通过数据和优化来"编程"模型执行特定任务；现在我们更多是用提示词"提问或指示"，让模型调用已学到的知识给出结果。

这种变化带来了三大优势：

可迁移性提升：一个 LLM 能覆盖以前几十个模型的功能

开发门槛降低：不需要复杂的模型训练知识，会写提示词就能使用 AI（所以现在很多所谓的 AI 产品经理和 AI 开发工程师岗位应该改名为大模型 API 产品经理，大模型 API 开发工程师 🤣）

迭代速度加快：修改提示比重新训练模型要快得多

随着 Claude 3.5 Sonnet 和 GPT 4o 等更全能模型的出现，提示词技巧也在进化，链式思维提示、角色扮演、多轮对话策略等技巧被广泛应用。

如何写好提示词

提示词的写法没有放之四海而皆准的公式，最有效的方式取决于你的使用场景。根据实际需求和场景来选择合适的提示词策略，才能获得最佳效果。

日常对话

当你只是与 AI 进行日常聊天时，采用渐进式提示通常更自然有效。你可以从简单问题开始，然后根据 AI 的回应逐步深入，在多轮对话中逐步完善你的要求。这种方式不需要精心设计复杂提示词，而是通过自然对话引导 AI 达到你的目标。

比如你想获取一份报告，可以先简单问："请帮我写一份关于气候变化的报告吗？"然后根据回复再补充："我想重点关注最近五年的数据趋势，长度大约 1500 字，目标读者是大学生。"这样的交流更接近人类自然对话，也给了 AI 更多理解你需求的机会。

日常场景不需要过度优化提示词，保持对话自然流畅即可。但很多人和 AI 交流经常出现的问题就是不会好好沟通：

首先是假定 AI 知道上下文，但 AI 实际上缺乏我们认为"显而易见"的背景信息。比如直接说"这个怎么修？"而不提供"这个"指的是什么，或者说"帮我写个邮件"却不说邮件内容和目的。记住，AI 没有通过其他渠道了解你的情况，它只知道你明确告诉它的信息。

其次是不会有效对话（无法清晰表达需求或按照逻辑顺序提供信息）。很多人与 AI 交流时，要么过于简短模糊，如"写个故事"；要么信息杂乱无序，在一段话中跳跃多个主题。更有效的方式是按照合理顺序提供信息，先说明目标，再提供相关细节，就像你会对一个人解释一样。这也就是 AI，如果是一个正常人类，根本就不会理你。

第三个问题是不会准确表达自己的想法。很多人只会输出情绪（"我需要一个超级棒的营销方案！"），而不会输出具体思路（”我的产品是 XXX，特点是 XXXX，我需要一个针对 18-25 岁用户的社交媒体营销方案，强调产品的 XXX"），AI 需要具体、明确的指引，而不是模糊的期望，提供足够的细节让AI能够理解任务的具体背景和限制条件。

如果你开始学习如何与 AI 交流，首先应该学会正确表达自己的想法。这意味着：

明确你的目标：在开始对话前，先想清楚你到底想从 AI 那里得到什么，是信息、创意、分析还是建议？

提供足够上下文：简洁但完整地说明相关背景，想象你在向一个聪明但完全不了解你的情况的人解释。

逐步细化需求：从基本需求开始，然后根据AI的回应逐步添加细节和调整方向，不必一次说完所有要求。

给出反馈：当 AI 的回答不符合预期时，具体指出哪里不对，而不是简单说"不行"或"重写"。例如："这个分析缺少了对中国女性白领用户群体的考虑，请增加这部分内容？"

当 AI 的回答不理想，可以直接告诉AI哪里需要改进，大多数情况下它能根据反馈调整。这种互动式的过程通常比试图一开始就写出完美提示词更简单有效。

AI 应用开发

在 AI 应用开发中，提示词已经不仅是与模型交互的工具，而是整个应用的核心组件之一，这种环境下需要结构化的提示词工程方法，确保提示词能够被有效迭代、维护和共享，这对于产品稳定性和团队协作至关重要。

明确的任务提示

很多时候 AI 应用并不是多轮对话的形态时，需要一次性精准的回应，就需要更严谨的"一次性精准提示"，这就像给一位高级专家下达明确任务指令。那么这个提示词，最基础所需要的内容大致如下：

说明任务目的

提供必要的上下文信息

通过例子展示期望输出

预先定义异常情况的处理方式

结构化设计

在应用开发中，提示词可以适当采用模块化设计，将一个复杂提示词分解为不同功能模块，比如角色、上下文、约束、示例等，这样不同团队成员可以快速了解和理解不同模块的作用，迭代中也不必每次都修改整个提示词，也方便日后排查问题。

同时在很多场景中，如果一些上下文 or 约束是类似的，我们最好应该复用模块，而不是重新撰写。

版本管理

像代码一样，提示词也需要进行版本管理。使用 Git 等工具跟踪提示词的变更，为每次更新添加有意义的提交信息。

针对重大更新，应当建立发布流程，包括测试、审核和部署步骤。确保每个版本都有明确的标识，便于在出现问题时快速回滚，也可以方便对比不同版本提示词的效果和差异。一个好的实践是使用语义化版本号（如 v1.2.3），或日期版本号（2025-03-04）。

团队协作与沟通

如果内部达成一致，可以考虑使用专门的工具或平台管理提示词库，例如一些开源、托管的大模型开发监控产品或者开发内部工具，你甚至可以考虑在这些平台上进行提示词的 AB 测试。

另外这些提示词应该在团队内允许查看和沟通的，这不是什么非常机密的东西，它就像代码一样，应当允许团队内的产品、开发或其他任意相关人查看和随时讨论。一个 AI 应用中，提示词脱离背后工程将意义大减。

常用提示词模式及优缺点

下面是几种常见的提示词模式，大部分人应该多少就有听过和用过：

角色扮演提示

角色扮演提示通过指定 AI 扮演特定角色来引导回答方向。例如"你是一名经验丰富的财务分析师，请分析以下季度报表数据并指出关键趋势。"这种方式能引导模型采用特定专业视角，增加回答的专业性和深度，并有助于保持一致的语气和风格。

然而，过度依赖角色设定可能限制模型发挥其全部能力，有时候它会产生刻板印象化的回答，而不是真正深入分析问题，比如 Anthropic 的 Amanda Askell 说："我几乎从未使用过这种角色扮演的提示技巧——即使以前是更糟糕的模型。"她认为直接清晰地表达需求往往更有效。

链式思维提示

链式思维提示 (Chain-of-Thought, CoT) 鼓励模型一步步展示思考过程。典型格式是"请一步步思考这个问题...[问题]"或"让我们一步步分析..."。这种方法实质上是让模型在生成最终答案前，先显式地输出中间推理步骤，类似于人类解题时的"草稿过程"（当然最近又有个什么 CoD，Chain of Draft）。

这种方法在解决复杂推理问题时特别有效，它使思考过程透明化，便于检查潜在错误，在一些测试中提高了数学和逻辑问题的准确性。

这里需要注意，使用 CoT 时有个关键点：必须让 AI 输出完整的思维过程，而不是直接跳到答案。如果只是加上"让我们一步步思考"但没有要求模型展示思考步骤，那效果基本与普通提示没什么区别。

对于面向用户的应用，如果你想隐藏思考部分但又需要精确答案，可以要求 JSON格式输出，设置"思考过程"和"结果"两个分开的字段。

示例驱动提示

示例驱动提示 (Few-Shot Prompts) 通过提供几个输入-输出对的示例，然后提出新问题。

这种方法通过示例直观展示期望输出，降低了对复杂指令的依赖，能有效引导模型理解特定任务格式。

不过它也有缺点，比如占用 token 较多，而且示例选择可能无意中引入偏差（尤其出现在一些智能程度较低的模型中），模型有时会过度关注示例特征而忽视更广泛的模式，导致泛化能力受限。

结构化输出提示

结构化输出提示要求模型以特定结构（如 JSON、XML、特定的 Markdown 等）输出结果。例如"分析以下文本的情感，并以 JSON 格式返回结果，包含'情感'和'置信度'两个字段"。

这种方法产生的输出易于程序处理和解析，规范了回答格式，提高了结果的一致性，特别适合需要自动化处理结果的场景。

在之前，这种复杂结构可能增加错误率，模型有时会偏离请求的格式，但在 2024 年的迭代中，大部分大模型服务商的 API 都提供了结构化输出的能力，这一点可以参考 OpenAI 官方的文档，写得非常细致。

使用结构化输出的提示词工程也会有一些不一样，通常你还需要去定义 JSON Schema，这个时候提示词就不仅是自然语言了：

此外可能还存在非常多的提示词撰写方式，但是知道有多少种方法并不是最重要的，更重要的应该是大家应该多尝试，多评估。

如何评估 AI 的输出

如果你要把提示应用到 400 个不同的案例中，通常人们会只考虑最常见的情况，看到提示在这些情况下能够得到正确的结果，然后就不再继续思考了。但实际上，你需要去找到那些不常见的情况，思考提示在这些情况下可能会出现的模糊不清。比如，你有一个提示说，“我将发送给你一些数据，我希望你提取出所有名字以 G 开头的行。”那么你就需要考虑，“如果我发送的这个数据集中根本没有以 G 开头的名字怎么办？如果我发送的不是数据集，而是一个空字符串呢？”这些都是你必须去测试的情况，因为只有这样你才能给模型更多的指令，让它知道在这些特殊情况下该怎么做。 ——— Amanda Askell(Anthropic 模型对齐微调专家)

许多人评估提示词效果时只靠主观感受："这个回答看起来不错"，但在专业环境中，我们需要更客观的评估方法。

但是评估提示词效果不应只依靠主观感受，而应建立系统化的评估流程，只有通过客观数据，才能确定提示词是否真正达到了预期效果。

比如说一个电商客服 AI 的评估指标可能包括：准确回答率、解决问题速度、满意度评分、需要人工干预的比例等，这些客观指标比起"感觉更好"更有说服力。

建立评估框架

首先，我们需要明白，评估的主体不应该只是提示词，假设你作为一个 AI 产品的产品策划，为了保证最终的用户体验，你需要评估模型、提示词、流程等等各种方面。

因此评估方法应该多元化，包括人工评估和自动化指标结合，虽然人工评估耗时，但能捕捉到细微差别，对于主观性较强的任务尤为重要。

自动化指标能提供可量化的表现数据，例如，对于 Chat PDF，可以测量回复相关性、完整性等方面；对于强格式输出的，比如说你希望 AI 输出 20-40 字，英文占比 40%，那么都可以通过编写脚本来进行评估打分，这些客观指标比主观感受更具说服力，也更便于团队内部讨论和决策。

专门工具如 Promptfoo 可以帮助批量评估，这类工具允许你定义多个测试用例和评估指标，自动对比不同提示词版本的表现：

定义测试用例集：创建多个代表性输入，包括常见查询和边缘情况

设置评估指标：定义如何衡量成功，如准确性、相关性或完整性

配置变体：设置多个不同版本的比较对象（模型/提示词/流程）进行对比测试

执行自动化测试：工具会将每个测试用例通过每个变体发送给 AI

分析结果：比较不同模型/提示词/流程的表现，找出最佳或最合适的方案

例如使用 Promptfoo 的简单配置可能如下：

这类 AI 生成效果评估工具虽然需要一定的学习成本，但对从事 AI 产品策划的人来说，这应该是必须要学习的部分。

实际应用中，可以建立一个整体的面向业务的评分工程，对模型、提示词、流程等在各个维度的表现进行量化评估：

内容质量

准确性（输出内容与事实的符合程度）
相关性（回答与用户问题的相关程度）
完整性（是否覆盖了问题的所有方面）

输出格式

字数
输出语言
Markdown or JSON or XML or HTML

速度

Time To First Token (TTFT)：首 Token 延迟，从输入到输出第一个 token 的延迟
Time Per OutputToken（TPOT），单 Token 生成时间

成本：在商业应用中，除了效果外，成本控制同样重要，常用的优化方式包括

删除冗余指令和不必要的装饰性语言，降低 token 消耗
根据任务复杂度选择合适的模型，先用轻量模型处理基础任务，仅在必要时调用智能程度较高的模型
对于重复性高的查询实施缓存策略，避免重复 API 调用

通过这些量化指标，可以更客观地比较不同提示词的效果，指导后续优化。当然有人可能会提到说上面的内容质量部分怎么评分？这里建议可以采取人类 + LLMs 综合评估的方式，目前很多评估工具都是支持的，比如说先让一个能力较强的 AI 打一遍分数，然后人类再核对一遍。这里就像是在训练模型常用的 RLHF（基于人类反馈的强化学习，Reinforcement Learning from Human Feedback）。

利用这一套工程你可以去评估任何 AI 应用相关的内容。

持续改进机制

AI 应用的优化应该是一个持续过程，而非一次性任务，尤其是提示词的优化。

先建立初始表现基准，然后定期评估效果，识别表现不佳的方面，有针对性地改进，最后再次评估验证改进效果。

因此收集和分析用户反馈很重要，提供便捷的反馈渠道，如满意度评分或问题报告按钮。实际用户的使用体验和问题报告能揭示测试环境中可能忽略的问题，对负面反馈进行深入分析，找出提示词的不足之处，发现提示词可能未覆盖的场景，能让产品更贴近实际需求。

让提示词回归工具

我觉得把提示弄得太抽象是一种过度复杂化的方式。实际上，很多时候你只需要写一个非常清晰的任务描述，而不是构建复杂的抽象。但是话虽如此，你确实经常需要将一系列指令编译成具体的结果。因此，精确性，以及编程中考虑的版本控制和管理实验的历史记录等问题，这些都同样重要。 ——— Zack Witte(Anthropic 提示工程师)

提示词的真实定位

随着提示词工程热度上升，一种误解也随之蔓延——仿佛掌握了一些"魔法提示词"，就能让 AI 产出惊人成果（我觉得真的是滑天下之大稽），这种观点把提示词过度神话化了。

事实上，在 AI 产品开发中，提示词只是整体工程中的一个环节，而非决定性因素。就像做一个 PDF 摘要和聊天产品，虽然提示词很重要，但用户体验的差距更多来自工程实现的差异。

如何高效处理 PDF 文件，如何分块、索引和检索内容，如何维护对话上下文——这些工程问题往往对产品体验有着更根本的影响，在这个过程中，提示词只是连接各个组件的"胶水"，而非决定产品成败的核心：

采用更先进的文档解析技术，能够准确保留表格、图表和格式信息

实现更智能的分块策略，在保持语义完整的同时优化检索效率

上下文管理更高效，能够在 token 限制内最大化包含相关信息

具备完善的兜底处理机制，在召回失败时能使用 Fallback 方案

当然也有可能采用了更新的技术，例如 voyage-multimodal-3 这一多模态向量模型对于检索部分以图片为主的 PDF 来说，效果会更好等等

常见误区与正确心态

在实际开发中，常见的提示词工程相关误区包括：

过度优化陷阱：花费数周时间微调提示词措辞，却只带来微不足道的改进

万能提示幻想：寻找一个能解决所有问题的"完美提示"，而非针对具体场景定制

提示词保密：将提示词视为核心机密，过度保护而不是在团队内共享和改进

忽视评估：在不同数据和场景下缺乏系统评估，导致提示词在实际应用中表现不佳

忽略用户反馈：过度依赖内部评估而非真实用户体验

更健康的心态是：提示词只是工具，不是秘密武器。它重要但非核心，应达到"足够好"即可，关键是确保它能与系统无缝配合，并建立客观评估机制。

AI 应用真正的核心竞争力在于产品的整体：数据处理、模型集成、上下文管理、错误处理、用户界面和用户体验设计。

结语

提示词工程是 AI 应用开发的重要环节，但并非全部。它是帮助我们与 AI 系统有效沟通的工具，而非神秘的魔法。

未来，撰写提示词会成为所有团队成员的基础技能，而真正的竞争力仍是这些传统的能力——识别场景需求、设计整体解决方案等。

部分对话引用来源：Claude AI圆桌论坛：资深提示工程团队手把手教你写提示词

介绍一下 PoweReader

2024-11-18T16:00:00.000Z

缘起：从 Reeder 说起

一直以来我都在用 Reeder 订阅各种 RSS，它确实是一款很优秀的 RSS 阅读器。但作为一个重度英文 RSS 用户，每天要读的英文内容实在太多了。虽说英语水平还过得去，但直接读英文总归没有读中文来得快。每次看到感兴趣的文章，都要复制到翻译软件，再切回来继续读...这个过程真的很影响阅读体验。

后来接触到沉浸式翻译，发现把英文原文和中文译文并排展示的方式，确实让阅读变得流畅了许多。这让我萌生了一个想法：为什么不把这样的阅读体验带到 RSS 阅读器中呢？

就这样，我开始尝试开发一款新的 RSS 阅读器，第一个特性就是内置了沉浸式翻译。不过随着项目的推进，发现光有翻译还不够。现在的信息实在太多了，光是订阅的几十个 RSS 源，每天就有几百篇文章，根本读不过来。正好赶上 AI 技术的爆发，我就想：为什么不让 AI 来帮助应对信息过载？

AI 辅助阅读

经过几个月的开发和优化，PoweReader 现在集成了多个 AI 功能：

AI 摘要：无论是单篇文章还是整个列表，都可以一键生成核心要点。特别是对于那些篇幅很长的技术文章，先看摘要再决定要不要深入阅读，能节省不少时间。

每日精选：每天打开 App，AI 会根据设置的关键词，从昨天的未读文章中挑选出最值得关注的内容。这样就不用担心错过重要信息了。

本地 AI 模型：考虑到隐私和用量问题，开发了一个轻量级的本地 AI 模型。虽然不如云端模型那么强大，但大部分情况下也能生成不错的摘要，而且完全离线，不限制使用次数。

可视化总结：最近又加入了一个新功能 - AI 可以把文章内容转换成直观的图片。比如读到一段复杂的技术架构描述，可以让 AI 画个流程图，理解起来更容易。

一路优化

从今年 3 月份上架到现在，已经发布了将近 20 个版本。除了 AI 相关的功能外，还添加了许多实用特性：

支持多种 RSS 服务，包括内置 RSS、TinyTinyRSS、FreshRSS、Fever、Miniflux、Feedbin、NewsBlur 等

通过 iCloud 在 iPhone 和 Mac 之间同步阅读进度

支持全文获取，无需打开原始链接就能阅读完整内容

支持离线阅读，包括离线图片缓存

支持 OPML 导入，轻松迁移订阅源

特别值得一提的是本地 AI 模型的优化过程。为了能随时随地使用文章摘要，在保证摘要质量的同时，把模型尽可能做小，让它能流畅地运行在手机上。这个过程确实花了不少心思，反复试了很多方式才找到一个可行的方向。

已上线 Product Hunt

今天 PoweReader 正式登陆 Product Hunt 了。如果觉得这个产品有帮助，欢迎去 Product Hunt 投票支持，也可以去 https://powereader.app 查看更多信息。

同时 iPhone 和 Mac 版本都已经上线 App Store。如果使用过程中有任何问题或建议，随时欢迎反馈 support@powereader.app。