XKC 的不定期分享

Agent = Model + Harness，那 Harness 能让模型更聪明吗？

2026-09-13T16:00:00.000Z

假设你让 AI 整理上个月的 14 张发票，做成一张人民币报销表，写清每一笔花了多少钱、在哪儿花的、属于哪一类。

AI 很快交出了一张整齐的表格，列出了 14 笔明细和合计金额。你抽查到其中一笔香港酒店的费用，发现发票写的是港币，AI 却直接把票面数字加进了人民币总额，没有换算。

你不知道其他 13 笔里还有没有类似的错误，只好从头核对一遍。AI 省下了填表的时间，但你仍然需要检查每笔记录，才能放心把表交出去。

在这个假设里，AI 读完了所有发票，填全了明细，也没有算错加法。问题出在它没有把「这笔费用是港币」和「这张表要用人民币报销」联系起来。

这类错误让人困惑，因为 AI 看起来已经把事情做完了。它有工具，能读文件，也能生成表格，为什么还是不够可靠？增加检查步骤、操作说明和工作流程，能不能减少这种错误？

什么是 Harness

你在聊天窗口里说「把这些发票整理成报销表」，过一会儿就收到了文件。这个过程看起来像是模型读完发票，再把表格写出来，但从你提出要求到拿到文件，中间还有许多工作需要模型之外的系统完成。

以这次报销任务为例，假设助手需要调用工具读取发票、汇总金额，再生成表格。我们先看它怎样读取一张发票。

系统先把文件列表和读取工具的说明交给模型，让它知道有哪些文件、可以怎样读取。模型据此提出请求，比如「读取第二张发票」，读取工具便打开文件、提取内容，系统再把结果交回模型。模型看到内容之后，才能决定记录哪些信息、还要不要查看其他文件。

工具就是供模型调用的具体功能。 读取文件、搜索邮件、运行计算、生成表格，都可以做成工具。每个工具都接收特定的输入，并返回结果。例如，读取工具根据文件路径找到文件，返回文件内容或读取失败的原因；计算工具接收算式，返回计算结果。模型负责提出调用请求，实际操作由工具执行。

但有了工具，这件事也不会自动完成。哪些工具现在可以使用？模型有没有权限读取指定的文件？读取失败后，系统怎样告诉模型失败原因？任务做了一半，系统怎样让模型在后续处理中记得哪些发票已经处理过？生成表格后，是继续检查，还是把文件交给用户？这些都需要系统组织和管理。

围绕模型安排这些工作的系统，就是这里说的 Harness。 它把用户要求、任务材料和可用工具的说明交给模型，执行模型发出的工具调用，再把结果交回模型，让模型继续处理任务。你收到最终回答之前，模型可能已经多次调用工具，并根据每次返回的结果决定下一步。

工具可以由产品团队实现，也可以连接外部服务。例如，邮件工具连接邮箱服务，完成保存草稿或发送邮件的操作。Harness 提供工具说明、检查调用权限，并把结果交回模型，但不需要自己实现整个邮箱服务。

指令和技能文档也参与这个过程，但它们的作用不同。「报销金额统一用人民币」是在说明任务要求；「遇到外币时，先确认汇率来源和日期，再换算」是在提供处理方法。计算工具负责执行模型提交的算式。系统在什么时候提供哪条指令、哪份文档和哪些工具，会影响模型接下来做什么。

现在回头看那张报销表，就能看出问题出在哪里。读取工具可以准确返回港币金额，计算工具可以正确加总模型提交的数字，表格工具也可以正常生成文件，但如果模型没有意识到需要先换算，最后的报销金额仍然会算错。Harness 让这些操作得以完成，模型则需要理解金额该怎样处理。

即使只聊天，不调用工具，系统也要为模型准备信息。它会把相关的历史对话和默认指令一起交给模型，对话太长时，还可能删减或概括旧记录。你觉得助手「记得前面说过什么」，往往是因为系统再次提供了那些信息。所以，聊天助手的表现从来不只取决于选了哪个模型，也取决于模型每次实际收到什么，以及它的输出怎样被处理。

DeepSeek 在介绍自己的 Harness 时，用「Agent = Model + Harness」这个等式说明两者的关系：一个 Agent 由模型和 Harness 共同组成。这里可以先把 Agent 理解为能够为完成任务调用工具，并根据结果继续行动的 AI 助手。这个等式解释了 Agent 由什么组成，至于模型和 Harness 分别怎样影响它的表现，我想进一步谈谈自己的理解。

我的看法是，模型的能力对应一个分数范围。Harness 能让模型的发挥更稳定，提高下限，也让它更有机会发挥出较高的水平。至于最高能达到什么水平，我认为主要由模型决定。

举个例子，假设一个模型的表现最低可以是 0 分，最高可以是 100 分。这些数字只是为了方便说明我的理解，不是实测分数。没有合适的 Harness，它可能缺少必要材料，或者在执行中途出了问题，最后得到一个低分结果。好的 Harness 把这些可以避免的问题处理好，它的日常表现就可能从经常不及格，变成大多能达到 60 分以上。我说的提高下限，是让低分结果更少出现，并不意味着每次都能保证达到 60 分。

90 分、100 分的结果也是如此，模型有能力做到，不代表每次都能做到。同一个任务让它重复尝试多次，也就是多次采样，可能才会出现一次特别好的结果。好的 Harness 还能提高这类高分结果出现的概率，让模型更经常地发挥出它原本就能达到的水平。

继续用这个分数例子：原来多次尝试才出现一次的 90 分，现在更经常出现了；原来经常不及格，现在大多能达到 60 分以上。两种变化都让 Agent 更好用，但不意味着模型的最高分从 100 分变成了 120 分。

Harness 能带来什么

没读过文件，就拒绝修改。 假设你让 AI 修改一段代码，它根据之前的对话猜测文件里有什么，直接提交了修改请求。如果编辑工具直接执行，它就可能改错位置，甚至覆盖原有内容。

