出处先说明白：这篇文章从哪句话开始

这篇文章的直接触发点，来自一张由读者提供的微博截图。截图里的核心判断很简洁：Agent 后续真正能积累下来的，并不只在数据本身，也不只在模型本身，更在一种可以迁移的 knowhow。文档类 Agent 会沉淀文档处理 knowhow，工业类 Agent 会沉淀工业分类和处置 knowhow，而且这种 knowhow 还能迁移。

这句话值得展开，原因不在它新鲜，而在它恰好戳破了一个常见误解。很多人一谈 Agent 资产，第一反应要么是模型权重，要么是私有数据。但在真实系统里，原始数据更像素材，模型更像底座，真正会随着任务反复运行而越来越值钱的，往往是任务怎么拆、工具怎么用、异常怎么兜、结果怎么验这些做事的方法。

为了避免把一句直觉判断写成口号，下面我会尽量只用可核对的公开来源来支撑它。那张微博截图只是写作线索，不作为正式参考；技术判断和场景分析，以下面的官方文档、论文和产品资料为主。

把这句话拆开看，更稳妥的理解是：

• 价值不主要落在原始数据本身。
• 价值也不主要落在模型权重本身。
• 更值得长期积累的是任务分解方式、工具选择与调用顺序、异常处理规则、验证与回滚标准、领域经验判断，以及可迁移的流程化做法。

为什么说 Agent 积累的是 knowhow，重点在“怎么把事做成”

第一条证据，来自主流 Agent 官方文档对系统结构的描述。Anthropic 在《Building Effective AI Agents》里明确把重点放在 workflows、agents 和 tools 这些系统要素上，并且直说：无论构建哪种 agentic system，工具都很可能是代理的重要组成部分，工具定义和规格应当像整体提示词一样被认真工程化。这种表述非常关键，因为它说明能力并不会只靠“多会一点知识”自动长出来，更依赖工具接口、调用约束和执行路径被设计出来。

Anthropic 在《Building agents with the Claude Agent SDK》里又给了一个更直接的 agent loop：gather context -> take action -> verify work -> repeat。这几乎已经把 knowhow 的主体说出来了。一个 Agent 长期沉淀的，重点不在上下文片段本身，而在它遇到什么任务该搜什么、该做什么、该如何验证、何时重试、何时停止。换句话说，它积累的是“怎么做事”的套路，不只是“背下了什么文本”。

第二条证据，来自状态化 Agent 和外部记忆系统。Letta 的文档把 stateful agents 定义为能够跨会话维持 memory 和 context 的代理，并明确写到：当 LLM agent 与世界交互时，它会累积 state，包括 learned behaviors、关于环境的事实，以及过去交互的记忆。Letta 对 archival memory 的定义也很清楚：这是一个语义可检索的长期存储层，适合存放 facts、knowledge 和 reference material，不该长期充当塞满上下文的工作记忆。更重要的是，它给出的真实例子没有停在抽象口号，直接落到“30k+ 记忆的个人知识管理代理”“32k+ 记忆的社交代理”，以及一个会从历史支持工单中学习成功解决方案的客户支持代理。

第三条证据，来自对长期记忆系统的研究与工程实现。MemGPT 论文用操作系统分层的思路处理上下文限制，论文摘要里明确写到，它能让多轮会话代理在长期交互中“remember, reflect, and evolve dynamically”。这句话的重点，既在“记住”，也在“反思并演化”。真正的 knowhow，恰恰出现在记忆脱离原样存档、开始在运行中被筛选、提炼、复用的时候。

• 工具是执行能力的主体，knowhow 很大一部分就嵌在工具规格、调用顺序和错误恢复里。
• 长期记忆更重要的工作，是把值得保留的规律抽成可检索的结构。
• 状态化 Agent 最值钱的地方，在于它知道什么值得记、什么时候该取、取出来后怎么用。

为什么这也意味着“微调有用，但优先级正在后移”

很多人会顺着这个话题继续往前推，得出一个更激进的结论：模型微调是不是已经没意义了？我觉得这个判断不能说得这么满，但它的优先级确实在下降。OpenAI 的 fine-tuning best practices 里有一个很值得注意的建议：把在微调之前已经对模型效果最好的 instructions 和 prompts，保留到每条训练样本中。这个细节说明，即便做了微调，系统仍然高度依赖原有的提示、规则和任务定义。那些工程层资产，单靠微调承接不了。

