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

这篇文章的直接触发点，来自一张由读者提供的微博截图。截图里的核心判断是：龙虾以及各种 Agent 后续迭代能积累的东西，不是数据，也不是模型本身，而是一种 knowhow；你做文档龙虾，它积累的是文档处理类 knowhow；你做工业龙虾，它积累的是工业分类 knowhow；这种记忆 knowhow 还可以迁移，这才是目前最有用的部分。

我认为这句话非常值得展开，因为它把很多人对 Agent 的一个常见误解点破了。我们总以为 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 喂再多历史日志，如果没有把这些经验性做法提炼成可执行的规则，它也只是“看过很多数据”；只有当它开始记住什么现象意味着什么风险、什么情况下先停机还是先降级、什么参数组合最值得复查时，knowhow 才真正形成。

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

1. 文档处理
- 版式识别
- 模板映射
- 字段校验
- 人工复核条件

2. 工业 / 运维
- 告警分级
- 异常模式库
- 排障顺序
- 升级与回滚策略

3. 客服 / 销售 / 交付
- 历史工单复用
- 话术与升级规则
- 客户偏好与限制
- 成功路径与失败案例

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

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

第二条最佳实践，是让记忆升级有门槛。不是每一轮对话都值得进入长期记忆，更不是每个成功案例都自动抽象成规则。比较稳妥的做法，是让 Agent 先生成候选记忆或候选规则，再由轻量 grader、离线 eval 或人工抽查决定是否晋升。OpenAI 的 eval best practices 强调 eval-driven development，Anthropic 也强调代表性测试集和针对失败案例的工具改进，这些都指向同一件事：没有评估，就没有可靠 knowhow。

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

第四条最佳实践，是给每条长期 knowhow 加上来源、适用范围和失效条件。经验型规则最怕被无条件复用。一个在某个客户、某个工厂、某类文档上成立的模式，换场景后很可能失效。最稳妥的做法，是把 provenance、时间戳、适用域和最后验证结果一起存下来。这样 Agent 学到的就不是“绝对真理”，而是“在什么条件下大概率有效的经验”。

第五条最佳实践，是从单 Agent、强工具、强评估开始，不要一上来就多智能体。OpenAI 官方文档已经明确提醒：是否需要 multi-agent architecture 应当由 evals 决定，起手就上多智能体只会增加复杂性。很多团队还没把一个 Agent 的记忆层、工具层和评估层跑顺，就急着上协作网络，结果只是把噪音放大。先把一个 Agent 的 knowhow 闭环打通，比同时起十个 Agent 更重要。

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

{
  "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 系统。这件事，可能比很多人现在意识到的更重要。