一种做法是在指令里写「修改前必须先读文件」，让模型记住并遵守。另一种做法是让编辑工具检查模型在当前任务中有没有读取过这个文件，如果没有，就拒绝修改，返回「请先读取文件，再提交修改」。模型收到错误提示后，可以先调用读取工具，再根据文件的实际内容修改。

两种做法的差别是，前者要求模型不要跳过这一步，后者让它跳不过去。模型没有因此变聪明，但它凭猜测直接修改文件的机会减少了。这就是我理解的 Harness 提高下限的一种方式。

读过之后，文件变了，也不能直接覆盖。 模型读取文件时，系统可以记下文件的版本。假设模型还在准备修改，另一个人已经保存了新内容，编辑工具就应该检查出版本变化，拒绝按旧内容修改，并要求重新读取。

这条错误提示能让模型知道，文件已经变化，需要先读到最新内容再修改。如果没有这个检查，修改可能显示成功，却覆盖了别人刚保存的内容。程序不需要理解代码的业务含义，也能通过比较版本阻止这次操作。

没有用户确认，就不能发送。 你让 AI 起草邮件，要求「先给我看，确认后再发」。Harness 可以把发送工具设成必须经过用户确认才能执行。模型即使提前发起发送请求，系统也会暂停操作，等待用户授权，而不是把模型自己写的「用户已同意」当作确认。

这个机制可以阻止未经确认的发送，但不能保证草稿内容正确，也不能替用户判断邮件该不该发。系统在这里检查的是用户有没有确认发送。

这些设计都可以由 Harness 实现，但并非所有 Agent 都具备。程序在操作前检查必要条件，确认条件满足后才允许工具执行。程序可以检查模型有没有读过文件、文件版本有没有变化、用户有没有确认，不必每次都依赖模型记住要求。

除了限制操作，Harness 还需要让任务能够正常进行。邮件工具一次只返回 20 封，就要说明是否还有下一页；任务要求明天早上发送邮件，就需要真正保存并触发定时任务；修改 3 个文件时有一个失败，就要把错误交回模型，并保留另外两个的执行记录。否则，模型即使理解了任务，也可能因为信息不全、功能缺失或执行中断而失败。

技能文档则可以提供一些具体方法，比如怎样翻到下一页、怎样运行项目的测试、怎样确认文件保存成功。模型可以参考这些方法完成任务。但文档里的提醒和程序中的检查有区别：写着「修改前先读文件」，不代表编辑工具已经禁止跳过读取。了解一个 Harness 时，需要分清哪些要求依赖模型遵守，哪些由程序检查并执行。

判断仍然要靠模型

编辑工具要求先读文件，可以防止模型没看内容就动手。但模型读完以后，可能误解某个函数的作用，改错计算逻辑，或者删掉用户原本想保留的功能。读取记录能证明它调用过读取工具，不能证明它理解了代码。

报销表也是一样，AI 读到了港币金额，也知道用户要人民币报销表，但还需要把这两条信息联系起来，得出「先换算，再汇总」的结论。Harness 可以要求它先读取发票，模型却仍然可能没有注意到币种。

真实工作里的材料经常混着旧版本、相似的名字和互相矛盾的说法。把材料找齐之后，模型仍然需要判断哪些相关、哪些有效，以及该按哪一条执行。

下面三个任务都是假设例子，其中的公司、文件和规则用于说明模型可能在哪些地方判断错。

第一类，两家公司名字相近，业务却不同。

你让 AI 整理这次采购的供应商邮件，把报价、交货安排和付款资料放进「包装采购」文件夹。

收件箱里有一家「青禾包装」，邮件谈的是纸箱报价和交货日期；还有一家「青禾传媒」，发来一封广告设计服务的推销邮件。你之前和供应商往来时，常把「青禾包装」简称为「青禾」，所以搜索「青禾」会把两家的邮件都找出来。

正确的做法是把青禾包装的采购邮件移入文件夹，不移动青禾传媒的推销邮件。AI 需要结合业务内容判断，不能因为两封邮件都出现了「青禾」，就把它们当成同一家公司的往来。

搜索工具把两家邮件都找出来，并没有出错。归档工具按照 AI 的选择移动邮件，也可以正常完成。容易出错的是模型选择邮件的那一步，它需要分清哪家公司参与这次采购，哪家公司只是在推销。

第二类，新通知只改了部分要求。

你让 AI 按最新要求设置老客户优惠。原方案写着：「优惠码叫『老客七五折』，用户输入后按原价的 75% 付款。」两天后，负责人发来更正：「折扣调整为八折。优惠码已经发给客户，名称不要改。」

正确的设置应该保留「老客七五折」这个名称，但实际按八折计算。原价 100 元，输入这个优惠码后应付 80 元。

模型可能犯两种错：看到优惠码叫「七五折」，就继续让客户付 75 元；或者读懂了要改八折，顺手把优惠码改成「老客八折」，导致客户手里已经收到的旧码不能用。

模型需要读懂这封通知的两项要求：折扣要改，优惠码名称不改。模型不能只找最新的数字，也不能为了让文字看起来一致，就自行修改所有相关内容。

模型把优惠码名称和折扣作为参数传给设置工具，八折和七五折都在工具允许的范围内，因此工具都能接受。工具返回成功，说明它已经按模型传入的参数完成设置，但这个折扣不一定符合用户要求。

第三类，费用超过普通标准，却不一定违规。

你让 AI 按公司差旅制度检查报销单。为了方便说明，假设制度规定：普通出差的住宿费上限为每晚 500 元；会展期间，入住公司指定的酒店，可以凭行政部门的确认邮件报销，最高每晚 800 元。

现在有三笔住宿费：第一笔每晚 680 元，住的是会展期间公司指定的酒店，附有行政确认邮件；第二笔每晚 580 元，是普通出差，没有特殊批准；第三笔每晚 760 元，备注写着「参加会展」，却没有提供指定酒店的确认材料。