OpenAI 同一份文档还反复强调数据质量、一致性、训练集与测试集划分，以及任务评估的重要性。换句话说，微调更适合那些目标稳定、标签清楚、输出形式明确的任务，比如分类、抽取、结构化解析、固定风格生成。它当然有价值，但它更像是在已有规则清晰之后，对特定环节做模型内收敛，不该被拿来承担工作流、记忆和工具设计这些职责。

这也是为什么我更赞同把 Agent 的长期资产理解为 knowhow，而不赞同“把所有行业知识都塞进模型里”这种想法。模型权重当然是能力基础，但企业和团队真正能积累、迭代、迁移、审计、复盘的部分，更多是外部化的：提示词、工具接口、任务模板、评估集、故障库、规则库和长期记忆层。模型是发动机，knowhow 更接近驾驶方法、操作手册和维修经验。

更稳妥的判断可以记成两组：

• 微调更适合：稳定任务、高一致性标签、明确输出格式，以及希望把成本或延迟继续压低的场景。
• 长期 knowhow 更适合沉淀在：system prompt、工具描述、外部记忆、工作流模板、评估与回放数据、失败案例库。

公开数据能支持到什么程度

如果只看理论，这件事还容易流于概念。公开数据虽然还不够完整，但已经能给出几个方向性的支持。第一，Mem0 官网公开展示的 benchmark 声称，它相对 OpenAI memory 在 response quality、latency 和 token savings 上有优势，其中一个最常被引用的数字是“26% 更高的 response quality 与 90% 的 token 节省”。这里我要特别强调，这是厂商自家的 benchmark，应该当作方向性信号，而不该被直接当成行业定论。但它至少说明一件事：当记忆层做得更有选择、更结构化时，效果和成本都可能明显改善。

第二，Letta 官方文档给出的几个实例也很有意思。它没有停在“有长期记忆”这种抽象说法，直接给出 30k+、32k+ 这类量级的 archival memories，并把支持代理的价值写得非常具体：存储 ticket resolutions、常见问题、按产品和优先级打标签、搜索类似历史问题、从成功解决方案中学习。这个例子和微博里那句“文档龙虾沉淀文档 knowhow、工业龙虾沉淀工业 knowhow”在结构上高度相通。

第三，OpenAI 和 Anthropic 的最佳实践都把 evals 放到了非常靠前的位置。OpenAI 的 evaluation best practices 甚至明确提醒：是否要做 multi-agent architecture，应该由 evals 驱动，直接从多智能体开始只会引入额外复杂度。这同样从反面说明，Agent 的长期价值不在于架构名词越来越多，而在于是否能把有效做法沉淀下来，并通过可重复评估不断收敛成 knowhow。

• Mem0 的“26% 更高质量、90% 更少 tokens”是厂商自报 benchmark，价值在于提供方向，不应当作独立审计后的行业结论。
• Letta 用 30k+、32k+ 长期记忆实例展示了：记忆层早已超出玩具级功能，开始承载长期交互和机构知识。
• OpenAI 与 Anthropic 都把评估、工具、工作流和上下文管理放在很前面，这和“knowhow 才是资产”的判断高度一致。

如果把这个判断往前推，最先成立的会是哪几类场景

第一类是文档处理型 Agent。微博原话里提到“文档龙虾”，这是一个很好的例子。文档处理真正有价值的部分，不在再背一遍 PDF，而在逐渐形成一套稳定的处理 knowhow：哪种版式先 OCR，哪类表格优先走结构化抽取，哪些字段必须交叉验证，哪些票据需要人工复核，哪些模板之间最容易混淆。这套东西一旦沉淀下来，就能跨客户、跨项目、跨时间复用。

第二类是工业与运维型 Agent。工业场景里的 knowhow 往往不是教材式知识，更常见的是异常模式、经验阈值、告警优先级、巡检顺序、供应商联络路径和补救脚本。你给 Agent 喂再多历史日志，如果没有把这些经验性做法提炼成可执行的规则，它也只是“看过很多数据”；只有当系统开始记住什么现象意味着什么风险、什么情况下先停机还是先降级、什么参数组合最值得复查时，这些经验才会真正成形。

第三类是客服、销售和交付支持型 Agent。Letta 文档里提到的支持代理非常典型。一个长期运行的客服 Agent 最值钱的部分，不在单次回答本身，而在它会越来越懂：哪些问题应先检索历史解决单，哪些客户要优先升级，哪些产品线最常出现联动问题，哪类承诺不能随便给，哪类话术最能降低误解和重复工单。这些都是业务 knowhow，不会从基础模型里天然长出来。