这三笔都超过 500 元，但处理方式不能一样。第一笔符合例外规定，可以通过；第二笔超过普通标准，需要按制度处理；第三笔还缺少判断依据，应该要求补充材料，不能仅凭「参加会展」四个字就通过，也不该直接断定它一定违规。

如果 AI 把所有超过 500 元的记录都列为违规，就会误报第一笔；如果只要备注里写了「参加会展」就允许报销，又会在第三笔缺少证明时直接通过。

工具可以筛出超过 500 元的住宿费，但能不能报销，还需要结合出差事由和确认邮件判断。

在这些任务里，工具都可能正常工作，AI 却仍然把事情做错。归档工具移动了邮件，但模型选中了推销邮件；设置工具按模型提交的参数修改了折扣，但模型传入的是七五折，用户要的却是八折；报销工具筛出了超额费用，但模型没看确认邮件，就把可以报销的住宿费判成了违规。

这几个例子里，工具执行了模型的要求，模型却没有正确理解用户的要求。

拿优惠码的例子来说，如果模型只读了旧方案，没有读到后来那封「改成八折，名称不变」的通知，Harness 可以在提交设置之前要求它查找并读取后续通知。模型因此发现新要求，就有机会把折扣改对。

但如果模型已经读到了这封通知，却仍然认为「既然改成八折，优惠码也应该改名」，即使程序确认它读过通知，也没能阻止它改错名称。程序能检查模型有没有调用工具读取通知，却不能仅凭这条记录知道它有没有读懂「名称不变」。修改文件前要求先读取文件，也是同样的道理。Harness 可以阻止模型跳过读取，但读完以后有没有理解正确，仍然取决于模型。

技能文档可以提醒模型核对供应商、查看新旧方案或检查报销证明，帮助它减少遗漏。但模型还要判断什么时候需要这些检查，以及怎样使用检查得到的信息。

固定业务可以逐项增加检查，通用 Agent 面对的任务却不断变化。

Harness 可以提供方法、执行明确的限制，但当前任务该用什么方法，以及材料到底意味着什么，仍然需要模型判断。

对构建 Harness 的启发

理解这些区别之后，构建 Harness 就有了一些具体的依据。能够由程序检查的要求，不必每次都交给模型记住。

修改前有没有读取文件、文件版本有没有变化、用户有没有确认，都可以在调用工具时检查。把这些事情交给程序，既能减少遗漏，也让模型少处理一些不需要临时判断的问题。

模型调用工具之后，Harness 还要把实际发生的事情告诉它。比如，模型要修改折扣，工具除了返回「修改成功」，还可以返回改的是哪个优惠码、现在的折扣是多少。模型有了这些信息，才有机会发现自己改错了优惠码，或者把八折填成了七五折。如果工具只说「成功」，模型就可能直接把任务标成完成，继续下一步。

但也不能每出一次错，就给所有任务多加一道检查。比如，AI 漏看了一份文件，我们就要求它以后每次都读完所有文件。这样也许能少漏一些内容，但下次用户只想改一个文件名，它也得先把所有文件读一遍。用户等得更久，token 也花得更多。所以，加规则时还得想一想：这次确实用得上，换个任务还需要吗？

渐进式披露是这里一个重要的设计方法：先让模型知道有哪些信息和能力，需要时再提供详细内容。 比如，先提供技能名称、用途和读取位置，任务涉及报销时，再读取报销方法；方法里涉及外币处理时，再查相关规定。不必在每次对话开始时，把报销、采购、合同审查的全部说明都交给模型。

渐进式披露也有前提。模型需要从简短说明里判断什么时候该读哪份内容，并且有明确的读取方式。如果说明太模糊，模型根本不知道还有一份相关规则，少用的 token 就可能变成遗漏。必须遵守的权限限制也不能只藏在按需读取的文档里，仍应由系统检查。这里要减少的是无关内容，不能让模型拿不到完成任务所需的信息。

信息怎样提供，还会影响缓存命中率。如果多次请求的开头相同，一些模型服务可以复用之前处理过的内容，降低重复输入的费用和处理时间，这就是这里说的 Prompt 缓存。对于依赖相同前缀的 Prompt 缓存，稳定的指令和常用工具说明可以保持内容、顺序不变，任务材料和后续读取的内容再按需追加。这样既不必一开始提供全部信息，也有机会复用已经处理过的输入。具体效果取决于 API 的缓存机制，不能为了追求更短的单次请求，就每轮重排整段上下文。

因此，少用 token、提高缓存命中率，都要以完成任务为前提，并看整个任务的消耗。一次少给了关键信息，导致模型反复查找，最终可能更贵；缓存命中了大量无关内容，模型仍然需要在这些内容里判断哪些有用。增加一条规则、一次读取或一次复核，都需要看它减少了什么错误，以及带来了多少额外处理。

对我来说，构建 Harness 需要不断回答一个问题：这一步真的有必要吗？删掉它，任务会不会更容易出错；保留它，多花的时间和 token 又解决了什么问题？这些取舍，需要随着任务和模型的变化重新判断。

我最近一直在微信里跟着 AI 练 HYROX

2026-07-29T16:00:00.000Z

最近我多了个习惯：训练计划直接在微信里跟 AI 一起定。

我平时练 CrossFit 和 HYROX。CrossFit 就是在健身房里做各种高强度功能性训练，举重、体操、有氧混着来，每天的课表都不一样。HYROX 更像一场体能竞速赛：跑 8 个 1 公里，每跑完 1 公里接一个动作，雪橇推拉、划船、波比跳、农夫行走，全程不能停。这两个项目都很吃心肺和持续输出。

为了准备 HYROX 比赛，我开始补跑步和心肺，问题一下子就多了：20 分钟节奏跑到底怎么跑？HYROX 团课能不能代替间歇跑？昨天刚上完 Hyrox Complete，今天还能不能接着跑？准备测 5KM，第一公里该跑多快？

最近几个月，我练完都会打开微信，跟 AI 聊一会儿当天的训练。

有时候就是一句：「今天课上又被拉爆了」「昨天腿还挺酸，明天能不能跑间歇」，或者直接问它：「这周已经连着练了三天，周末还想去 Savage，你说怎么安排？」

一开始都是随手问问。后来我发现，单次问答根本做不了训练规划。每开一个新对话，都得从头解释我最近练了什么、哪天有空、之前哪儿疼、现在在备什么比赛。

我想要的是同一个 AI：它记得我之前的情况，还能根据新数据一直修正判断。

它得先慢慢了解我

用久了，AI 当然也会判断错。

有一次它把 Savage 当成了课程。我直接纠正：Savage 是我训练的健身房，Hyrox Complete 才是课。之后聊课表，它就没再把这俩搞混。

这事看着小，其实很能说明长期记忆的作用。

训练这件事，AI 真正需要记住的，远不止身高、体重、最大心率。它还得知道我平时练什么、固定课排在哪几天、最近在备哪场比赛、哪些训练容易连着上强度，以及它之前给过哪些不靠谱的建议。

比如我说「周末还想去 Savage」，只有它知道这是个场馆，才会接着问我打算上什么课。要是把 Savage 当成一门课，后面强度怎么判断肯定就偏了。

所以记忆的价值不只是少打几行字，它直接决定了 AI 能不能听懂你在说什么。

它看不到我身体发生了什么

但有个很麻烦的问题：AI 再聪明，也看不到躺在 Apple Health 里的数据。

我总不能每次都截图，手动告诉它昨晚睡了多久、HRV 多少、跑了几公里、平均心率多少。

而且训练数据也不是几个平均值能说清的。一场 HYROX 或者间歇跑，很多有用的东西都藏在过程里：心率从哪一段开始往上窜，组间有没有歇过来，每公里配速是不是一直在掉，步频和功率什么时候变了，中途停的时间有没有把平均值拉偏，还有练之前几天的睡眠和恢复怎么样。

所以我干脆做了个叫 Somvia 的东西，把 Apple Health 里的健康和训练数据整理成 AI 能直接查的结构，再通过 MCP 接进 Hermes。

接好之后，玩法一下子变多了。我不用一项项抄数据了，AI 能自己读一场比赛的心率曲线、每公里配速、间歇分段、步频、跑步功率、睡眠阶段、HRV、静息心率、VO₂ Max。

再往前看几周，它还能整理出一些过去通常要在专业跑表、恢复设备或者训练平台里才能看到的分析：最近高强度是不是太密了，跑量有没有真的涨上来，长距离从第几公里开始掉速，恢复变差是单日波动还是一直在往下走，现在的配速区间和成绩大概是什么水平。

不过这些原始数据还是来自 Apple Health。Somvia 负责整理和查询，阈值配速、Critical Speed、训练负荷、成绩预测这些，是模型基于已有数据推出来的，得继续拿真实训练校准，不能当成实验室测出来的结果。

记久了，判断会不一样

有一次我连着两天都在上强度。

第一天做了一次 HYROX 全程模拟，用时大概 1:37:30，平均心率接近 172，最高冲到 187。第二天又做了将近 1 小时 41 分钟的 Mixed Cardio，平均心率 160 左右。

我自己当时就觉得「这两天量还挺大」。

但 AI 往前翻了记录，发现我那段时间 13 天练了 12 天，好几节课最高心率都接近 180，就建议我别再往上堆了，至少留一个完整休息日。

如果只看当天，我还能继续练。把前后十几天放一起看，结论就变了。

测 5KM 时也遇到过类似的情况。

我 8×1KM 间歇，工作段平均能跑到 4:40/km 左右。单看这个，很容易给一个挺激进的预测。

但 AI 还查到两件事：一是我当时纯跑量其实不高，7 月折算下来一周也就 12.4km 左右；二是我有次连着跑前 3KM 用了约 15:36，后面明显掉速了。

把短间歇速度、持续跑能力和跑量底子放一起，它给的 5KM 预测是 24:30 到 25:30，建议先按 25 分钟来：第一公里压到 5:05，第二、三公里稳在 5:00，3KM 之后再按体感提。

这个判断跟我自己的感受很贴：短间歇速度有了，但连续顶住的能力还不够稳。第一公里跑嗨了，后面就容易还债。

长期数据的作用就在这儿——它会拉住模型，不让它被一次漂亮成绩带跑偏。

体感也是数据的一部分

Apple Health 能记心率和配速，却不知道我那天为什么跑得慢。

天太热、前一晚没睡好、课里休息偏多、动作不熟、腿有点不舒服，这些都会影响表现，但手表记不全，模型也不可能凭空知道。

所以我练完还是会补几句：

「今天体感其实不累。」

「这节课中间休息比较多。」

「心率偏高，可能跟天热有关。」

「右腿有点紧，但不疼。」

它也不会只认手表数据。AI 会把这些和设备数据放回去重新判断，我到底练了多少、第二天该怎么安排。Apple Health 不知道我今天想练什么，主观体感还是得自己补。

这也让我重新理解了健康数据：体感不是什么不可靠的附注，它本身就是训练上下文的一部分。设备数据和人自己的感觉，得互相校正。

核心的判断，我还是交给强模型

我这套配置是 Hermes 接 Codex，用 GPT-5.6 Sol，reasoning effort 开到 xhigh。Hermes 对我最大的好处就是能接微信，练完顺手聊两句就行，它的长期 Memory 和历史会话负责把这些零散交流接起来。

为什么选 Sol，原因很直接：训练分析很看模型够不够强。

它得同时懂运动生理、跑步训练、睡眠、恢复、伤病风险这些东西，还得把它们跟我几个月的训练记录揉在一起算。这里面既有计算，也有很多不完整、互相牵扯的信息。