三类最可能率先跑通的 knowhow 场景，可以先这样看：

• 文档处理：版式识别、模板映射、字段校验、人工复核条件。
• 工业 / 运维：告警分级、异常模式库、排障顺序、升级与回滚策略。
• 客服 / 销售 / 交付：历史工单复用、话术与升级规则、客户偏好与限制、成功路径与失败案例。

真正可落地的最佳实践：不要把记忆当垃圾堆，要把 knowhow 当资产

如果接受“Agent 迭代沉淀的是 knowhow”这个判断，那么实践层最重要的事，就不该是盲目拉长上下文，而该是设计一套让 knowhow 能形成、能验证、能迁移、也能淘汰的系统。第一步，是把数据、状态和 knowhow 明确分层。规范文档、数据库记录、知识库内容属于 canonical knowledge；当前任务里的中间变量和临时结论属于 working state；只有那些在多个任务里反复证明有效的规则、模板、异常模式和验证标准，才值得被抬升成长期 knowhow。

第二步，是给记忆升级设门槛。并非每一轮对话都值得进长期记忆，也并非每个成功案例都应该直接抽象成规则。更稳妥的做法，是让 Agent 先生成候选记忆或候选规则，再由轻量 grader、离线 eval 或人工抽查决定它是否配得上“长期资产”这个身份。OpenAI 和 Anthropic 都把 eval 放得很前面，原因就在这里：没有评估，就没有可靠 knowhow。

第三步，是尽量把 knowhow 外部化。别把高价值经验只埋在黑箱 embedding 里，而要同步沉淀成人类可读、机器可用的结构化资产，比如 Markdown playbook、JSON policy、tool schema、校验清单、失败样例集、路由规则和审批条件。这样做的好处很现实：可审计、可版本化、可迁移、可回滚，也更容易跨模型、跨供应商、跨 Agent 继承。

最后一点常被低估：每条长期 knowhow 都应该有来源、适用范围和失效条件。经验规则最怕被无条件复用。一个在某个客户、某个工厂、某类文档上成立的模式，换个场景很可能就失效。把 provenance、时间戳、适用域和最近一次验证结果一起存下来，Agent 学到的就不会变成“绝对真理”，而更接近“在什么条件下大概率有效的经验”。

• 分层：把规范知识、运行状态和长期 knowhow 分开。
• 提炼：只把重复验证有效的模式晋升为长期记忆。
• 外部化：把高价值 knowhow 同步沉淀为可读、可审计、可迁移的结构化资产。
• 带出处：为每条 knowhow 记录来源、时间、适用范围和最近一次验证结果。
• 先单体后协作：先把单 Agent 闭环做好，再决定要不要多智能体。

一份可执行的 knowhow 存储模板，可以长这样：

{
  "name": "invoice_table_extraction_rule_v3",
  "type": "procedure",
  "scenario": "增值税发票表格抽取",
  "rule": [
    "先判断版式是否旋转",
    "金额字段必须与税额字段交叉校验",
    "若抬头缺失则进入人工复核"
  ],
  "evidence": [
    "run_2026_03_14_001",
    "run_2026_03_14_017",
    "run_2026_03_15_004"
  ],
  "owner": "doc-agent",
  "scope": "invoice-processing",
  "last_verified_at": "2026-03-14",
  "expiry_policy": "30_days_recheck"
}

最后收束成一个判断

所以回到那条微博的原判断，我的结论是：它大体是对的，但需要被工程化地理解。Agent 真正积累的，当然不只在“数据”，也不只在“模型”，更是那套能在系统外部被观察和管理的 knowhow。它体现为任务路径、工具协议、验证标准、异常处理、领域经验和可迁移的操作方法。

这也解释了为什么很多团队会感觉：同样一个底座模型，换一套记忆层、工具层和评估闭环，Agent 的实用性会完全不同。差异不一定来自底层模型换代，而更可能来自谁更早把那些隐性的业务经验显性化、结构化并可持续迭代。

如果未来两三年 Agent 真的会成为主流软件形态的一部分，那么最应该被重视的资产，未必是“我有多少私有数据”，也未必是“我是不是自己训了个模型”，真正该问的是：我是否拥有一套会随着任务执行不断积累、又能够迁移给下一代 Agent 的 knowhow 系统。这件事，可能比很多人现在意识到的更重要。

更新附注

• 版本：v1.1

更新日期：2026-03-31 更新原因：重写开头和最佳实践段，减少概念堆叠，把“knowhow 是资产”的判断落到更明确的工程分层和记忆门槛上。