现在很多小模型的 Agentic 能力做得很强，搜东西、调 API、制作 PPT 啥的，看起来很哇塞，靠给它喂工具调用的数据、做专项训练，很快就能补上来。这类任务通常边界清楚，结果也好验证：工具调没调成功、JSON 对不对、文件生成没有，都有明确答案。

但健康和训练分析经常没有唯一标准答案。同样的心率配速，还得看天气、睡眠、训练史、体感、设备误差。Agentic 跑分高，只能说明它擅长那一类任务，不能直接证明它的开放领域知识和复杂健康判断也一样强。

Sol 是 GPT-5.6 系列里最强的那个，官方定位就是处理复杂专业工作的旗舰。在更偏临床的 HealthBench Professional 里，Sol 也比同系列的 Terra 和 Luna 高。HealthBench 不能直接代表训练规划能力，但它至少说明一件事：处理复杂健康信息时，最强的模型确实有更大的余量。

xhigh 是给模型更多推理预算，让它能多花点时间查事实、找缺失信息、比较不同解释、看数据之间有没有矛盾。

我不是说它每次都对。但核心判断我还是愿意交给能力余量更大的模型，再把 reasoning effort 开到 xhigh，让它多检查几遍。

所以假如你也想用 AI 接管自己的训练，有条件的话我个人更推荐 ChatGPT 或 Claude。Gemini 全系列我强烈不推荐——至少在我自己的使用里，它的幻觉问题和复杂健康数据的稳定性远没有达到要求。国内的话，Kimi K3、Qwen 3.8 Max 我试过都还不错，其他的都比较一般。实测下来感觉还是跟参数量强相关。

说到底是在设计上下文

这套系统拆开看其实不复杂：

微信是我平时说话的地方；

Hermes 记着长期背景、历史对话，负责调工具；

Somvia 把 Apple Health 的数据整理好给它查；

GPT-5.6 Sol 负责理解、计算、判断。

真正难的是决定什么东西该进 Prompt。

像我练 CrossFit 和 HYROX、Savage 是场馆、固定怎么排课，这种长期不变的，适合放进长期记忆。

每天在变的心率、睡眠、HRV、训练记录，适合需要的时候再通过 Somvia 查。

「今天不累」「右腿有点紧」这种体感，得带着时间和场景存，不能直接焊死成长期结论。

阈值配速、成绩预测、恢复判断这些推出来的结果，要标清楚依据和时间，后面的训练数据能更新甚至推翻它。

要是把所有历史都塞进 Prompt，上下文很快就被污染了；可只留几个固定标签，AI 又看不懂现在的状态。长期训练助理干的活，就是一直在挑「此刻真正有用的那部分信息」。

所以它说到底是个上下文设计问题。

它也有边界

我不会让 AI 替医生或教练做决定。

手表和 Apple Health 的数据可能缺、可能有误差，模型推出来的阈值配速、恢复状态、成绩预测，都得靠真实训练一次次验证。

真出现持续疼痛、胸痛、头晕、心悸、心率异常，就该停训去看专业的人。AI 在这儿顶多帮我整理信息、发现异常趋势，诊断它做不了。

我更愿意把它当一个一直在旁边参与我训练决策的助理：整理记录、发现矛盾、算配速，提醒我别忘了前几天发生过什么。最后练不练、练多少，还是我自己定。

从聊天工具到训练助理

现在我流程很简单。

练完就在微信里说一嘴：今天练了什么、体感咋样、哪儿不舒服。AI 自己去查 Apple Health 的心率、配速、睡眠、恢复，再结合前几周的记录，判断这次到底练到什么程度，第二天该上强度还是收一点。

一次新的 5KM 测试，也不是测完就完了。真实成绩会被放回之前的间歇、周跑量、后程掉速里，重新校准配速区间和下一阶段怎么练。

每多练一次，后面判断的依据就多一块真实信息。

我现在觉得，AI 帮你规划训练，关键就在这儿：它得长期记得你怎么练的，看得到身体真的发生了什么，模型本身还得有能力把这些信息串起来。

Hermes 记着训练背景，Somvia 接进 Apple Health 数据，GPT-5.6 Sol 负责理解和判断。这三样接起来之后，我在微信里随手说的那几句话，才慢慢变成一套一直跟着我更新的训练计划。

对我来说，这才是 AI 从一个聊天工具，变成我长期训练助理的那一刻。

Agent Memory 设计指南：AI 助手到底应该记住什么？

2026-06-12T16:00:00.000Z

很多人一聊 Agent Memory，第一反应会跑到框架和库：要不要上 Mem0、Zep、MemOS，还是自己用向量库和 RAG 拼一套。这个反应很正常，毕竟 Memory 最后总要落到存储、检索、更新和删除。

问题在于，框架选型一放到前面，讨论很容易变成工具对比。Mem0、Zep、MemOS 这些东西当然有差异，但放在产品早期，它们都还只是实现路线。更有区分度的入口，是先看场景：客服 Agent、销售助手、个人助理、coding Agent、学习产品，对 Memory 的要求完全不同。

客服要稳定保存用户偏好和工单状态；销售要记客户关系、痛点和下一步动作；个人助理要接上昨天的工作；coding Agent 要记住 repo 里的局部规则；学习产品要判断用户最近卡在哪里。场景不同，后面的 Schema、检索、更新、过期和权限设计都会不一样。

Agent Memory 其实是在设计上下文。什么东西有资格再次出现在 Prompt 里，什么时候出现，以什么形式出现，带着多高的可信度出现，这些才是真正影响体验的部分。

总览图：Agent 与不同记忆模块之间的读取和写入关系

用户画像与历史搜索

用户画像与历史对话搜索的双层记忆结构

最常见的一类 Memory，是用户画像加历史搜索。

用户画像放少量稳定信息，比如用户是谁、常用技术栈、回答风格、固定项目背景、常用工具环境。它的作用是让 Agent 一上来就知道一些基础背景，不用每次都重新问。

Profile 一定要克制。

「用户偏好直接、信息密度高」可以进画像；「用户昨天在改 Agent Memory 那篇博客」不适合长期放着。后者很快会过期，几天之后还在系统提示里出现，只会让 Agent 误判当前任务。

完整历史就放在历史记录里，需要证据时再查，不要默认塞进 Prompt。用户问「上次我们怎么定的」，这时候去搜索历史记录很合理；如果每轮对话都把过去几个月的摘要带进来，就会变成背景噪音。

Claude 就是这一类。它先整理出一份 profile，把长期偏好和背景放进去，默认影响回答；需要查过去发生过什么时，再用 Chat Search 去搜历史对话。Hermes 有类似分工，USER.md 放用户偏好，MEMORY.md 放环境事实和工具经验，会话搜索负责回看过去。

这个模式适合做第一步个性化。用户不用每次自我介绍，Agent 不需要背着完整历史上路。少量稳定画像，加一个能搜历史的入口，已经能解决很多产品里的 Memory 需求。

时间维度与工作记忆

今天、昨天、当前任务和长期归档组成的时间分层记忆

长期画像只能解决一部分问题。很多时候，Agent 接不上话，并非因为它不知道用户是谁。更常见的情况是，它不知道昨天发生了什么。

比如昨天改了一篇文章，上午定了一个方案，刚才跑了一个测试，或者某个任务做到一半停住了。这些信息太新、太具体、变化太快，不适合写进长期画像。如果只留在聊天记录里，每次都要从历史会话里重新找，速度慢，结果也不稳定。

中间应该有工作记忆。今天、昨天、当前任务、没做完的事、刚刚定下来的方案，都可以先放这里。

这种工作记忆看起来很简单，但对个人助理、写作协作、研究助理这类长期使用的产品非常关键。一个天天用的 AI 助手，用户最常问的其实就是：「昨天说到哪了？」「上午那个决定是什么？」「刚才那个任务处理完了吗？」这类问题靠长期画像解决不了；每次都去历史会话里现找，记录一多就慢，而且不一定找得准。

OpenClaw 的记忆机制可以作为一个参考。它把长期记忆和工作记忆分开：MEMORY.md 放长期事实、偏好、长期决策和压缩后的摘要；memory/YYYY-MM-DD.md 放当天的运行上下文、观察、会话摘要和还在变化的信息。今天和昨天的 daily notes 会自动进入上下文，更早的 daily notes 留在文件里，通过 memory_search 或 memory_get 查回来。

这里关键在时间维度。长期记忆保持克制，日常上下文有自己的位置，历史内容可以搜索但不会每次都塞进 Prompt。对个人助理、写作协作、研究助理这种连续使用的产品来说，工作记忆会直接影响「能不能接上昨天」。

我现在主力个人 Agent 已经转到 Hermes，原因也很简单：Hermes 的上下文工程、工具系统、定时任务、消息通道和整体可扩展性更适合我现在的工作流。但只看 Memory 体验，OpenClaw 在时间连续性上设计得更完整。它在长期记忆和原始会话之间放了 daily notes，不用只依赖一份长期记忆文件，也不用每次都去翻完整历史。这样，「最近几天发生了什么」就有了一个明确位置。

当然，daily notes 不能变成流水账。今天发生的事可以先记下来，任务结束后该清就清。值得长期保留的，再整理进长期记忆。否则只是把污染从长期记忆挪到了最近记录里。

项目上下文与作用域

coding agent 的项目作用域记忆结构

Coding Agent 的 Memory，核心通常在项目上下文。

写代码时，模型本身通常不缺通用编程知识。真正影响它表现的，是这个 repo 里的局部信息：测试怎么跑，构建怎么跑，哪些命令有风险，哪些目录有特殊约定，之前踩过哪些坑。

这类记忆最重要的是作用域。

举个更具体的例子：同一个 repo 里，apps/web 可能要求所有改动都跑 pnpm test 和 Playwright，services/api 可能走 pytest，infra 目录里的 Terraform 只能 plan 不能 apply。如果 Agent 把这些规则都记成一条「项目经验」，下次改 API 时套用前端测试命令，或者在基础设施目录里误跑高风险命令，就可能影响交付甚至安全。

项目记忆最好按路径、仓库、任务范围拆开。根目录放全局规则，子目录放局部约定，调试经验绑定到具体模块。这样 Agent 才不容易把 A 项目的规矩套到 B 项目。

Claude Code 的 CLAUDE.md 就是很直接的做法。根目录写仓库级规则，子目录写更具体的约定，Agent 工作中发现的构建命令、调试经验、架构笔记再慢慢补进去。人写规则和边界，Agent 沉淀经验和踩坑记录，这两个东西应该分开。

还有一点要说清楚：Memory 文件只是上下文，强制约束要靠系统机制。你把「不要跑生产删除命令」写进 Memory，模型更容易遵守，但安全问题还得靠权限、hook、沙箱、CI 和代码审查来兜底。Memory 负责提醒，系统机制负责拦截。

结构化记忆

轻量记忆记录与结构化事实网络的取舍

很多 Memory 保留在 Markdown 里更自然。写作偏好、daily notes、项目规则、调试经验，本来就更像文档。人能改，模型能读，结构也可以靠 frontmatter、固定标题和固定字段约束。

问题在于，AI 生成 Markdown 时，经常不按字段写。你在提示词里要求它记录「来源、时间、状态、置信度」，它这次可能写全，下次可能漏掉一个字段；这次叫「预算」，下次叫「价格范围」；这次写在列表里，下次写进一段话里。人读起来差不多，系统要合并、更新、统计、推荐、交接时，就很难稳定依赖这些表达。

结构化记忆的价值，是用 structured output / JSON Schema 控制 AI 的记忆输出。字段名、字段类型、枚举值、必填项都提前定好，AI 只负责把对话里的信息填进去。同一个事实每次都落到同一个字段里，后面保存、查询、更新和删除都会清楚很多。

它的第一个好处是可控。你想让 AI 记用户尺码，就让它只能输出 size_type、value、region、confidence、source、updated_at 这些字段。你想让它记销售线索，就定义客户、角色、痛点、反对意见、下一步动作、负责人、更新时间。Prompt 约束当然也有用，但自然语言约束经常不够稳定；JSON Schema 至少能把输出限制在一套确定结构里。

有人可能会问，现在模型已经很强了，还需要这么麻烦吗？真实产品里经常用不了最好的模型。成本、延迟、吞吐、供应稳定性都会影响选择。客服、销售、电商这类场景，很多记忆抽取可能跑在更便宜、更快的模型上。模型能力越不稳定，越需要 Schema 帮它收住输出范围。

第二个好处是好存。固定 JSON 可以直接进文档数据库、关系数据库、KV、图数据库，也可以旁边挂向量索引。Markdown 当然也能存，但如果后面要做筛选、统计、推荐、交接，JSON 字段会省很多解析成本。

第三个好处是好取。系统可以直接读 budget.max、shoe_size.region、brand_loyalty.level、relationship.role、event.occurred_at，不用每次把一段 Markdown 扔给模型重新解释。推荐商品时读尺码和预算，销售交接时读痛点和下一步动作，企业知识图谱里读人物关系和事件关系，都更稳定。

第四个好处是好改。字段级更新比改整段 Markdown 清楚。用户预算变了，就更新预算字段；销售负责人换了，就更新 owner；某个判断过期了，就改 status 或 expired_at。冲突、撤销、删除、审计也更容易做。

适合结构化的，通常是关系密、变化频繁、后续还要被业务使用的记忆。企业里的人物关系和事件就是例子：谁负责哪个客户，谁参与了哪次会议，某个反对意见出现在哪个项目或续约节点。电商里也一样：用户品味、尺码偏好、预算范围、品牌忠诚度、跨访问浏览模式。销售团队共享客户记忆也很典型：客户历史、偏好、痛点、反对意见、下一步动作，需要不同销售代表接手时直接读到同一套信息。

如果再往前走，就是知识图谱式记忆。人、公司、项目、事件、产品、偏好变成实体，负责、参与、反对、购买、影响这些变成关系。Agent 回忆时除了在文本里搜关键词，还可以沿着关系找：这个客户和哪些销售聊过，哪个事件改变了预算，谁影响采购决策，某个痛点最早在哪次沟通里出现。这里的 Schema 已经扩展到实体类型、关系类型、时间和来源。

结构化不必作为默认选项。写作风格、项目说明、daily notes、调试经验，Markdown 往往更合适。需要控制 AI 的记忆输出、需要字段一致、需要跨人或跨 Agent 共享、需要查询统计或业务动作时，再引入 JSON Schema。Mem0 的 metadata/categories、MemOS 的 MemCube/lifecycle/governance，都可以理解成这条路上的不同实现：让 Memory 从自由文本，变成可以被系统稳定保存和消费的对象。

用户理解要和 Profile 分开

用户建模中事实与推断分离的记忆架构

还有一类 Memory 更敏感：用户理解，或者叫用户模型。

它和前面说的 profile 要分开看。Profile 更像一份稳定背景，适合放用户明确说过、长期有效、每次对话都可能有用的信息，比如语言偏好、技术栈、常用项目、回答风格。它在上下文工程里的位置也比较明确：通常在会话开始时进入系统提示词，作为默认背景使用。

用户理解更像一组会变化的判断。它关心的是「用户现在可能需要什么」。这类信息不适合长期固化在系统提示词里，更适合在特定场景下动态载入，作为当前任务的一段参考上下文。

教学助手是典型例子。Profile 可以记录「用户在学线性代数」「偏好中文解释」「希望先看例子」。用户理解要处理的是另一件事：最近几次练习里，他是否都卡在矩阵乘法的含义上？他现在是完全不会，还是会做但不熟？下一轮是该直接讲概念，还是先给一个更小的例子？这些判断只对当前学习阶段有用，不适合变成永久背景。

这部分最容易做错的地方，是把用户理解写进 profile。

比如用户说「我最近很忙」，这句话可以影响当前这段时间的建议：少给复杂方案，少安排额外任务。把它写成长期 profile「用户时间紧」就会出问题。再比如教学产品发现用户连续几次卡在矩阵乘法，这可以影响下一节课怎么讲，但不适合写成用户长期属性。它更适合放在动态上下文里，带上来源和时间，用完之后还能被新的学习表现覆盖。

用户理解的重点在于控制这些判断怎么进入 Prompt。稳定事实进 profile；阶段性判断按场景读；模型推出来的东西要能被后续行为推翻。否则 Memory 会把一次临时状态写成长期背景。

很多产品用不上用户模型。查天气、翻译、查资料、生成摘要，价值不来自长期理解用户。强行加用户模型，只会增加成本和调试难度。只有当产品体验真的依赖长期个性化，比如学习、陪伴、教练、长期项目协作，用户理解才值得进入 Memory 设计。

回到设计：Memory 其实是在设计上下文

Agent Memory 设计的五组核心关系

前面这些形态看起来不一样，最后都会回到同一件事：这条信息怎么进入上下文。

第一，是固化还是动态载入。用户长期偏好、固定环境信息、稳定项目背景，可以放进 profile 或系统提示词，作为默认背景。当天进度、最近决定、某个 repo 的局部规则，更适合按时间、路径、任务动态载入。否则默认上下文会越来越厚，真正重要的信息反而被淹掉。

第二，什么时候读，怎么读。有些信息每次都该出现，比如语言偏好、常用项目、当前任务边界。有些信息只在用户问到时才需要，比如几个月前某次讨论、历史工单、旧版本的调试记录。这里还要考虑上下文缓存：稳定内容尽量固定在同一位置，动态内容按需追加，避免 Memory 频繁变化影响缓存命中率。

第三，是事实、规则、状态，还是推断。事实要有来源和时间，规则要有作用域，任务状态要能过期，用户理解只能作为带置信度的判断。把这些信息都写成同一种 Memory，Agent 很容易把临时状态当长期偏好，把系统推断当用户事实。

第四，是谁来更新。用户明确说「记住」当然要写；用户纠正了旧信息，也要更新。项目规则、工具经验、任务状态，可以由 Agent 在合适时机整理，但自动写入越多，越需要过滤、去重和审查。Memory 写入不追求勤快，关键是不要把噪音写成长期上下文。

第五，什么时候清理。Memory 系统不能只写不删。任务结束了，临时状态就该消失；用户改主意了，旧偏好就要失效；几周前的「昨天」必须变成具体日期，或者干脆从默认上下文里移出去。否则 Memory 会慢慢变成一堆看似有用、实际会误导模型的旧信息。

几个容易踩的坑

第一个坑，把 Memory 做成纯历史搜索。

历史搜索当然有用，但它只能回答「过去哪里提到过」。它不会自动告诉你这条信息现在还是否有效，也不会判断它该不该默认进入 Prompt。把聊天记录切块全丢进去，最多得到一个历史检索系统，离真正可用的 Memory 还差一步。

第二个坑，把所有历史都塞进 Prompt。

这就是上下文污染。Agent 带着一堆无关历史干当前的活，成本上去了，注意力下来了，行为更不可控。Memory 要解决的是哪些过去值得出现，不能把过去全部搬进来。

第三个坑，只有长期画像，没有最近工作状态。

个人助手最容易这样。它记得你的职业、语气和长期偏好，却不知道昨天刚做了什么决定。很多时候，「你了解我」这句承诺没有用，用户需要的是「你能接得上刚才那件事」。

第四个坑，把临时判断写成长期背景。

用户说过一句「最近很忙」，可以影响最近几次安排，但不该一直留在 profile 里。教学产品判断用户最近卡在某个概念，也应该随着后续练习变化。用户理解如果没有来源、时间和覆盖机制，很快会污染 profile。

第五个坑，只写不清理。

过期记忆比没有记忆更麻烦。被推翻的结论还留着，三周前写下的「昨天」没人知道指哪天，重复条目互相打架，都会让 Agent 带着错误背景工作。

OpenClaw 的 Dreaming 处理的就是短期信号到长期记忆的整理问题。它默认关闭，打开后会在后台做记忆整理：Light 阶段整理和暂存近期材料，REM 阶段提炼主题，Deep 阶段按分数、召回次数、查询多样性等条件筛选，只有通过门槛的内容才会写进 MEMORY.md。DREAMS.md 主要给人看，方便回看系统这次整理了什么。

这个设计有一个很重要的点：daily notes 可以承接短期上下文，但不能把 daily notes 里的内容一股脑追加进 MEMORY.md。只有反复出现、仍然有效、以后默认需要的内容，才适合整理进长期记忆。DREAMS.md 的作用是让人看到这次整理大概发生了什么，避免长期记忆变成一个黑箱。

按产品问题选择 Memory 形态

按产品问题选择 Agent Memory 模式的决策地图

个人助理先解决连续性。默认 profile 让 Agent 知道用户的稳定背景，今天/昨天的工作记忆让它接得上最近的事，历史搜索负责查更早的对话。对这类产品来说，最怕的是明明昨天刚定过方案，今天又像第一次听说。

Coding Agent 先解决作用域。repo 规则、目录约定、测试命令、危险操作边界，都要跟路径和项目绑定。它不需要先理解用户性格，把 A 目录的经验套到 B 目录就已经足够危险。

客服、运营、企业流程类产品，往往也会先从 Markdown 或自然语言摘要做起。早期先把客户偏好、工单状态、沟通记录整理出来，已经能解决一部分连续性问题。等到这些记忆开始参与通知、分派、升级、权限、审计、用户自助修改，就需要逐步过渡到结构化记忆。关键是字段要稳定，后续动作才知道该读哪一项、改哪一项、撤销哪一项。

教学、陪伴、教练类产品更需要用户理解。因为这类产品的价值来自长期互动：知道用户最近卡在哪里，知道当前状态适合怎样的解释方式，也知道哪些判断已经被新的表现推翻。

第一版不用追求完整。个人助手先做 profile、最近连续性和历史搜索；Coding Agent 先管好项目作用域；会驱动动作的产品从 Markdown 起步，再逐步结构化；用户理解等产品真的依赖长期个性化再做。Schema 应该被管理需求逼出来，不要为了架构看起来完整提前设计一大套。

结语

我现在看 Agent Memory，不太关心它到底叫长期记忆、短期记忆、用户画像，还是 RAG。名字不重要，重要的是它最后怎么进入 Prompt。

一条信息进入 Prompt 之前，应该先经过评估。它现在还有效吗？它属于当前用户、当前项目，还是当前任务？它应该每次默认出现，还是只在用户问到时搜索？它是用户明确说过的事实，还是模型根据互动推出来的判断？如果用户改了主意，它能不能被更新或删除？这些都属于评估阶段。Memory 写进去只是开始，真正影响体验的是每次使用前怎么判断它该不该进上下文。

这些问题想不清楚，Memory 很快会变成另一个历史仓库。看起来什么都记了，实际每次还是要模型自己在一堆旧信息里判断哪些能用。上下文窗口再大，也不该拿来承受这种混乱。

好的 Memory 设计，核心是控制信息进入上下文的方式。该默认出现的，稳定放进去；该按需查的，保留来源再查；该过期的，及时移走；该让用户改的，就不要藏在系统内部。做到这里，Memory 才能从「存历史」变成改善 Agent 连续性和可靠性的基础设施。

读完 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 产品的基石。