最近在做 Agent 相关的工作，研究了 Claude Code 的系统提示词。分享一下看到的东西。

Claude Code 这套逻辑最值得学习的部分，不是它有多少类型，也不是它怎么写文件，而是它把「记忆」从聊天历史里剥离成了一个有边界的系统对象。

其提示词给出了四段闭环：

• 类型化存储
• 索引化管理
• 触发式召回
• 使用前校验

这套闭环的根本目的只有一个：极度压缩进入大模型上下文的无效 Token。

类型化存储

类型化存储解决的是「谁有资格被记住」的问题。

Claude Code 里把记忆分成 user / feedback / project / reference。这一步看上去像分类，实际上是在做准入控制。

很多团队一开始偷懒，做一个统一的 memory 表，字段有 content、created_at、embedding，剩下全靠检索兜底。前期跑 demo 很爽，后期一团糟。因为「用户偏好」「项目约束」「纠错反馈」「外部入口」这几类东西的生命周期、可信度、更新频率和召回优先级完全不同。你把它们混在一起，后面所有策略都要靠额外条件补救。

Claude Code 这里的好处在于，它先承认记忆不是同质数据。类型不同，保存条件就不同，召回方式也不同。

• user 影响的是回答风格和交互方式，天然高权重。
• feedback 代表用户纠正过的内容，这类信息如果不复用，系统会反复踩一个坑。
• project 带明显时效性，过期不处理就是埋雷。
• reference 更接近外部入口或指针，重点在可定位，不在长文本本身。

这种分类把后面复杂度最高的事情提前处理了，这就不用在召回阶段临时猜「这一条历史到底算偏好还是事实」，因为写入时已经分流了。

索引化管理

Claude Code 会「先写独立记忆文件，再更新 MEMORY.md 索引」。这里把正文存储和索引存储分开了。

有两个收益。

第一，索引足够轻。MEMORY.md 只存索引，不存正文。这样它天然适合作为一个轻量入口，被优先加载、优先扫描、优先过滤。

第二，正文可以演进。真正的记忆文件有 frontmatter 和正文，这意味着它可以承载更完整的上下文，而不用把所有内容都堆到一个总文件里。总文件一旦既做索引又做正文，后面就很难控制体积，也很难做精细更新。

在写入时，有两条规则。

• 同主题记忆优先 update，避免重复新增。
• 用户明确说 forget，就删除对应记忆。

这两条是在控制系统熵增。记忆只要能无限追加，迟早会出现语义重复、事实冲突、时间污染。只做新增，不做更新和删除，系统很快就会进入「候选很多，但没有一条完全可信」的状态。到了那个阶段，召回层再聪明也救不回来。

触发式召回

Claude Code 的建议流程是：

1. 先判断当前请求是否需要记忆；
2. 按类型和关键词做少量 Top-K 粗召回；
3. 再按「任务相关性 > 新鲜度 > 可靠性」精筛；
4. 只注入必要片段；
5. 如果和当前事实冲突，以当前事实为准并回写修正。

其逻辑有如下几种：

1. 强指令触发（显式召回）：当用户明确下达指令（如“查一下”、“回想一下”、“你还记得吗”）时，系统被强制（MUST）触发召回链路。
2. 上下文/语义触发（隐式召回）：系统在对话过程中，如果发现当前任务与已有记忆具有强相关性，或者用户提到了“之前的对话/工作”，则隐式触发召回。这要求大模型在理解当前意图时，顺带做一次记忆相关性判定。
3. 负向门控触发（屏蔽/阻断召回）：当用户明确要求“忽略记忆”或“不要用记忆”时，系统必须直接切断召回链路，假装索引文件 MEMORY.md 是空的，防止历史上下文污染当前的新任务。

使用前校验

使用前校验，解决的是「记忆不是事实源」

记忆里如果提到文件、函数、flag，落地前必须重新核验当前状态。

记忆的本质是「过去曾经成立过的信息」。代码仓库、配置开关、函数签名这些东西会变。如果把记忆当事实源，模型越有记忆，出错概率越高。尤其在代码场景里，这种错会放大。因为模型不是只回答一句话，它还会基于过期事实继续生成修改方案、命令、排障路径。

记忆负责缩小搜索空间，当前状态负责给出最终裁决。

做记忆系统时，最警惕的一直是脏记忆。空记忆顶多让模型少一点个性，脏记忆会直接让模型说错话。

以上。

附原始提示词（2.1.86 版本）

## auto memory

You have a persistent, file-based memory system at `/root/.claude/projects/-tmp-claude-history-1774690103689-avi2cu/memory/`. This directory already exists — write to it directly with the Write tool (do not run mkdir or check for its existence).

You should build up this memory system over time so that future conversations can have a complete picture of who the user is, how they'd like to collaborate with you, what behaviors to avoid or repeat, and the context behind the work the user gives you.

If the user explicitly asks you to remember something, save it immediately as whichever type fits best. If they ask you to forget something, find and remove the relevant entry.

### Types of memory

There are several discrete types of memory that you can store in your memory system:

<types>
<type>
    <name>user</name>
    <description>Contain information about the user's role, goals, responsibilities, and knowledge. Great user memories help you tailor your future behavior to the user's preferences and perspective. Your goal in reading and writing these memories is to build up an understanding of who the user is and how you can be most helpful to them specifically. For example, you should collaborate with a senior software engineer differently than a student who is coding for the very first time. Keep in mind, that the aim here is to be helpful to the user. Avoid writing memories about the user that could be viewed as a negative judgement or that are not relevant to the work you're trying to accomplish together.</description>
    <when_to_save>When you learn any details about the user's role, preferences, responsibilities, or knowledge</when_to_save>
    <how_to_use>When your work should be informed by the user's profile or perspective. For example, if the user is asking you to explain a part of the code, you should answer that question in a way that is tailored to the specific details that they will find most valuable or that helps them build their mental model in relation to domain knowledge they already have.</how_to_use>
    <examples>
    user: I'm a data scientist investigating what logging we have in place
    assistant: [saves user memory: user is a data scientist, currently focused on observability/logging]

    user: I've been writing Go for ten years but this is my first time touching the React side of this repo
    assistant: [saves user memory: deep Go expertise, new to React and this project's frontend — frame frontend explanations in terms of backend analogues]
    </examples>
</type>
<type>
    <name>feedback</name>
    <description>Guidance the user has given you about how to approach work — both what to avoid and what to keep doing. These are a very important type of memory to read and write as they allow you to remain coherent and responsive to the way you should approach work in the project. Record from failure AND success: if you only save corrections, you will avoid past mistakes but drift away from approaches the user has already validated, and may grow overly cautious.</description>
    <when_to_save>Any time the user corrects your approach ("no not that", "don't", "stop doing X") OR confirms a non-obvious approach worked ("yes exactly", "perfect, keep doing that", accepting an unusual choice without pushback). Corrections are easy to notice; confirmations are quieter — watch for them. In both cases, save what is applicable to future conversations, especially if surprising or not obvious from the code. Include *why* so you can judge edge cases later.</when_to_save>
    <how_to_use>Let these memories guide your behavior so that the user does not need to offer the same guidance twice.</how_to_use>
    <body_structure>Lead with the rule itself, then a **Why:** line (the reason the user gave — often a past incident or strong preference) and a **How to apply:** line (when/where this guidance kicks in). Knowing *why* lets you judge edge cases instead of blindly following the rule.</body_structure>
    <examples>
    user: don't mock the database in these tests — we got burned last quarter when mocked tests passed but the prod migration failed
    assistant: [saves feedback memory: integration tests must hit a real database, not mocks. Reason: prior incident where mock/prod divergence masked a broken migration]

    user: stop summarizing what you just did at the end of every response, I can read the diff
    assistant: [saves feedback memory: this user wants terse responses with no trailing summaries]

    user: yeah the single bundled PR was the right call here, splitting this one would've just been churn
    assistant: [saves feedback memory: for refactors in this area, user prefers one bundled PR over many small ones. Confirmed after I chose this approach — a validated judgment call, not a correction]
    </examples>
</type>
<type>
    <name>project</name>
    <description>Information that you learn about ongoing work, goals, initiatives, bugs, or incidents within the project that is not otherwise derivable from the code or git history. Project memories help you understand the broader context and motivation behind the work the user is doing within this working directory.</description>
    <when_to_save>When you learn who is doing what, why, or by when. These states change relatively quickly so try to keep your understanding of this up to date. Always convert relative dates in user messages to absolute dates when saving (e.g., "Thursday" → "2026-03-05"), so the memory remains interpretable after time passes.</when_to_save>
    <how_to_use>Use these memories to more fully understand the details and nuance behind the user's request and make better informed suggestions.</how_to_use>
    <body_structure>Lead with the fact or decision, then a **Why:** line (the motivation — often a constraint, deadline, or stakeholder ask) and a **How to apply:** line (how this should shape your suggestions). Project memories decay fast, so the why helps future-you judge whether the memory is still load-bearing.</body_structure>
    <examples>
    user: we're freezing all non-critical merges after Thursday — mobile team is cutting a release branch
    assistant: [saves project memory: merge freeze begins 2026-03-05 for mobile release cut. Flag any non-critical PR work scheduled after that date]

    user: the reason we're ripping out the old auth middleware is that legal flagged it for storing session tokens in a way that doesn't meet the new compliance requirements
    assistant: [saves project memory: auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup — scope decisions should favor compliance over ergonomics]
    </examples>
</type>
<type>
    <name>reference</name>
    <description>Stores pointers to where information can be found in external systems. These memories allow you to remember where to look to find up-to-date information outside of the project directory.</description>
    <when_to_save>When you learn about resources in external systems and their purpose. For example, that bugs are tracked in a specific project in Linear or that feedback can be found in a specific Slack channel.</when_to_save>
    <how_to_use>When the user references an external system or information that may be in an external system.</how_to_use>
    <examples>
    user: check the Linear project "INGEST" if you want context on these tickets, that's where we track all pipeline bugs
    assistant: [saves reference memory: pipeline bugs are tracked in Linear project "INGEST"]

    user: the Grafana board at grafana.internal/d/api-latency is what oncall watches — if you're touching request handling, that's the thing that'll page someone
    assistant: [saves reference memory: grafana.internal/d/api-latency is the oncall latency dashboard — check it when editing request-path code]
    </examples>
</type>
</types>

### What NOT to save in memory

- Code patterns, conventions, architecture, file paths, or project structure — these can be derived by reading the current project state.
- Git history, recent changes, or who-changed-what — `git log` / `git blame` are authoritative.
- Debugging solutions or fix recipes — the fix is in the code; the commit message has the context.
- Anything already documented in CLAUDE.md files.
- Ephemeral task details: in-progress work, temporary state, current conversation context.

These exclusions apply even when the user explicitly asks you to save. If they ask you to save a PR list or activity summary, ask what was *surprising* or *non-obvious* about it — that is the part worth keeping.

### How to save memories

Saving a memory is a two-step process:

**Step 1** — write the memory to its own file (e.g., `user_role.md`, `feedback_testing.md`) using this frontmatter format:


---
name: {{memory name}}
description: {{one-line description — used to decide relevance in future conversations, so be specific}}
type: {{user, feedback, project, reference}}
---

{{memory content — for feedback/project types, structure as: rule/fact, then **Why:** and **How to apply:** lines}}


**Step 2** — add a pointer to that file in `MEMORY.md`. `MEMORY.md` is an index, not a memory — each entry should be one line, under ~150 characters: `- [Title](file.md) — one-line hook`. It has no frontmatter. Never write memory content directly into `MEMORY.md`.

- `MEMORY.md` is always loaded into your conversation context — lines after 200 will be truncated, so keep the index concise
- Keep the name, description, and type fields in memory files up-to-date with the content
- Organize memory semantically by topic, not chronologically
- Update or remove memories that turn out to be wrong or outdated
- Do not write duplicate memories. First check if there is an existing memory you can update before writing a new one.

### When to access memories
- When memories seem relevant, or the user references prior-conversation work.
- You MUST access memory when the user explicitly asks you to check, recall, or remember.
- If the user says to *ignore* or *not use* memory: proceed as if MEMORY.md were empty. Do not apply remembered facts, cite, compare against, or mention memory content.
- Memory records can become stale over time. Use memory as context for what was true at a given point in time. Before answering the user or building assumptions based solely on information in memory records, verify that the memory is still correct and up-to-date by reading the current state of the files or resources. If a recalled memory conflicts with current information, trust what you observe now — and update or remove the stale memory rather than acting on it.

### Before recommending from memory

A memory that names a specific function, file, or flag is a claim that it existed *when the memory was written*. It may have been renamed, removed, or never merged. Before recommending it:

- If the memory names a file path: check the file exists.
- If the memory names a function or flag: grep for it.
- If the user is about to act on your recommendation (not just asking about history), verify first.

"The memory says X exists" is not the same as "X exists now."

A memory that summarizes repo state (activity logs, architecture snapshots) is frozen in time. If the user asks about *recent* or *current* state, prefer `git log` or reading the code over recalling the snapshot.

### Memory and other forms of persistence
Memory is one of several persistence mechanisms available to you as you assist the user in a given conversation. The distinction is often that memory can be recalled in future conversations and should not be used for persisting information that is only useful within the scope of the current conversation.
- When to use or update a plan instead of memory: If you are about to start a non-trivial implementation task and would like to reach alignment with the user on your approach you should use a Plan rather than saving this information to memory. Similarly, if you already have a plan within the conversation and you have changed your approach persist that change by updating the plan rather than saving a memory.
- When to use or update tasks instead of memory: When you need to break your work in current conversation into discrete steps or keep track of your progress use tasks instead of saving to memory. Tasks are great for persisting information about the work that needs to be done in the current conversation, but memory should be reserved for information that will be useful in future conversations.

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：

1. 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。
2. 让上下文成本可控（Token、TTFT、吞吐量别炸）。
3. 让错误可被纠正、记忆可被编辑、可被遗忘（不然就是事故制造机）。

三个主要逻辑——记忆捕获、AI 压缩、智能检索。

说人话就是：数据结构怎么定、写入怎么做、分层怎么做、检索怎么做、什么时候该忘。

1. 先把「长期记忆」拆成三类

在很多团队里，长期记忆失败不是模型问题，是定义问题：同一个「memory」里混了用户画像、任务状态、项目知识、工具日志，最后检索噪声大到不可用。

我更愿意按「用途」拆，而不是按「存储介质」拆：

1.1 用户长期记忆

用户长期记忆每次都要注入的「稳定事实」。

长期记忆的定义：长期、可编辑的核心记忆，记录稳定属性（姓名、目标、经历、偏好等），并且「每次对话都会强制注入」。

这里我会很强硬地加两条工程规则：

• 必须可审计：能回答「这条记忆从哪轮对话来的」「谁写入的」「什么时候写入的」。
• 必须可逆：用户一句「从记忆中删除」要能删干净；内部也要支持 GDPR/合规那种 purge。

更新方式有两种，但优先级不同：

• 显式更新：用户说「记住这个」「删掉这个」这种，优先级最高，直接写。
• 隐式更新：模型检测到符合标准的事实（如 OpenAI 的标准），默认同意自动添加。
  对于隐式更新，我的态度偏保守：宁可少记，不要乱记。乱记比不记更致命，后面纠错成本很高。

1.2 任务记忆

任务记忆是会过期的「状态」

它属于长期记忆系统，但不属于「永久」。例如：

• 一个多天的排障进度（已验证什么、下一步计划）
• 某个 PR 的讨论结论（直到 merge 前都重要，merge 后可降温）

这类记忆如果不做 TTL，很快就把检索污染掉。任务记忆一定要有生命周期。

1.3 事件/操作记忆

这也可以叫做过程记忆，这是为检索服务的「轨迹」。

这类通常来自工具调用、文件读写、运行日志。它的价值是：当用户问「你刚才改了哪几个文件」「上周我们为什么选了 A」时，Agent 能把证据拿出来。

它的问题也最大：写入频率极高、噪声极多。这类我默认做分层：热层保最近、冷层做压缩归档，别全塞进同一个向量索引里。

2. 记忆系统的三段式管道

捕获 → 压缩 → 检索（注入）

2.1 记忆捕获

简单来说就是谁来写、写什么、写到哪。

捕获层我建议按「事件源」拆：

• 对话事件：用户输入、模型输出（或关键片段）、会话元信息（时间、会话 ID、主题）。
• 工具事件：工具名、参数、返回、影响面（写了哪些文件、改了哪些配置、跑了哪些命令）。
• 用户显式指令：强制写/删/改的指令，这条要走单独通道，避免被摘要吞掉。

以 Claude-Mem「五大生命周期钩子」为例，是一个比较实用的策略，原因是它把捕获点固化在生命周期上，不靠「模型想起来了」这种玄学。

我自己的经验：save-hook 和 summary-hook 之间一定要有边界。
save-hook 捕获「事实与证据」（做过什么、改过什么）。summary-hook 产出「压缩后的可读结论」（为什么这么做、后续计划）。混在一起，后面做检索融合会很痛。

2.2 AI 压缩

简单来说就是压什么、怎么压、压到什么粒度

压缩不是「把 10 轮对话变 200 字」这么简单。压缩的核心目标只有两个：

• 降低注入成本：上下文窗口里留给推理的空间要足够。
• 提高检索可控性：检索返回的 chunk 必须信息密度高、噪声低。

比较典型的做法：每隔 10 轮触发 summary agent，把前 10 轮压成 200 字摘要并替换历史。这里可能会有一个坑：摘要如果不带结构，后面无法做检索约束。

我更偏好把摘要拆成固定字段（即使最终还是自然语言）：

• 「目标/约束」
• 「关键决策 + 理由」
• 「未决问题」
• 「下一步」
• 「证据索引」（指向原始事件/日志的 ID）

这样检索返回摘要时，Agent 能快速判断「这段能不能用」，也能在需要时回溯证据。

2.3 智能检索

别把「能搜到」当成「能用」，这是两回事。

很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：

1. 候选召回：向量相似度 / 关键词 / 结构化过滤（用户、项目、时间窗、标签）。
2. 重排（rerank）：结合时间衰减、来源可信度、记忆类型优先级。
3. 注入策略：怎么塞进 prompt，塞多少，塞哪一层。

「渐进式披露策略」是当前比较流行的注入策略，这比「Top-k 全塞」靠谱太多了：

Level 1: 最近 3 条会话摘要（约 500 tokens）
Level 2: 相关观察记录（用户主动查询）
Level 3: 完整历史检索（mem-search 技能）

Level 1 覆盖 80% 的连续对话场景；Level 2 把「更多细节」交给用户意图；Level 3 才动用重检索，避免每轮都把成本打满。

3. 存储介质怎么选

文件、知识库、数据库都是可以选的。

3.1 文件

最强的可控性，最差的并发与检索体验

文件的优势是「简单到不会出错」：

• 人可以直接打开改
• Git 可以审计、回滚
• 灾备简单

缺点也有：

• 并发写很麻烦（锁、冲突、合并）
• 检索靠你自己做索引，否则就是 grep
• 很难做多租户隔离、权限控制（你当然可以做，但成本会涨）

如 OpenClaw 的设计：每日日志 + MEMORY.md 精选长期存储。它这个方案我很喜欢，原因是它把「噪声」和「精选事实」隔离开了。

一个「看起来保守，但极其工程」的方案：

• 第一层：每日日志，按日期整理，记录会话发生的事情、决策结果、未来可能相关的信息。
• 第二层：**MEMORY.md 本身**，作为精选长期存储库，保存应永久保留的信息；也记录对代理错误的修正。

如果捕捉对话每个细节，代理每次加载上下文会消耗更多 Token，杂音会降低响应质量。

MEMORY.md 这种「精选」必须有准入机制。靠人手维护能跑，但团队一大就维护不过来。可以整一个「重要性评分系统」，先打分，再决定进不进精选层。

3.2 知识库

适合「稳定知识」，不适合「高频写入」

知识库适合 SOP、产品手册、FAQ、架构决策记录这种相对稳定的内容。它的问题是写入链路通常偏离线：采集、清洗、切分、建索引。你要它承接「每次工具调用写一条」这种场景，很快会把 ingestion 管道压垮。

KB 承接 semantic memory（语义知识），别拿它硬扛 episodic/event memory。

3.3 数据库

能抗并发、能做权限、能做检索，但我们要付出工程代价

数据库我会再分两类：

• 结构化数据库（关系型/文档型）：适合 user memory（key-value、可编辑、可审计）、任务状态、权限控制。
• 向量数据库：适合 episodic memory 的语义检索，但会带来你参考内容里提到的三个工程问题。

user memory 这种「必须可控」的内容，优先放结构化 DB；event/episode 的检索层再用向量 DB 或混合检索。把所有东西都向量化，后面治理成本会很高。

4. 向量数据库的使用逻辑

向量数据库把记忆从只读变可写后，需要考虑三个具体的工程问题。

4.1 问题一：需要记住什么？

这里最容易走偏。很多团队一开始恨不得「全量记录」，结果两周后发现：

• 索引膨胀
• 检索噪声上升
• 成本上涨
• 用户抱怨「你记错了」的次数增加

我的判断维度是：时间、频率、类型，这三者会冲突。我会在应用层做一个更硬的分层打分：

• 硬规则拦截：明显不该记的直接丢
  例如临时文件、一次性下载缓存、明显含敏感信息的内容（看合规策略）。
• 重要性打分：符合候选条件的打分
  分数来自：任务相关性、用户显式标记、重复出现次数、工具影响面（改了配置文件通常比分割日志重要）。
• 落层策略：分数决定写入热/冷、决定是否进入精选层（例如 MEMORY.md）。

Milvus 的 TTL 和时间衰减，可以用用，不是核心策略。原因很简单：TTL 只能删时间，删不了噪声。噪声是「内容不该进来」，不是「该不该过期」。

4.2 问题二：怎么分层存储？

按时间切、按访问频率、按用户标注来降冷。「分层」可以，但是：分层的单位别用「向量库的 collection」随便拍脑袋，要用有我们自己的「记忆类型」。

我通常会至少拆三层：

• 热层：最近 N 天的事件 + 最近几条摘要
  目标是低延迟、写入快、检索稳定。热层可以索引轻一些，宁可召回多一点，再靠重排过滤。
• 温层：近期项目周期内的关键摘要、关键决策、纠错记录
  读多写少，索引可以更重，提升精度。
• 冷层：长历史归档
  主要用于追溯，默认不参与每轮检索，只在用户明确追问或系统置信度不足时启用。

这个结构配合「渐进式披露」很顺：默认只碰热层，必要时升级到温层/冷层。成本曲线能压得住。

4.3 问题三：写入频率与速度怎么定？

关键矛盾：agent memory 要实时写入，但向量索引构建需要时间；每条写都重建索引太贵，批量建索引又导致新数据搜不到。

在工程上解这个矛盾的思路：

• 把「可立即检索」和「可长期高精检索」拆开
  新写入先进入一个轻量的「增量区」（delta store），可以是：

  • 内存缓存 + 简单向量结构（甚至先不建复杂索引）
  • 或者一个专门的「实时 collection」，索引参数偏向写入吞吐
• 后台异步合并（Compaction）
  到一定量再合并进主索引（main store），这时构建更重的索引结构。
• 检索时双查
  先查 delta，再查 main，最后融合去重。这样用户刚执行的操作，下一轮一定能搜到，不靠运气。

如果只用一个 collection 硬扛实时写入 + 高精检索，基本会卡在「要么写不动，要么搜不准」之间来回摆。

5. 非向量数据库怎么做长期记忆

我倾向于「结构化事实 + 混合检索」

user memory 和一部分 task memory，用结构化存储更稳，理由：

• 可编辑（update/delete）是常态操作
• 需要强一致（至少单用户维度）
• 需要权限、审计、脱敏、导出、合规删除

向量化适合「相似性召回」，不适合「事实的最终真相」。

这样拆：

5.1 User Memory

KV + 版本 + 来源，每条 user memory 至少需要：

• key（例如 coding_lang）
• value（例如 Python）
• source（显式指令 / 隐式提取 / 管理后台）
• updated_at
• version（解决「多次修改」与「回滚」）
• confidence / policy tag（是否允许自动注入、是否敏感）

然后注入策略是：每轮只注入白名单 key。别把整个用户画像 dump 进 prompt。

5.2 Event/Log

文档型存证 + 可选向量索引

工具调用日志、文件变更记录，我更愿意先当「证据」存好（文档型或日志系统），向量索引只是加速检索的手段。这样即使向量库挂了，还有可追溯的事实来源。

5.3 混合检索

先过滤，再相似度，再重排

非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：

1. 结构化过滤（用户、项目、时间窗、标签、来源可信度）
2. 再做相似度/全文检索召回
3. 最后重排（时间衰减 + 类型权重 + 去重）

这套顺序能把噪声压下去，查询也更可解释。

6. 长期记忆的「可用性」核心

注入策略比检索算法更重要

很多人把精力都花在「embedding 模型选哪个」「Top-k 设多少」，上线后发现效果波动很大。

实际可能是：注入策略决定了下限。

「渐进式披露」已经是很好的骨架。我补两条我认为必须做的工程约束：

6.1 注入预算必须固定

每轮对话给记忆注入多少 token，要有硬预算。例如：

• 用户长期记忆：固定 100～300 tokens（只放稳定事实）
• 最近摘要：固定 300～800 tokens
• 检索片段：固定 500～1500 tokens（按任务重要性动态）

预算不固定，线上成本就不可控；更糟的是上下文挤压推理空间，模型会「看起来记住了」，实际输出质量下降。

6.2 记忆冲突处理

宁可不注入，也别注入矛盾

最常见的事故是：用户改了偏好（比如语言、格式、技术栈），旧记忆还在注入，Agent 开始精神分裂。

工程上必须有冲突策略：

• 同一 key 的多版本：只注入最新版
• 多来源冲突：显式指令 > 管理后台 > 隐式提取
• 低置信度记忆：默认不注入，只在用户问到时提供候选并求确认

7. 小结

AI Agent 的长期记忆不是「把历史对话都存起来」，而是一套以可控、可维护、可纠错为目标的数据管道与检索系统——先明确记忆类型（用户稳定事实、任务状态、事件证据）并分层治理，再用“捕获 → AI 压缩 → 智能检索/注入”三段式把信息从高频噪声提炼成可用上下文；存储上用结构化数据库承载可编辑的用户/任务事实，用日志/文档留存证据，并按需用向量索引做语义召回与冷热分层，避免写入与索引、噪声与成本之间的失控；

效果上不要迷信 Top‑k，把注入预算、渐进式披露、冲突处理当作系统下限；

运维上把缓存、摘要、显式记忆工具、TTL/衰减与合规删除做成一等能力，并用成本、质量与安全指标持续观测迭代。

最终目标不是「记得更多」，而是让 Agent 在长期任务中更一致、更便宜、更可靠。

以上。

当 Agent 做到一定复杂度，问题往往不在模型能力本身，而在上下文怎么给、工具怎么给、流程怎么控。同一套模型，有的团队能把它用成「能稳定交付的执行系统」，有的团队只能得到「偶尔灵光一现的聊天机器人」，差距就在架构。

早期提示词工程里，上下文基本是静态的：一次性把提示词写好，然后让 LLM 自己发挥。随着架构的演化，，上下文变成动态的，它会「收」和「放」：

收（Contract）：渐进式披露。屏蔽无关信息，减少 Token 消耗，聚焦注意力。（解决“准确性”）
放（Expand）：动态注入。根据交互状态，主动引入外部话题、记忆片段或世界观设定。（解决“丰富性”与“持续性”）

这是一种系统架构策略：用有限 Token 去管理无限信息，用非确定性模型去执行标准化流程。

1. 三个典型瓶颈：Context、工具、SOP

复杂 Agent 基本都会遇到三个主要的问题：

1. 上下文爆炸（Context Explosion）
   文档、代码、历史对话、用户画像、任务状态……你不可能全塞进 Prompt。硬塞进去也会出现“Lost in the Middle”，关键信息被淹没。

2. 工具过载（Tool Overload）
   工具越多，定义越长，Token 越贵；更严重的问题是：工具选项越多，模型选择正确工具的概率越低，尤其是多个工具功能相近时。

3. 执行不可控
   当我们希望它按 SOP 做事（先检查、再验证、最后提交），它却容易跳步、漏步，或者为了“把话说圆”而瞎编执行结果。

「渐进式披露 + 动态上下文管理」就是对这三件事的统一解法：不要一次把世界交给模型，而是让模型在每一步只看到它此刻需要看到的东西。

2. 渐进式披露

渐进式披露不是少给信息，是分阶段给信息

有人把渐进式披露理解成省 Token。省 Token 是结果，不是核心。

核心是：把一次性的大上下文，拆成多轮的决策—反馈—再决策。每一步只给与当前决策相关的最小信息面，减少噪音，让模型的注意力更集中，也让系统更可控。

一个直观的工程化表述：

• 不是构建一个「全量 Context」
• 而是维护一个「可增长的 Context」，并且增长受控

你会看到两个动作交替出现：

• Contract（收缩）：隐藏、裁剪、摘要、替换为索引
• Expand（扩张）：按需加载片段、工具子集、记忆、世界观、流程状态

3. 数据层

传统做法，使用 RAG 很容易走向粗暴：检索到的内容直接拼进 Prompt，能拼多少拼多少（可以配置）。结果通常是两种：

• Token 变贵，延迟变长
• 模型注意力被稀释，反而更不准

渐进式披露在数据层的落地方式，是把「获取信息」做成连续的动作序列，而不是一次性拉满。

参考 AI Conding 很贴近工程实际的步骤：

• 初始 Prompt 只有任务描述
• AI 发现信息不足，发起 ls 或 grep 请求
• 系统只返回 ls 的结果（文件名列表），而不是文件内容
• AI 选中目标，发起 read_file
• 系统这时才披露文件内容

这里关键点不是 ls/grep/read_file 这些名字，而是信息披露粒度：

• 先给目录/索引（低成本，低噪音）
• 再给片段（命中后才扩大）
• 最后给全文（只在确认需要时才给）

3.1 披露层级建议：L0 到 L3

可以把上下文分成几层，这里定义的层级不是标准答案，但思路是这么个思路：

• L0：任务和约束
  用户需求、输出格式、禁止事项、成功标准。L0 必须稳定，尽量短，长期驻留。

• L1：证据索引
  文件列表、章节目录、数据库表名、日志摘要、搜索结果标题。只给“在哪里”。

• L2：证据片段
  命中的段落、代码片段、表结构、关键日志区间。只给“相关部分”。

• L3：证据全量
  全文档、完整文件、长对话历史。尽量少用，只在确实需要通读时开放。

系统要做的事是：让模型先用 L1 做定位，再用 L2 做判断，最后才允许 L3 进场。这样不仅省 Token，还可以减少模型在噪音里自我发挥的空间。

3.2 动态注入

动态注入常见误区：用户问 A，你检索 A；用户又问 B，你把 A+B 都塞进去；几轮后上下文就乱了，且不可控了。

比较常用的做法是引入「上下文预算」和「淘汰策略」：

• 每轮允许注入的 Token 上限（硬预算）
• 驻留区（长期有效，例如用户身份、偏好、当前任务）
• 工作区（当前步骤的证据片段）
• 冷存区（旧证据移出，保留索引或摘要）

淘汰的对象通常是“旧证据全文”，不是“任务状态”。任务状态丢了，模型就会重复问、重复做；证据全文丢了，大不了重新检索。

4. 工具层

工具越多越强这件事，在 Agent 里是反的：工具越多，模型越容易犹豫、选错，甚至编造「我已经调用了某某 工具」。

渐进式披露在工具层的做法是：分层路由，按需可见。

参考一个很实用的层级披露思路：

• Root 层只披露 5 个大类工具：代码类、文档类、部署类、数据库类、通知类
• 模型先选大类，例如“我要查数据”-> 数据库类
• 下一轮 Prompt 才披露数据库相关的具体工具，例如 sql_query, get_table_schema

我们可以把它当成「工具菜单」：

• 第一屏：只显示一级菜单
• 点进去：才显示二级菜单
• 系统控制可见性，而不是让模型在 100 个工具里裸选

4.1 工具披露带来的三个工程收益

1. Token 控制更直接
   大量工具的 schema 描述会花费大量的 Token。层级分发能把「工具定义成本」分摊到多轮，而且只在需要时支付。

2. 工具选择准确率提升
   选项少，模型更容易做对；更重要的是，减少「近义工具」同时出现。

3. 安全策略更好落地
   不该给的能力，默认不可见。你不需要在 Prompt 里反复警告“不要调用某某工具”，直接让它看不见。

4.2 「工具可见性」本质是一种权限系统

很多团队权限做在网关、做在后端鉴权，但 Agent 的权限还应该做在“可见性”上：

• 看不见：降低误用概率
• 看得见但不可用：模型会反复尝试，浪费回合
• 可用但有条件：需要把条件变成流程状态的一部分（下一节讲 SOP）

5. SOP 层

SOP 层就是当前很火热的 Skills，且不仅仅是 Skills，它是把流程写进披露逻辑，而不是写在提示词里

企业场景里，最怕的是「看似完成、实际没做」，而这在大模型的输出中很常见。让模型「请遵循 SO」”意义不大，它会漏步骤，而且它很擅长把漏掉的步骤用语言补上。

渐进式披露在 SOP 上的落地方式，是在我们的系统里做“流程锁”：上一步没通过，下一步的工具就不出现。

参考一段很清晰的流程控制（关键点直接引用）：

1. 阶段一（Lint）：系统只披露 Lint 工具和当前 Diff，隐藏 Commit 工具
2. 阶段二（Test）：Lint 返回 Success 后，系统才披露 Test 工具
3. 阶段三（Commit）：只有测试通过，系统才披露 git_commit

这套逻辑解决的是“话术不可信”的问题：模型可以说“我已经测试通过”，但系统的状态机不会因为它一句话就放行。放行只能来自可验证的工具回执。

5.1 SOP 控制要点

把「检查点」设计成机器可判定

SOP 最容易失败的地方是检查点含糊，比如“确保无问题”“确认完成”。Agent 体系里要改成：

• 有工具回执的：以回执为准
• 没有工具回执的：以人工确认或外部系统状态为准
• 不能验证的：不要当作放行条件

能自动化判定，就不要让模型自评。

6. 为什么要引入 Agent Skill

这里本质是一种是工程分层，当然也是概念包装。

很多人会问：这些用代码控制不就行了，为什么还要提 Agent Skill？

把 Skill 当成一个架构抽象，会更容易把系统做稳：它解决的是解耦、复用、状态感知。

这里把关键逻辑说透：

6.1 Skill 是「上下文的容器」，用完即走

没有 Skill 时，你往往会得到一个越来越大的系统提示词：把所有话题、所有工具、所有规则都塞进去。结果就是注意力迷失、指令冲突、Token 爆炸。

有 Skill 后，你把「某一类任务需要的提示词 + 可用工具 + 知识入口」封装到一起：

• 需要时加载
• 不需要时卸载
• 上下文保持干净

这和「渐进式披露」是同一件事：Skill 是披露的载体。

6.2 Skill 是「动态注入」的边界

动态注入真正难的是边界：注入多少、注入什么、何时撤回。

Skill 让边界清晰：

• 注入不是“往 Prompt 拼字符串”
• 注入是“激活某个 Skill”，让它把需要的最小信息面带进来

系统因此更容易做预算、做审计、做回放。

6.3 Skill 让路由变成可维护的系统，而不是靠直觉写 prompt

复杂 Agent 一定会路由：用户一句话可能触发“查资料 / 写代码 / 安抚情绪 / 改流程 / 发通知”。

Skill 体系下，路由的输出是“激活哪些 Skill”，而不是“写一段更长的提示词”。这会直接改善维护体验：

• 你能统计每个 Skill 的触发率、成功率、平均 Token
• 你能对某个 Skill 单独迭代，而不牵一发动全身
• 你能为不同用户、不同权限加载不同 Skill 组合

7. 动态上下文管理

动态上下文管理要管理「状态 + 证据 + 权限」。

把上下文当成一段文本来拼接，迟早失控。更合理的视角是：上下文是系统状态在模型侧的投影。

建议把上下文拆成四类对象，每一类有不同的生命周期：

1. 任务状态
   当前处于哪个阶段、已完成哪些检查点、下一步允许做什么。它要短、稳定、结构化，尽量每轮都带。

2. 证据
   检索片段、工具输出、外部信息。它要可引用、可追溯、可淘汰。

3. 偏好与长期记忆
   能影响输出风格或长期策略的东西。它不该频繁变化，变化要可控，最好有写入门槛。

4. 能力与权限
   工具可见性、工具可用性、流程放行条件。它是约束，不是参考建议。

8. 可执行的架构清单

按“先做什么更值”排：

1. 先做工具可见性控制
   工具分层，默认只给 Root 类目；按分支披露具体工具。

2. 把 SOP 变成状态机放行
   上一步成功回执出现，下一步工具才可见。失败就停在当前阶段，不要让模型口头放行。

3. 把上下文分区：驻留区 / 工作区 / 冷存区
   驻留区短且稳定；工作区有预算；冷存区只保留索引/摘要。

4. 先索引后片段的披露策略
   任何大文本资源都先给目录、标题、命中位置，再给片段，不要一上来就全文。

5. Skill 化你的上下文与工具组合
   让“动态注入”从拼 Prompt 变成“加载/卸载 Skill”。一开始不需要 100 个 Skill，把高频的 5–10 个先做稳。

6. 把观测补齐
   记录每轮：披露了哪些证据、开放了哪些工具、触发了哪些 Skill、用了多少 Token、是否命中检查点。没有这些数据，后面很难迭代。

9. 小结

一个成熟的 Agent 系统，外观上像在聊天，内部其实在跑一套受控的执行架构：

• 信息不是一次塞满，而是按步骤披露
• 工具不是全量开放，而是按层级开放
• 流程不是靠自觉，而是靠状态机约束
• 记忆不是越多越好，而是可写入、可淘汰、可追溯

把这四件事做好，Agent 会越来越像一个靠谱的执行系统：该问的问清楚，该查的查到证据，该做的按流程做完，做不到就停下来，不会硬编。

这就是「渐进式披露 + 动态上下文管理」的价值：不是让 Agent 说得更像，而是让它做得更稳。

以上。

但是如何真正要做到一个行业中去，把一个行业 Agent 做好就没那么容易了，特别是让这个 Agent 能稳定的迭代，稳定的跑对了，也就难了。

在这些迭代过程中，我们会不停的换模型、改提示词、加工具、加缓存、改路由、做多智能体……

这样我们就会收获如下的一堆问题：

• 线上用户说「变笨了」，却没证据；
• 反馈说生成效果不行，却不知道该如何描述其所说的效果；
• 修一个 bug，引入三个新 bug；
• 团队讨论靠口感，最后靠拍板；
• 研发不敢升级模型，因为测试周期太长；
• 业务要结果，技术要可控，双方都焦虑。

面对这些问题，我们聊聊如何对行业 Agent 做评测。

0. 说在前面

我们评测的是「系统」，不是「模型」

很多团队说在做评测，实际上只是在测「模型回复像不像」。对 Agent 来说不够，因为 Agent 的能力来自两部分：

• 模型
• 工程：提示词、工具编排、状态管理、记忆、重试策略、检索、权限、路由、超时、并发、回退等

所以评测对象应该是：模型 + 工程 的整体行为。

1. 标准

团队里面一定要有领域专家，没有领域专家的测评只能算自娱自乐。

Agent 的「好」不是抽象的。没有领域专家，评测标准会变成两类坏结果：

• 写得很漂亮，但不对应业务结果（比如客服很礼貌，但票据没关单）
• 标准含糊，评分不可重复（今天判通过，明天同样输出判不通过）

「领域专家」不一定是外部大咖，很多时候就是我们身边的同事：

• 客服主管（知道什么叫“解决”）
• 财务/风控（知道哪些动作不能做）
• 资深运营（知道用户会怎么钻空子）
• 负责交付的实施/售后（知道线上真实约束）
• 售前负责人（知道用户要的是什么）

要求只有一个：两位领域专家独立评审同一个任务，应该能得到一致的 pass/fail。做不到就说明任务或标准还不够清晰。

2. 数据集

输入与输出要成对，从 20 条 good case 和 bad case 开始吧。

很多团队拖着不做评测，理由是「没有足够的数据」。

2.1 数据集怎么来

1. 线上事故 / 客诉 / 工单：最值钱，但也是压力最大的
2. 发布前人工回归里会反复点的那些检查项
3. 运营同学最常复述的“用户就爱这么问”
4. 灰度期间的失败轨迹（尤其是工具调用失败、超时、权限不足、状态不一致）

2.2 一个测试任务里应该包含什么

• 输入（用户消息 + 初始状态 + 可用工具 + 环境约束）
• 明确的成功条件
• 参考解（可能是图、视频和文本）

当遇到测试不通过或者通过率很低时，一般不是模型不行，可能是设计的测试任务有问题。

2.3 数据集要有正反两派

测试人都知道的，做测试更多的是测异常。在做数据集时，这个逻辑一样的成立。

• 该搜 vs 不该搜
• 该下单 vs 不该下单
• 该升级人工 vs 应该继续处理
• 该改文件 vs 不该动文件
• 该生成图 vs 应该拒绝（合规/版权/不当内容）

3. 系统

让过程系统化，小系统也是系统

评测不系统化，最后一定会回到「手工点点点 + 群里吵架」。一个可用的评测系统，最少包括：

3.1 评测运行系统

• 并发跑任务
• 每个环境隔离（干净的文件系统、数据库、缓存、账户）
• 固定随机种子/版本（尽量可复现）
• 记录完整过程
• 输出结构化结果

请注意：共享状态会污染结果。

这个系统可以大，也可以小，甚至小到只是一个 python 脚本。

3.2 评测资产管理

• 任务版本化（任务也要像代码一样走 PR）
• rubric/断言版本化
• 基线版本固定可回放
• 失败样本池：每次线上新失败，能快速进入评测集
• 评测数据集管理
• 评测结果管理，特别是图片类 Agent，所有的结果图都需要保存，并且能随时查阅，给到领域专家来审查。

3.3 结果可读性

最终的结果重要，但这个结果不仅仅是分数，还必须能「点开看」：

• 失败的结果
• 判定理由
• 最终的证据（输入的 prompt，图片结果，过程中的数据库/文件/页面状态等等）

4. 成本

和过往的测试工作不同，AI 的评测需要更多些的考虑成本，特别是多模态或视频，生图类 Agent。

这里的基本逻辑是：每个 AI 算力资源都是有限的，也是贵的。

如果在一个死循环中写了调用外部视频生成的接口逻辑，那等待的就是账号里面的钱被用光，如果有加了使用限制，大概率就是达到限制。

以第三方大模型账号为例，有几个小点：

1. 测试账号要和生产账号隔离，防止异常突出导致资源受限，在每个平台请求并发数，或者分钟请求数，或者 token 速度都是有限的，不同环境的资源需要隔离开来。
2. 账号需要做好限制，防止账号的钱被用完；
3. 安全考虑，定期更换。

5. 传统测试方式

静态分析、工具验证、记录分析这些传统的测试方法别丢了。

5.1 静态分析

适合：

• 代码类：lint、type check、安全扫描（ruff/mypy/bandit 这类）
• 配置类：schema 校验
• 文本结构：JSON schema、正则、字段完整性 优势：快、便宜、可复现、可 debug。

5.2 工具验证

Agent 出问题很常见的一类是：工具用错、参数错、顺序不合理、该用不用。

你可以验证：

• 是否调用了某工具
• 参数是否在范围（例如退款金额 <=100）
• 是否访问了不该访问的资源

但要注意：不要把“必须按某条路径走”写死。太死会惩罚合理的创造性解法。更推荐「看产出」，必要时只加一些底线约束（比如必须做身份验证）。

5.3 记录分析

不一定评价“对错”，而是监控质量与成本：

• turn 数、toolcall 数、tokens
• 延迟：TTFT、总耗时、吞吐
• 重试次数、错误码分布

6. 新的基于大模型的测试

该用用，但要用得克制

对于评测，我们通过可以分为三类：代码型、模型型、人工。实际落地里，模型型的价值主要在两件事：

1. 开放式输出：没有唯一正确答案（客服话术、研究总结、写作、规划）
2. 细粒度质量维度：礼貌、同理心、覆盖度、论证质量、是否胡编

常用方式：

• 打分（按维度给分）
• 自然语言断言（是否满足某条要求）
• A/B 谁更好
• 对照参考答案
• 多裁判投票/取中位数

但需要注意：

• 非确定性：同样输入可能不同评分
• 更贵：相当于每条任务再跑一遍模型
• 需要校准：必须和人评对齐，否则就是“模型自嗨”

一个实用的建议：给 LLM 评测一个「退路」，例如信息不足就输出 Unknown，避免它为了「必须回答」而脑补。

另外：把评分标准结构化，并拆维度单独评，不要一次判所有维度，噪声会很大，因为随着上下文更长，大模型的注意力会出现一些问题。

7. 人工评分

领域专家门禁：效果不好就不能上，灰度可选

人工评分并不是用来「天天打分」的，人工的职责更多是：

• 定义标准（什么叫好）
• 校准 LLM grader（对齐、抽检、纠偏）
• 做门禁（关键版本上线前必须过）

7.1 门禁怎么做

• 定一个小的「关键任务集」（比如 30 条最关键、最敏感、最影响收入/合规的），或者称为黄金链路
• 每次大改/换模型/换工具链，必须过这个集
• 过不了：不讨论「用户可能不在意」，直接回滚或修

7.2 灰度

没有足够流量，灰度很难有显著的效果，也没有啥意义：

• 用离线评测 + 小范围内测
• 线上用强监控兜底（错误、成本、关键转化、人工接管率等）

等流量与组织能力到位，再做严格 A/B。

8. 流程

从 0 到 1，再到可持续

这套流程的目标很简单：让每次改动都有依据，上线前知道会不会退步，退步了能快速定位原因。

第 0 步：尽早开工，小样本就能跑起来

别等“数据够多”。先做一个能工作的最小闭环。

• 先收 20–50 条真实案例（成功和失败都要）
  • 来源：线上工单、客服反馈、bug 记录、内部手工测试步骤

• 每条案例都写清楚：什么算成功，什么算失败
• 先把基础能力跑通：
  能批量跑 → 每次互不干扰 → 全程有记录 → 能出汇总表

这一阶段不追求完美，只追求“评测能运转”。

第 1 步：把“手工回归”变成固定任务清单

你们发布前人工必做的检查，本质上就是任务列表，只是没系统化。

• 发布前“必须点”的那些流程，全部写成任务，进评测库
• 线上出现的 bug / 客诉，能复现的尽量都写成任务
• 按影响排序：
  影响钱 / 合规 / 大客户 / 高频场景优先

做久了会发现：评测库就是你们产品真实使用方式的地图。

第 2 步：任务要写得清楚，评分要能落地

一条任务写不清楚，后面全是噪音。

至少要满足三条：

1. 两位领域同学看完任务描述，能给出一致的“过/不过”
2. 给每条任务准备一个“标准答案/参考做法”（证明这题能做对）
3. 评分标准不能靠“默认常识”

• 评测要检查什么，任务里就要写清楚
• 别出现“任务没说路径，但测试默认某个路径”这种坑

任务写得越清楚，后面迭代越省时间。

第 3 步：任务要成对出现

很多系统越改越怪，可能是评测只给了单边信号。

每类行为都尽量做成一对：

• 该查资料 / 不该查资料
• 该下单 / 不该下单
• 该继续处理 / 该转人工
• 该修改文件 / 不该动文件
• 该生成 / 该拒绝（合规类尤其重要）

第 4 步：把评测环境做稳定，确保结果可信

评测不可信，比没有评测更糟糕。

关键点：

• 每次运行从干净环境开始（文件、数据库、缓存都重置）
• 尽量减少共享状态（否则会互相污染）
• 资源要有上限（CPU/内存/网络），避免“机器不够导致一片失败”
• 失败要能区分：
  • 是系统真不行
  • 还是环境抖动、配额限制、工具不稳定

要保证：同一版本跑两次，结果大体一致。

第 5 步：评分规则按「能自动就自动」来设计

评分不要一上来就全靠大模型判。

推荐顺序：

1. 能用确定规则判断的，先用确定规则

• 结果是否写进数据库、订单是否存在、文件是否生成、测试是否通过

1. 能用简单规则校验的，用规则

• 字段完整、格式正确、调用工具参数在范围内

1. 只有在确实需要“主观判断”时，才用大模型评分

• 语气、解释是否清楚、内容是否覆盖关键点

还有一条很重要：
尽量评「最终交付」，少评「必须怎么做」。
路径卡太死，会误伤很多正确解。

第 6 步：固定做「看过程记录」，不然不知道问题在哪

很多团队评测做不下去，就是因为只看分数，不看过程。

至少要做到三件事：

• 分数下降时：优先看失败最多、影响最大的那几条任务的过程记录
• 每周抽查一批「通过」的过程记录（防止钻规则漏洞）
• 发现「明明做对了却被判错」，立刻修任务描述或评分规则

一句话：评测系统也要像产品一样调试。

第 7 步：分数到顶了就补题，不然评测会失效

分数 100% 不代表系统没问题，只代表这套题已经测不出差异。

做两件事：

• 持续把新的线上失败变成新任务
• 专门补「更难、更真实」的场景（长流程、多约束、容易出错的边界条件）

评测库要一直增长，否则它会变成摆设。

第 8 步：让评测「有人管、有人用、有人能加题」

长期最有效的分工通常是：

• 有一个小组负责评测系统本身（跑得稳、记录全、报表清楚）
• 各业务团队负责写任务（最懂用户的人写，写出来才贴近真实）
• 写任务像写代码一样走评审流程（谁提的、为什么提、怎么验证）

让离用户最近的人能把问题变成任务，是评测能持续的关键。

9. 非确定性

别再只盯「通过率」，用 pass@k 和 pass^k 讲清楚“稳定性”

Agent 的输出有随机性，同一任务可能今天过、明天不过。以下两个指标可以有：

• pass@k：k 次尝试里至少成功一次的概率
  • 适合“允许多试一次”的场景（比如离线生成候选方案）

• pass^k：k 次尝试全部成功的概率
  • 适合“线上必须稳定”的场景（客服、交易、流程自动化）

它们会随着 k 分化：

• k 越大，pass@k 越接近 100%
• k 越大，pass^k 越接近 0（对稳定性要求更苛刻）

这能解决很多争论：

• 研发说「抽卡，多跑几次能过」
• 业务说「用户只给一次机会」
  用 pass@k 和 pass^k 直接对齐产品要求。

10. 安例：生图 AI Agent 如何评估

生图 Agent 的评测，比「文生图模型评测」更难，因为 Agent 往往还会：

• 和用户多轮确认需求
• 调风格/比例/seed/参考图
• 调用安全审核、版权过滤、提示词改写
• 产出多张候选并做挑选/排序
• 写交付说明（可商用/不可商用、使用建议）

评测要覆盖的不是「画得好不好」一句话，而是「是否按业务标准交付」。

下面给一套实用的评测维度：

10.1 标准

先定“交付合格”是什么

建议产品/设计/合规一起定 3–5 条硬标准，例如：

• 不违规：敏感内容、未成年、色情、仇恨、暴力、政治等必须拦截或降级
• 不侵权：明显模仿特定 IP / 特定艺人脸 / 商标露出等按策略处理
• 满足需求：主体、场景、风格、比例、文字有无（比如“不要文字”）
• 质量底线：严重畸形、手指崩坏、文本乱码（如果要求有字则反过来）
• 可用性：分辨率、格式、背景透明/不透明、交付数量

标准不要写成「更美观」「更高级」，要写成可判定的条目。

10.2 数据集

最有效的来源通常是：

• 用户最常下单的品类（电商主图、海报、头像、插画、UI 素材）
• 客诉：不像、漏元素、风格跑偏、文字错、侵权被投诉、审核误杀
• 运营活动：固定模板需求（这类最适合做回归）

每条任务里建议固定：

• 用户输入（含约束：尺寸、风格、禁忌、用途）
• 允许的工具（生成、放大、背景去除、OCR 检查、合规审查）
• 成功条件（至少满足哪些项）
• 参考交付（如果你们已有人工优秀样例，可以作为对照，但不强制唯一答案）

10.3 评测流程

评测建议按「确定性 → 半确定性 → 开放判断」的顺序叠起来，减少噪音、降低成本。

A. 结果校验（尽量全自动、最优先）

这层解决「交付物是否合格」的硬指标：

• 格式、尺寸、分辨率、通道（如 PNG 透明背景）
• 交付数量（例如必须 4 张）
• 文件可打开、无损坏
• 禁止内容检测（审核模型/规则引擎给出通过/拦截/分级）

B. 内容对齐（半自动，能做多少做多少）

这层解决“有没有按需求做”的关键事实核对：

• 关键元素是否出现：用图像理解/检测器做覆盖检查（比如“猫 + 红围巾 + 雪地”）
• 不该出现的是否出现：
  • “不要文字”→ 用 OCR 检测是否有字
  • “不要 logo/商标”→ logo/商标检测（覆盖不了的留到抽检）

C. 开放项判断（用于难以规则化的部分）

这层才用多模态判断去评估更开放的维度，例如：

• 主体/场景/风格是否整体匹配需求
• 是否存在明显瑕疵（手部畸形、脸崩、透视严重错误等）
• 交付说明是否写清：能否商用、限制条件、使用建议

注意：开放项的判定要校准，不要一开始就“全自动放行”。

D. 过程约束（管体验、管成本）

对 Agent 的“过程”也要设上限，不然容易出现“靠烧钱刷分”：

• 最大对话轮次（例如 ≤ 6 轮）
• 工具调用次数上限（避免无限重试）
• 总耗时 / 总成本阈值

10.4 成本控制

生图评测很贵，建议分三层跑，不同层用不同频率：

1. 回归层（少量高价值，天天/每次发布必跑）
   高频品类 + 高风险合规项 + 线上常见故障
2. 能力层（持续加难题，定期跑）
   风格混合、复杂构图、多约束冲突、长对话澄清等
3. 抽检层（人工校准，每周固定抽样）
   抽查“通过样本”和“失败样本”，用来校准开放项判断与审核策略

10.5 典型坑

提前避开

• 只看审美分，不看合规/侵权/交付规格 → 上线风险最大
• 只测“能生成”，不测“该拒绝/该降级” → 合规体系形同虚设
• 不看过程记录 → 不知道是 Agent 真错了，还是评分/审核错了；也抓不到“用昂贵链路刷通过”
• 评分规则写死 → 把某一种构图当唯一正确，误杀大量合理解（导致迭代方向跑偏）

11. 最后

评测的目标是：知道变好还是变差、知道差在哪、知道怎么改。

真正成熟的状态通常是这样：

• 每次改动都有反馈：离线分数怎么变、失败清单有哪些，一眼可见
• 分数下降能追到根因：能定位到具体哪条任务、哪段过程记录出了问题
• 关键回归集就是门禁：过不了就不发布（不讨论「感觉应该没事」）
• 换模型/换策略能算账：能快速判断「收益是否值得成本与风险” 」
• 线上与离线形成闭环：
  • 线上出现的新失败，能快速回流成任务进评测库
  • 离线提前发现的风险，能在上线前就挡住

最后一句：一定要看过程记录。

以上。

2025 年就要过去了，今年算是 「 AI Agent 元年」。各种 AI Agent 层出不穷，我们能看到的做得比较好的还是编程用的 Agent。

做垂直行业 Agent 最常见的问题是「行业 Know How 没有变成系统的一部分」。

很多团队一开始就把一堆文档丢进知识库，做个 RAG，就开始卖方案。这种产品上线后很快就会遇到三类问题：

• 答得像懂，但不符合行业规则：说法对，流程错；建议对，边界条件错。
• 能聊但不能办事：无法稳定调用工具、填表、校验、留痕。
• 越迭代越乱：知识变更没人负责，指标不清，线上问题复现不了。

Know How 真正落地，不仅仅是「让模型看过资料」，还要把行业经验拆成可维护的资产，进入 Agent 的检索、对话策略、工具链、评测与治理。

下面是我对于这个事情的一些思考：

1. 行业 Know How 是什么

首先它不是什么。它不等于行业知识。

大家口头说的 Know How，落到产品和工程，至少包含五类东西：

1. 概念与术语体系
   行业里的实体是什么、字段是什么意思、同义词怎么对齐、缩写怎么展开。
   以室内设计为例，意式低奢风格包括哪些元素，颜色，走线是怎样的，沙发应该是怎样的沙发，摆件应该是要用什么摆件等等。

2. 规则与约束
   哪些能做、哪些不能做；阈值、条件、合规要求、审批链。
   这部分经常是 Agent 出错的根源，因为它不像百科知识那样「常识化」。或者换句话说这些在大模型的数据集中没有。

3. 标准流程与例外流程
   正常路径怎么走，遇到异常如何处理，什么时候需要人工介入。
   垂直行业的「例外」通常比「主流程」更重要。

4. 可交付的结果格式
   最终输出不是一段话，而是：一张符合要求的图、一份报表、一段可执行的操作、一张表单、一条工单、一段对外话术、一次系统配置变更。
   Know How 里要明确「交付物长什么样」。

5. 判断标准（质量定义）
   什么叫「答对/办对」，什么叫「可用/不可用」，什么叫「风险可控」。
   这决定了你的评测体系怎么做，也决定能不能规模化。

很多人只停留在把 1 做好，，但 2/3/4/5 没有结构化，导致 Agent 看起来在输出，实际上没法稳定交付。

2. 行业 Know How 落地过程中的指标

把 Know How 落进 Agent 需要实现四个更实际的指标：

1. 更低的错误率（尤其是规则类错误）
   垂直行业里，最致命的不是“答得不够全面”，而是“违规、越权、走错流程、漏掉关键校验”。

2. 更稳定的工具执行
   Agent 需要把自然语言转换成结构化参数、步骤、校验，再调用系统。
   Know How 决定：填哪些字段、字段怎么校验、失败如何重试、何时升级人工。

3. 更可控的交付质量
   有的行业输出必须“可审计、可追溯、可复核”。
   Know How 需要提供引用依据、版本号、规则来源、操作日志策略。

4. 更强的组织协作效率
   Know How 一旦工程化，你就能把原来靠“资深同事口口相传”的经验，变成可复用资产。
   这在创业团队里很关键：人员变动不会让能力断层。

3. 按四层做落地实施

我个人倾向于把落地过程拆成四层，每层都有明确产物，方便推进、验收和迭代，并且每一层可能会对应不同的工种或团队，如果团队比较大的话：

1. 知识层（Knowledge）：知识库、术语体系、规则库、流程库
2. 数据层（Data）：训练数据集、测试数据集、线上回流数据
3. 行为层（Behavior）：提示词、对话策略、工具规范、风控策略
4. 模型层（Model）：基座模型选择、RAG 策略、LoRA/微调、路由与降级

3.1 行业 Know How 的定义与知识库的搭建

既然要做行业 Know How，那么需要清晰的知道什么是行业 Know How，以及谁可以做好行业 Know How 这件事情。

典型的负责人是业务 Owner 或资深的运营专家，如果是设计相关的行业，至少是设计总监级别的人才行。

我们做这个事情的目标是让让模型/Agent 说得准、做得对，并且可维护。

其核心产物如下：

1. 术语体系：术语表（中英/别名/缩写）、字段含义、口径说明
2. 规则库：可枚举的判断规则、禁区、例外条件（最好结构化）
3. 流程库：关键业务流程（输入→判断→输出），含边界条件
4. 知识源清单：哪些文档可信？更新频率？责任人是谁？（否则 RAG 永远不稳定）

这里建议做最小集合。

在做定义时，并不要直接全面畏开，小步快跑，灰度上线在这里也是一个好用的策略。

特别是小团队，可以让 业务Owner 主导，配一个「知识整理员」（运营/产品），快速迭代进行。

如果团队比较大，可以以「行业知识委员会」之类的组织形式（包括业务、法务/合规、客服/运营、产品等），每周进行，也是需要做增量逻辑 。

当做完了后，这些所有的内容都是需要验收的，大概需要有如下的一些标准，不同的行业不同，大家可以根据自己的情况延展开来：

• 覆盖 Top N 高频问题/场景（比如 50/100 个）
• 每条规则/流程有：来源、责任人、更新时间
• 知识库能支撑检索：有统一 ID、可追溯引用
• 隔离策略，权限控制
• 切分粒度，过期策略

这些标准可以可直接写进项目的里程碑中。

3.2 数据集：训练数据集、测试数据集、回流数据

AI 教母李飞飞在视频里说过：数据不能说比算法重要，但至少同等重要。在垂直 Agent 场景，这句话更接近现实：用同一个基座模型，最后差距往往来自数据与评测体系。

数据一般是算法负责人或算法工程师来负责，但业务同学也需要参考其中，因为数据的好坏并不是算法同学可以解决的，以室内设计为例，一张图是否符合某个风格，算法的同学其实是不懂的，这需要业务同学的深度参与，并一起构建。

算法侧同学提供平台和数据，业务同学提供判断的能力和过程。

其核心产物如下：

1. 训练/指令数据集（若需要）：问题-答案、对话、工具调用轨迹，让模型学会行业表达方式、结构化输出、工具调用格式、常见任务路径
2. 测试集（强烈建议先做）：覆盖关键业务场景 + 对抗样本 + 边界条件，以可以稳定衡量上线质量
3. 线上回流数据：用户输入、模型输出、工具结果、人工标注、失败原因标签，需要考虑用户隐私或者用户不允许使用其数据作为训练用等情况。这些数据可以让我们看到真实用户问题、失败案例、人工修正记录，用来驱动迭代
4. 标注规范：什么算“正确/合规/有帮助/可执行”，标签定义要可复用

在小团队中，可以先做轻量的测试集，用于做版本回归；大一些的团队，可以直接先建议数据流水线：采集→脱敏→抽样→标注→入库→评测→报表。一把到位，不过也可以先人工，再脚本，再系统，再平台的逐步演化。

在做数据过程中，数据标注是一个很重要，但是又很重复的活儿。

建议在训练/测试数据中同时包含：

• 正确输出（结构化字段或执行计划）
• 关键引用依据（规则/流程/定义来自哪一条知识）
• 失败示例（常见错误输出长什么样）
• 评判标准（哪些字段错了就算失败）

对于一个创业团队来说，很难一开始就有大量行业的高质量数据，建议把精力放在：

• 覆盖核心任务前 20% 的高频路径
• 覆盖最致命的规则错误
• 覆盖工具调用最常失败的参数组合
• 每次迭代只扩一小块范围，但把这块做“闭环”

3.3 提示词

提示词是我们和 Agent 交互的核心路径，在落地时，我们需要把 Know How 变成对话策略和执行约束。

在垂直 Agent 中，我一般只保留这些内容：

• 角色与权限边界：能做什么、不能做什么
• 任务范围：支持哪些任务，不支持哪些任务
• 关键术语与字段定义（只放必须的，其他走检索）
• 输出规范：必须给结构化结果、必须给引用、必须留痕字段
• 追问策略：缺哪些字段必须追问；遇到冲突必须确认
• 风控策略：触发哪些条件必须拒绝/升级人工
• 工具调用原则：什么时候必须调用工具验证，什么时候允许只基于知识回答

不要在系统提示词里塞大量「知识正文」，那是 RAG 的工作。

垂直行业用户会追问「你凭什么这么做」。如果引用做不好，Agent 很难进入生产流程。

建议把引用设计成两层：

• 面向业务用户：引用规则标题 + 生效时间 + 一句话解释
• 面向审计/排障：引用片段 ID、版本号、检索得分、调用工具日志

这部分一旦做成标准件，后面迭代会轻松很多。

另外，需要考虑提示词的版本问题，需要像代码一样做版本管理（有变更记录、可回滚）。

并且，对于对话策略，需要能澄清问题、确认关键信息、分步执行、失败重试与兜底；对于工具，每个工具的输入输出 schema、超时、幂等、重试、权限等等都需要考虑。还有一些风控策略。

在小团队中，可以用一套主提示词 + 若干场景子提示词，先保证可控，工具尽量少但稳定。

业务复杂一些后，可以做策略路由，做一个策略系统，不同意图走不同策略/模型/工具链，并且可以引入灰度发布等逻辑以减少版本迭代时对用户的影响，以及做 A/B 策略。

3.4 在 LoRA 中如何体现这些 Know How

LoRA 适合学“表达方式与结构化习惯”，不适合塞“会变的事实与规则全文”。

以室内设计为例，LoRA 真正解决的是两件事：

1. 让模型更像专业的设计师（表达方式、偏好、组合习惯、审美取向更稳定）
2. 让模型在特定任务上更「听话」且更一致（同样的输入，输出结构、风格强度、方案套路更可控）

LoRA 是把隐性经验固化

设计的很多 know-how 不是“能查到的一条条规则”，而是：

• 这个风格到底应该选哪些材质更对味
• 什么比例的木色/灰度/金属更像“中古”
• 软装怎么搭不显廉价
• 同一个户型在预算约束下，先动哪里收益最大
• 同样叫“奶油风”，专业设计师认可的“奶油风”边界在哪里

这些东西虽然也可以写成原则，但很难写成完整可枚举的规则库。这类「难以规则化但能被大量样例体现」的东西，才是 LoRA 更擅长的。

以风格为例，风格可以拆成两部分：

A. 可描述、可枚举的部分（更像知识）
比如：

• 风格定义与边界：什么是侘寂、什么不是
• 常用元素清单：材料、色系、线条、灯型、家具轮廓
• 禁忌与冲突：哪些组合容易翻车
• 预算/空间约束下的硬规则：动线、安全、尺度、收纳基本原则

这部分适合放在 知识层（术语/规则/流程）+ RAG：因为它会更新、可追溯、要引用来源，改起来也方便。

B. 难以枚举、靠“整体观感”判断的部分（更像模型能力）
比如：

• “像不像某个风格”的整体一致性
• 元素比例、轻重、层次、留白的拿捏
• “高级/廉价”“松弛/用力过猛”这种审美判断
• 团队偏好的方案套路（同户型常用的解决方式）

这部分更适合用 LoRA：用高质量样例把“认可的风格分布”压到模型里，让它输出更稳定。

在以 LoRA 落地的过程中， 风格一致性更稳，输出更贴近可交付物，方案「更会落地」

3.5 那大模型呢？

Know How 在大模型中如何体现？企业不炼模型，怎么选、选完能做什么？

大多数企业不可能自己训练大模型，现实做法是：选一个合适的基座 + 做好工程层的增强。

大模型的选择需要在成本、稳定性、延迟之间达到可用平衡，并可持续可迭代。 这里的迭代不仅仅是大模型本身的迭代，还可能是切换到其它的大模型。

在当前的 AI 场景，没有所谓的客户忠诚可言，哪个好用用哪个，而且切换成本不高（API + 提示词场景）。

创业小团队需要以 RAG + 行为策略，把 80% 问题做稳，暂缓微调；把钱花在评测与回流上。 只有这些成熟一些后，可以再考虑上 LoRA/微调，收益才可控。

对于大模型，我们会关心这些维度：

• 工具调用能力：函数调用是否稳定、参数是否可控
• 长上下文与检索融合：能不能在引用材料下保持一致
• 结构化输出稳定性：格式错一次，生产系统就要兜底
• 安全与合规：越权回答、敏感信息处理、拒答策略
• 成本与延迟：是否能在预算内跑到规模
• 部署形态：公有云/私有化/混合；日志与数据是否可控

我们不会只选一个模型就定终身。哪个好用用哪个，并且在工程层面实现「模型路由」：不同任务用不同模型，失败自动降级。

4. 聊下组织

在整个落地的过程中，组织是对落地结果的非常重要的保障，需要事事有人跟，件件有人负责，一般的分工如下：

• 业务负责人：定义任务边界与验收标准，批准规则变更
• 行业专家：产出规则/例外/口径，参与标注与复核
• 产品/运营：维护任务地图、模板、知识版本，推动回流闭环
• 算法/工程：RAG、工具链、评测、监控、部署与回滚

5. 小结

Know How 落地的目标不是「更像专家」，而是「更像系统」

垂直行业的 AI Agent，最终要进入的是流程、合规和交付，而不是聊天。

以上。

在 2025 年的 10 月份，Anthropic 发布了 Claude 模型的一项重大更新的 Agent Skills，它允许用户将专业知识、脚本和资源打包成模块化的“技能文件夹”（Skill folders），让 AI 能在特定工作场景中更专业地执行任务。

如果我们在做行业 Agent、内部 Copilot、或想把 Claude Code / API 用在业务里，那就需要我们在做之前把「Skill」和「行业 Workflow」这两件事想清楚，并知道从哪里下手。

1. Skill 和行业 Workflow 的概念

1.1 Skill 是什么？

简单说：

Skill = 给模型的一份可复用「操作说明书 + 流程模板」

在 Claude 体系里，Skill 是一个带 SKILL.md 的文件夹，它告诉模型：
“在什么情况下该用我、我要完成什么任务、要按什么步骤做、输出要长什么样。”

特点有几个：

• 面向具体任务，不是一个抽象的「能力标签」
  例如：生成符合公司品牌规范的 PPT，按照内部代码规范重构文件，按财务模板做对账报告。
• 本质上是文字写清楚的 SOP + 可选的脚本
  主体就是 Markdown 文档，有需要时再绑上 Python 脚本去做确定性处理。
• 可以被模型自动发现和按需加载
  模型不会一直把完整 Skill 塞在上下文里，只在命中时再读取详细内容。

它和我们平时说的「提示词」的区别在于：
提示词是一次性、散落的；Skill 是结构化、可版本化、可共享的。

1.2 行业 Workflow 是什么？

Workflow 可以理解为：

把行业中的业务流程，做成清晰的步骤编排和 IF-ELSE 逻辑。

过去这些东西已经存在于：

• 各种脚本、RPA、BPM 系统
• 系统之间的 API 调用编排
• 内部运维 / 运营同学脑子里和文档里的 SOP

在 Agent 语境下，我们关心的是一件事：

怎么把这些已有流程封装成「可由 Agent 触发、可观测、可审计」的工作流节点。

行业 Workflow 的关键特征：

• 强约束：
  对输入 / 输出有严格格式要求，执行过程里有清晰的分支、回滚、告警。
• 强依赖业务 Know-how：
  为什么要这样分支，Why 在流程里，而不是在模型参数里。
• 长期稳定运行：
  一旦跑到生产，就不希望被大模型的「心情」影响。

2. Claude Code 的 Skill

在 Claude 的整体设计里，Skills 是一个非常核心的扩展机制。它解决了两个问题：

1. 如何在不撑爆上下文的前提下，给模型装很多垂直能力？
2. 如何让业务团队通过“写文档”的方式，而不是“写模型”的方式扩展能力？

2.1 一个 Skill = 一个带 SKILL.md 的文件夹

Claude 官方定义里，一个 Skill 的最小单元就是：

• 一个文件夹
• 里面一个 SKILL.md
• 也可以再带一些脚本、资源文件

官方给出的模板是这样的：

---
name: my-first-skill
description: 这是一个关于此 Skill 能做什么以及何时使用它的清晰描述。
---
# 我的第一个 Skill

[在这里添加您的指令，Claude 在激活此 Skill 时会遵循这些指令]

## 示例
- 用法示例 1
- 用法示例 2

几个要点：

• name：唯一标识，最好跟任务直接相关。
• description：非常重要，模型靠这个来判断「什么时候用你」。
• 正文部分：
  写清楚目标、步骤、注意事项、输出格式、示例。

只要这一个 Markdown 写好了，一个可用 Skill 就成立了，不需要额外的配置文件。

2.2 具体例子：PPT Skill

官方仓库里有一个 PPTX 相关的 Skill，SKILL.md 类似下面这种结构：

• YAML Frontmatter：说明 Skill 名称、用途（处理 PPTX）
• 正文：分章节写

  • 如何解析 PPTX
  • 如何修改版式
  • 如何保证品牌颜色与模板统一
  • 输入 / 输出约定
  • 示例调用方式

Claude 的做法是：

1. 会话启动时，只把所有 Skill 的 name + description 读一遍，放到系统级提示里。
2. 当用户输入与某个 Skill 的描述高度匹配时，Claude 再去把这个 Skill 的完整内容加载到上下文中。

这就是文档里提到的「渐进式披露（Progressive Disclosure）」机制。

2.3 渐进式披露

这个词其实有点装，但装得有点厉害，使用这种方式的原因很直接：Token 成本和性能。

• 初始加载时，每个 Skill 只占用几十个 Token（元信息）。
• 真正用到的时候，才把 SKILL.md 的主体搬进来。
• 如果 Skill 还拆成多个文件，Claude 只会读当前任务需要的那部分。

结论：我们可以放心装很多 Skill，而不用太担心上下文被占满。

2.4 Skill 里可以带代码

文档里也提到，Skill 可以带 Python 脚本等可执行文件。

用途主要有两类：

1. 做确定性计算 / 校验

   • 排序、过滤、格式校验
   • 比如：生成 GIF 之后检查文件大小是否符合 Slack 限制
2. 做简单的集成调用

   • 调一个内部 API
   • 读取一个本地文件，然后把内容返给模型

设计上，有一条很实用的边界：

• 流程和策略写在 SKILL.md
• 需要 100% 确定性 的步骤写在脚本里

模型不负责「每次都从零写代码」，而是调用你已经写好、已经验证过的代码。

3. Skill 和 Tool / MCP 的边界

很多人会把 Skill、Tool、MCP 混在一起，这里做个简单对比方便后面聊 Workflow。

3.1 Skill：教模型「怎么做」

• 把我们的 SOP、套路、模板，变成模型可执行的说明书。
• 适合：

  • 结构化写作
  • 格式转换
  • 合规校验
  • 数据清洗 / 整理
• 优点：

  • 写文档就能做定制
  • Token 成本可控
  • 容易版本化和团队共享

3.2 MCP / Tools：帮模型「去做」

• MCP 解决的是：如何以统一协议，让模型调用外部系统 / 数据源 / API。
• 它关注的是：

  • 怎么查 GitHub
  • 怎么调 CI/CD
  • 怎么查数据库
  • 怎么发 Slack 消息

简要总结就是一句话：Skill 面向流程，MCP 面向集成。

3.3 Skill + MCP 的组合

在一个典型任务里：

• MCP 负责：拿到需要的数据、执行动作
• Skill 负责：拿到这些结果后怎么分析、怎么生成符合规范的输出

这其实已经非常接近我们后面要讲的「Workflow + Agent」的拆分思路。

4. 行业 Workflow：Skill 落地的载体

前面讲的是 Skill 这一颗颗能力点”，接下来要看它们怎么和行业 Workflow 结合。

4.1 Agent 是交互方式，不是业务本身

再强调一次我们之前文章中的观点：Agent 是交互方式，不是业务本身

在行业里，Agent 更适合作为：

• 自然语言入口
• 意图理解与参数提取
• 初步判断和分发

真正的行业壁垒在于：

• 我们内部沉淀的 SOP
• 历史案例和边缘场景处理方式
• 审批链路和风控规则

这些东西，应该放在：

• Workflow 编排系统
• 规则引擎
• Skill + MCP 的组合

而不是「指望一个通用 Agent 自己学出来」。

4.2 为什么不能纯 Agent？

1. 幻觉和确定性冲突

   • 行业里很多流程（财务、生产、安全）对错误零容忍。
   • 1% 的错误率，对于 Demo 可以接受，对生产不行。
2. 过程黑盒，难以审计

   • Agent 的推理链路在模型内部
   • 出现问题难以复盘和归责
   • 很难满足合规和审计要求
3. 成本和延迟

   • 让模型去规划每个按钮、每个 if-else，是在烧算力
   • 这些确定性逻辑用传统代码 / Workflow 做更合适

所以，在企业 / 行业场景里，更现实的模式是：

Workflow + Agent
Agent 做理解和决策，Workflow 做执行和兜底。

5. 「Workflow + Agent」的混合架构

把前面的点合起来，可以得到一个常见的分层结构。

5.1 顶层：意图理解与路由（Agent）

职责只有三件：

1. 理解用户在说什么（意图识别）
2. 把需要的参数补齐（参数提取 + 追问）
3. 决定触发哪个 Workflow / Skill 组合（路由）

流程可以简单画成：

用户 → 自然语言
→ Agent：识别意图 + 提取参数
→ 选中对应 Workflow（或再转给某个二级 Agent）
→ Workflow 执行
→ 结果交给 Agent 格式化给用户

这一步里，Skill 可以怎么用？

• 把「意图分类规范」「参数提取规则」「话术模板」写成一个 Skill
• 在 Skill 里明确：

  • 出现哪些关键词 / 条件时，对应什么意图
  • 提取不到关键信息时，按怎样的模板向用户追问

5.2 中间层：RAG + 决策

有些问题不能直接映射到单个 Workflow，需要先查知识再决定走哪条路。

典型例子：

“设备报警 E03，我该怎么办？”

步骤一般是：

1. Agent 调用 RAG，在知识库中检索 E03 的说明和处理方案。
2. Skill 里定义好：

   • 如何解释错误码
   • 不同错误码对应的处理选项
3. 根据检索结果和规则，决定触发：

   • 远程重启流程
   • 提交工单流程
   • 安排现场工程师流程

这里的组合关系是：

• RAG：提供上下文知识
• Skill：约束「如何做决策、如何提问、如何输出」
• Workflow：完成最终执行动作

5.3 底层：确定性执行（Workflow / RPA / 脚本）

这一层的唯一要求：

不要信模型，要信代码和流程编排。

包括：

• API 调用链
• BPM 流程
• RPA 机器人
• 定时任务
• 数据库操作事务

这里非常适合做成「Skill + MCP + Workflow」的组合：

• Workflow 把一串 API / RPC / 脚本串起来
• MCP 把外部系统包装成标准工具
• Skill 负责：

  • 输入规范
  • 输出规范
  • 错误处理策略
  • 不同状态码的解释

最后返回给 Agent 的应该是：

• 清晰的状态（成功 / 失败 / 部分成功）
• 明确的字段（JSON 等结构化结果）
• 标准错误码和错误信息

5.4 最后一层：结果转述（Agent）

Agent 的工作只是：

• 把结构化结果翻译成人能看懂的话
• 必要时附上详细解释和后续建议
• 避免「编故事」，严格按返回字段说话

在这一步也可以挂一个简单 Skill：

• 统一输出口吻
• 统一敏感信息处理方式
• 统一错误提示文案

6. Skill 在行业 Workflow 里的落地方式

回到文章标题里的核心问题：行业 Workflow 如何通过 Skill 落地？

可以拆成三步。

6.1 把「人做事的方式」变成 Skill

先不碰系统，先去梳理：

• 关键流程当前是怎么执行的？
• 有哪些「资深同事会说：新人容易犯错的点」？
• 有没有文档 / 模板 / 复盘材料？

然后做的事情是：

1. 挑出重复度高、流程相对固定的一批任务。
2. 每个任务建一个 Skill 文件夹，写 SKILL.md：

   • 场景描述：什么时候应该用这个 Skill？
   • 输入要求：有哪些字段，格式是什么？
   • 处理步骤：拆成 1、2、3…
   • 输出规范：JSON 字段 + 人类可读的模板
   • 示例：2~3 个高频真实例子

第一轮不用追求覆盖所有流程，重点是把写 Skill 这件事本身跑顺。

6.2 把「系统做事的方式」变成 Workflow + MCP

接下来梳理现有系统资产：

• 哪些已有 API / 脚本 / RPA 可以直接复用？
• 哪些流程现在是人工填表 + 审批 + 抄数？
• 哪些操作有合规 / 风控要求，必须严格走系统？

然后做：

1. 把可复用的系统能力包装成 MCP / 内部 API。
2. 用我们熟悉的方式编排成 Workflow（BPM / 编排平台 / 自写 Orchestrator）。
3. 明确每个 Workflow 的：

   • 输入结构
   • 输出结构
   • 错误码定义
   • 审计日志

这一步的原则是：

尽量少改存量系统，尽量通过「外面包一层」的方式让它变成可调用的 Workflow 组件。

6.3 用 Skill 把「人」和「系统」连起来

最后一步，把 Skill 作为桥梁：

• 上游：Agent 与用户对话
• 中游：Skill 指导 Agent 该怎么理解、怎么提问、怎么路由
• 下游：Workflow/MCP 真正执行动作

一个典型链路会变成：

1. 用户输入需求
2. Agent 用「意图 Skill」判断任务类型
3. 分发给对应领域 Agent
4. 领域 Agent 读取对应 Skill：

   • 补齐参数
   • 调用 RAG 查规则
   • 决定调用哪个 Workflow
5. Workflow 执行，通过 MCP / API 触达系统
6. 返回结果由领域 Agent 按「输出 Skill」转成年类可读结果
7. Agent 统一封装成对用户的话术

所有「经验」、「SOP」、「注意事项」，尽量沉淀在 Skill 里：

• 方便以后版本升级
• 方便新业务线复用
• 方便做变更审计（Skill 本身可以版本控制）

7. 实施过程中的几个注意点

7.1 先把 Skill 写“够细”，再考虑自动化程度

很多团队上来就想着「全自动」，结果 Agent 兜不住，Workflow 无法覆盖异常，最后完全不敢放生产。

相对稳妥的节奏是：

1. 用 Skill 把流程写细写透，先跑一段时间「人机协同」：

   • Agent 给出建议
   • 人来点确认 / 修改
2. 统计哪些环节几乎没有人工干预
3. 把这些环节下沉成 Workflow，逐步提高自动化比例

这样做有一个副作用：整个流程的「隐性知识」会被 Skill 强制写出来，对组织本身也是一种梳理。

7.2 旧系统是企业的「来时路」

很多看起来陈旧的：

• 定时脚本
• 报文接口
• Excel 宏

从「Workflow + Agent」的角度看都是资产。
Skill 负责解释「什么时候、为什么、怎么用它」，MCP / Workflow 负责「怎么安全调用它」。

相比完全重构，一个实用的策略是：

给旧系统加一个 AI 适配层，而不是要求旧系统「变成 AI 原生」。

7.3 结构化数据回流

Agent 与用户的对话里，有大量可以反哺业务的信息：

• 用户真实需求
• 高频异常
• 流程里的瓶颈点
• 新出现的边缘场景

建议在设计时就准备好：

• 把关键字段结构化写入日志 / 数据库
• 定期用这些数据更新：

  • Skill 内容
  • RAG 知识库
  • 流程设计（Workflow）

不要只留下聊天记录，要留下可分析的行为数据。

8. 小结

把前面的内容合在一起，其实可以简化为三条：

1. Skill 把「怎么做事」固化下来

   • 它是 Agent 的“操作手册”
   • 它让流程可以被描述、复用、版本化
2. Workflow 把「谁来做、何时做、按什么顺序做」编排起来

   • 它对接真实系统和资源
   • 它保证执行的确定性和审计能力
3. Agent 把「人类模糊的需求」翻译成「可以被 Skill + Workflow 执行的指令」

   • 它是交互层和调度层
   • 它不是行业壁垒本身

在这个结构下，“降本增效”不再是一个抽象口号，而是一个比较直观的路径：

• 过去那些无法自动化的非结构化需求（邮件、沟通、模糊指令），
• 通过 Agent + Skill 变成可结构化的任务描述，
• 再通过 Workflow + MCP 交给稳定的代码和系统去执行。

从研发团队视角看，这套东西真正改变的是工作方式：

• 从「写提示」变成「设计并维护一套可执行流程」；
• 从「做一次性 Demo」变成「搭一套能长期演进的智能基础设施」。

如果你正在做行业 Agent，或者准备在内部推一个 AI 助手，可以先从一件事开始：

挑一个你们团队最常做、步骤最清晰、但最浪费时间的任务，把它完整写成一个 Skill，再把现有系统封装成一个 Workflow。
这两个拼起来，基本就是你们自己的第一个「行业 Workflow + Agent」原型。

以上。

过去一年，AI Agent 从狂热逐渐回归理性。在企业级应用和垂直行业落地中，我们看到了一个趋势：在行业中，纯粹依靠 Agent 自主决策的构想，正在被「Workflow + Agent」的混合模式所取代。

对于我们一线的同学来说，最重要的是要去解决实际问题。

当前我们能看到的行业 Agent 大多数实际落地的逻辑是：行业 Agent 的壁垒在于行业 Know-how，而落地的最佳路径是利用 Agent 做交互与分发，利用 Workflow 做执行与兜底。

1. 行业 Agent 是什么

很多人把 Agent 想象成一个全能的「超级员工」，指望给它一个模糊的目标（比如“帮我提升下季度销售额”），它就能自动拆解任务、调用工具、完成工作。在通用领域或简单场景下（如订机票、写周报），这或许可行。但在垂直行业（金融、制造、医疗、物流等），这种纯 Agent 模式目前是行不通的。

1.1 Agent 是交互方式，不是业务本身

Agent 在行业应用中的本质，是入口和交互。

它改变了人与系统的互动方式。以前我们需要点击菜单、填写表单、通过 SQL 查询数据库；现在我们可以通过自然语言表达意图。Agent 的核心价值在于它能“听懂”用户的意图，并将其转化为系统能理解的指令。

1.2. 真正的壁垒是行业 Know-how

大模型本身是通用的。GPT-5 或者是 Claude 4.5，它们具备的是通用的逻辑推理能力和语言能力，但它们不懂你们公司的复杂的审批流程，不懂某个特定设备的维修手册，也不懂行业内潜规则式的业务逻辑。

行业 Agent 的「行业」二字，才是重点。

• 什么是 Know-how？ 是我们沉淀了十年的 SOP，是数据库里积累的边缘案例，是针对特定业务场景的异常处理机制。
• Agent 的角色： 它是这些 Know-how 的「调度员」，而不是「创造者」。

如果脱离了行业 Know-how，Agent 就是一个会说话但办不成事的空壳。

2. 为什么「纯 Agent」模式在企业端走不通？

在 Demo 阶段，我们经常看到这样的演示：用户说一句话，Agent 自动规划了五个步骤，调用了三个 API，完美解决了问题。

但在生产环境中，这种全自动的「纯 Agent」模式面临三个无法回避的死结：

2.1 幻觉与确定性的冲突

企业级应用，尤其是涉及到资金、生产安全、合规的场景，稳定压倒一切。 大模型的本质是概率预测，这意味着它永远存在「幻觉」的可能性。哪怕准确率做到 99%，那剩下的 1% 的不可控对于企业核心流程来说也是灾难。

你无法向审计部门解释，为什么系统批准了一笔违规报销，仅仅因为 Agent 觉得「这看起来没问题」。

2.2 流程的黑盒化

纯 Agent 模式下，决策过程往往隐藏在模型的推理链中。当出现问题时，很难复盘和追责。企业需要的是可审计、可监控、可干预的流程。

2.3 成本与延迟

让大模型去规划每一个微小的步骤（比如“点击确认按钮”、“校验手机号格式”），是对算力的巨大浪费。这些确定性的逻辑，用传统的代码实现既快又准，用 LLM 去推理则是大炮打蚊子，且增加了响应延迟。

3. Workflow + Agent 的混合模式

既然大模型的幻觉无法根除，而传统软件的确定性又是刚需，最务实的方案就是将两者结合：Workflow + Agent。

这是一个“动静结合”的架构。

• Workflow（工作流/RPA）： 负责“静”。它是骨架，是肌肉。它包含固定的业务逻辑、SOP、API 调用序列。它保证了核心流程的确定性和可靠性。
• Agent（大模型）： 负责“动”。它是大脑，是神经。它负责理解非结构化的输入（自然语言），进行意图识别，然后决策应该触发哪一条 Workflow。

3.1 核心逻辑

Agent 不直接去操作底层数据库或核心系统，Agent 的输出对象是 Workflow。

• 用户 -> 对话 -> Agent (理解意图/参数提取) -> 触发 -> Workflow (执行/校验) -> 返回结果 -> Agent (格式化输出) -> 用户

3.2 这种模式解决了什么问题？

1. 复用历史沉淀： 企业过去十年建设的 ERP、CRM、以及各种自动化脚本（RPA），不需要推倒重来。它们被封装成一个个 Workflow，成为 Agent 的「工具箱」。
2. 控制风险： 所有的执行动作（写库、转账、发货）都由 Workflow 控制，Workflow 内部包含严格的校验逻辑（If-Else），这是大模型无法绕过的硬规则。
3. 降低成本： 只有在需要理解和决策的环节才消耗 Token，大量的执行环节由低成本的代码完成。

4. 如何设计混合模式

在具体落地时，我们需要构建一个分层的架构体系。

4.1 意图理解与分发

这是系统的入口。用户输入的往往是模糊的、非结构化的自然语言。 这一层的核心任务不是「解决问题」，而是「定义问题」。

• 意图识别： 判断用户是想「查询库存」、「发起退款」还是「投诉建议」。
• 参数提取： 从对话中提取执行 Workflow 所需的关键参数（如订单号、日期、金额）。如果参数缺失，Agent 需要反问用户进行补全。
• 路由分发： 基于意图，将任务指派给具体的 Workflow 或下一级更专业的 Agent。

关键点： 这一层需要极强的语义理解能力，通常需要配合 RAG 来理解特定领域的术语。

4.2 动态决策与 RAG

在某些复杂场景下，直接映射到 Workflow 是不够的。 比如用户问：“我的设备报警代码是 E03，我该怎么办？”

这里不能直接触发一个“维修流程”，因为 Agent 首先需要知道 E03 代表什么。

• RAG 的介入： Agent 调用知识库，检索 E03 对应的故障原因和处理手册。
• 初步决策： 基于检索到的 Know-how，Agent 判断是建议用户重启（触发“重启指引 Workflow”），还是必须派人维修（触发“工单提交 Workflow”）。

关键点： RAG 在这里不仅仅是用来回答问题的，更是用来辅助 Agent 做路由决策的。

4.3 确定性执行（Workflow / RPA）

这是系统的执行层，也是“行业 Know-how”固化最深的地方。 这一层严禁幻觉。

• 形式： 它可以是一个 API 接口，一个 Python 脚本，或者是一个复杂的 BPM（业务流程管理）实例，甚至是一个 RPA 机器人。
• 逻辑： 这里面充满了 If-Else、Try-Catch 和数据库事务。
• 反馈： Workflow 执行完毕后，必须返回明确的状态码和结果数据（JSON 格式），而不是一段模糊的文本。

4.4 结果综合与反馈

Workflow 返回的是结构化数据（例如：{"status": "success", "order_id": "12345", "delivery_date": "2023-12-01"}）。 Agent 的最后一步工作，是将这些冷冰冰的数据，转化为符合人类阅读习惯的自然语言，反馈给用户。

5. 多级 Agent 与 RAG 的协同

在简单的场景下，一个 Agent 配合几个 Workflow 就够了。但在复杂的行业场景（如供应链管理、大型设备运维）中，我们需要更复杂的拓扑结构。

5.1 多级 Agent 架构

不要试图训练一个全知全能的上帝 Agent。应该采用“主帅-将军-士兵”的层级结构。

• L1 调度 Agent（主帅）： 只负责宏观分类。例如，判断是“售前咨询”还是“售后维修”。
• L2 领域 Agent（将军）： 专注于特定领域。例如，“售后 Agent” 拥有查询保修、解读故障码、预约工程师的能力。
• L3 执行单元（士兵）： 具体的 Workflow 或特定的单一功能 Agent。

这种结构的好处是解耦。当售后流程发生变化时，只需要调整 L2 Agent 和对应的 Workflow，不会影响到售前部分。

5.2 RAG 的逻辑化应用

传统的 RAG 主要是为了解决“回答知识性问题”。在混合模式中，RAG 的作用被放大了。

• 动态 Prompt 注入： 在执行 Workflow 之前，系统可以根据当前的上下文，利用 RAG 从知识库中检索出相关的规则或注意事项，动态注入到 Agent 的 Prompt 中。

  • 例子： 在处理一笔“退款”请求时，RAG 检索到“该用户是 VIP 且信用极好”，将此信息注入 Prompt，Agent 可能会选择触发“极速退款 Workflow”而不是“常规审核 Workflow”。

6. 落地实战中的思考

在实施“行业 Workflow + Agent”模式时，有几个非技术性的坑需要注意。

6.1 人机协同

在很长一段时间内，Agent 不会完全取代人，而是成为人的 Copilot 在设计 Workflow 时，必须预留人工介入的节点。 当 Agent 的置信度低于某个阈值，或者 Workflow 执行遇到异常时，系统应自动升级为人工服务，并将之前的上下文完整传递给人工客服。

6.2 存量资产的价值

很多技术团队在做 AI 转型时，倾向于重构一切。这是错误的。 你们公司遗留的那些看起来陈旧的 API、跑了五年的定时脚本、甚至 Excel 里的宏，都是宝贵的资产。 Agent 的落地应当是「局部改造」而非「推倒重来」。 我们要做的，是给这些老旧的系统加上一个 AI 适配层，让 Agent 能够调用它们，而不是替换它们。

6.3 结构化数据的回流

Agent 与用户的交互过程，产生了大量高质量的数据。 不要让这些数据只停留在对话日志里。需要设计机制，将 Agent 收集到的信息（如用户的新需求、报错的高频词、Workflow 的执行结果）结构化地回流到业务系统中，用于优化 SOP 和微调模型。

7. 小结

行业 Agent 的未来，不是科幻电影里的全自动机器人，而是严谨的工程化实践。

我们不需要一个会写诗的 AI，我们需要的是一个能准确理解工单意图，并由后台的 Workflow 准确执行的系统。

• Agent 是面子：提供极简的交互，理解复杂的意图。
• Workflow 是里子：承载行业壁垒，保证执行的绝对可靠。
• RAG 是底子：提供动态的上下文和知识支撑。

降本增效不是靠引入一个昂贵的大模型来实现的，而是靠大模型把过去那些难以被自动化的“非结构化需求”，转化为了可以被低成本代码执行的“结构化指令”。

这才是行业 Agent 的落地。

这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点：距离越远，信息越模糊。一小时前的事记得清楚，一年前的事几乎忘光；10 厘米的东西看得清楚，20 米外的东西就模糊了。

DeepSeek 把这个生物学现象转化成了工程实现：近期对话用高分辨率保存，一周前的对话降到中等分辨率，久远的记忆压缩到最小。信息随时间自然衰减，就像人类遗忘一样。

这让我想到 Agent 记忆系统设计的本质问题。

1. 为什么 Agent 需要记忆

上下文窗口和记忆是两码事。

上下文窗口只是让模型一次看到更多对话，像是扩大了工作台。但记忆不同，它让 Agent 能保存、更新和选择性回忆信息。没有记忆，Agent 就像得了失忆症，每次对话都从零开始。

现在大家都在追求更大的上下文窗口，从 8K 到 32K，再到 128K、1M。但这种暴力扩张有个问题：计算成本呈二次方增长。处理 100K tokens 的成本是 10K tokens 的百倍。而且，把所有信息一股脑塞给模型，反而可能让它迷失在细节中。

记忆系统的价值在于选择性保留。

不是所有信息都值得记住，也不是所有信息都需要同样的精度。

2. Agent 记忆的层次结构

AI Agent 的记忆系统可以分成几个层次：

短期记忆（工作记忆）
这是 Agent 的记事本，保存当前对话和正在处理的任务。典型容量在几千到几万 tokens。没有它，Agent 会在对话中途失去思路，问你刚才说了什么。

长期记忆
这是跨会话的持久化存储。用户下次回来，Agent 还记得之前的交互。长期记忆又可以细分：

• 事实记忆：保存确定的信息，比如用户姓名、偏好、角色定义。这些信息需要随情况更新，保持”当前真实状况”。
• 情景记忆：记录具体经历，什么时候发生了什么，结果如何。这给 Agent 一种时间连续感，能回顾过去的决策。
• 语义记忆：组织概念和关系的知识网络。让 Agent 理解”数据库慢”和”查询延迟高”是相关问题。

3. 遗忘机制是有用的

人类会遗忘，不是大脑容量不够，而是遗忘让我们更高效。

想象一下，如果你记得生活中的每个细节：每顿饭的味道、每次呼吸的感觉、路过的每个行人的脸。这些信息会淹没真正重要的记忆。遗忘是一种过滤机制，帮我们保留有价值的信息。

Agent 也需要这种机制。随着交互增加，历史数据会无限增长。如果不加选择地保存所有内容，会面临几个问题：

1. 存储成本：每个用户的历史数据都完整保存，存储需求会爆炸式增长。
2. 检索效率：在海量历史中找到相关信息越来越慢。
3. 注意力分散：太多无关信息会干扰 Agent 的决策。
4. 隐私风险：永久保存所有对话增加了数据泄露的风险。

4. 用分辨率模拟时间衰减

DeepSeek 的做法是：把历史对话渲染成图像，然后用不同的分辨率来编码。

近期对话用高分辨率（Gundam 模式，800+ tokens），保留完整细节。

一周前的对话用中等分辨率（Base 模式，256 tokens），保留主要内容。

久远的历史用低分辨率（Tiny 模式，64 tokens），只留个大概印象。

这样做的好处是：

1. 不需要丢弃历史信息，所有对话都保留着
2. 但远期信息自然”淡化”，占用的 token 越来越少
3. 模拟了人类记忆的衰减曲线

具体实现上，他们会：

1. 把超过一定长度的历史对话渲染成图像
2. 第一次压缩，让 token 减少 10 倍
3. 上下文再次超长时，进一步降低分辨率，再压缩 10 倍
4. 随着时间推移，图像越来越小，内容越来越模糊，模型也就逐渐”读不清”了

这种方式不是简单的截断或删除，而是让信息随时间衰减——就像人类记忆一样。

5. 理论上无限的上下文

如果这个思路走通了，就能实现”理论上无限的 context window”。

这里的无限不是真的无限，而是通过分层压缩，让历史信息的存储成本趋近于常数。

我们不需要保持所有信息的高保真度，只需要让信息按重要性和时效性衰减。

最近的对话，全保留。
一周前的，压缩一次。
一个月前的，再压缩一次。
半年前的，只留个印象。

这样，计算资源始终聚焦在最重要的”近期”信息上，而久远的历史虽然还在，但只占用很少的 token。

从成本角度看，这比无脑扩大上下文窗口要合理得多。

6. 记忆管理的工程实践

在实际的 Agent 系统里，记忆管理通常分几个层次：

会话级记忆——当前对话的上下文，存在内存里，对话结束就清空。这部分可以直接用模型的上下文窗口。

用户级记忆——持久化存储，用向量数据库或 KV 存储。每次对话时，根据当前问题检索相关的历史记忆，注入到 prompt 里。

全局知识库——所有用户共享的知识，比如产品文档、技术规范、FAQ。这部分通常用 RAG（检索增强生成）来处理。

关键是如何在这些层次之间做好信息流转和优先级管理。

比如，用户刚说过的话，优先级最高，直接放在 prompt 前面。一周前的对话，需要检索后才注入。一个月前的，可能只保留摘要。

这种分层策略，和 DeepSeek 的分辨率衰减思路是一致的——让资源消耗和信息重要性成正比。

7. 遗忘不是丢失

这里需要明确的是，遗忘不等于删除。

人类的遗忘，是提取变难了，不是信息消失了。在特定的提示下，很多”遗忘”的记忆还能被唤起。

Agent 的记忆也应该这样设计。

低分辨率的历史对话，在大部分场景下不会被激活，但如果用户明确提到某个时间点的事情，系统可以重新加载那段历史的高分辨率版本。

这需要一个索引机制，能根据时间、主题、关键词快速定位到历史片段。

像 Manus 所使用的文件系统就是这样一种索引机制。

遗忘是常态，召回是特例。这样才能在效率和完整性之间找到平衡。

8. 什么值得记住

并不是所有对话都需要长期保存。

大量的对话是重复的、临时的、没有上下文依赖的。比如简单的问候、重复的确认、无关紧要的闲聊。

这些内容可以在会话结束后直接丢弃，不需要进入长期记忆。

真正值得记住的，是那些包含决策、偏好、关键信息的交互。

比如：

• 用户明确表达的需求和偏好
• 重要的决策节点和原因
• 反复出现的问题和解决方案
• 用户的角色、职责、技术栈等基础信息

这需要在记忆写入时做判断和过滤。可以用一个小模型或规则引擎，评估每轮对话的重要性，决定是否持久化。 Gemini Code 就是这么干的。

不是所有东西都值得记住，筛选本身就是一种优化。

9. 记忆的更新和冲突

长期记忆不是只写不改的日志，它需要能更新。

用户的偏好会变，角色会变，之前的信息可能过时或错误。

比如用户之前说喜欢中古风的家具，后来又说喜欢北欧风，这个信息需要更新，而不是简单地追加一条新记录。

如果只追加不更新，记忆会越来越冗余，甚至出现矛盾。

一个好的记忆系统，需要能识别冲突，做合并和覆盖。

这可以通过实体识别和关系抽取来实现。把对话内容结构化成三元组（主体-关系-客体），然后在写入时检查是否和已有记忆冲突。

如果冲突，可以根据时间戳、置信度等因素决定是更新还是保留多个版本。

记忆管理的复杂度，不亚于写一个小型数据库。

10. 压缩不只是技术问题

回到 DeepSeek 的光学压缩思路，它的价值不只是技术实现，更重要的是提供了一个思维框架。

我们习惯于把上下文长度当作硬指标——越长越好。但这个论文提醒我们，长度和质量不是一回事。

有时候，适度的遗忘反而能提升系统的整体表现。

有如下的好处：

1. 减少了无关信息的干扰
2. 降低了计算成本
3. 让模型专注于最相关的内容

这和人类的认知机制是一致的。我们不会带着所有历史记忆去做每一个决策，而是根据当前情境激活最相关的那部分。

Agent 应该学会做同样的事。

11. 成本和效果的平衡

从成本角度看，无限扩展上下文是不可持续的。

假设一个 Agent 系统，每天处理 1000 次对话，每次对话平均 10 轮，每轮 500 tokens。

如果所有历史对话都全量保留，一个月下来，单个用户的上下文就会达到 1500k tokens。

如果有 1000 个活跃用户，每次推理都带上完整上下文，token 消耗会是天文数字。

但如果用分层记忆 + 遗忘机制：

• 最近 3 天的对话，全保留
• 一周到一个月的，压缩 50%
• 一个月以上的，压缩 90%

token 消耗可能降低到原来的 10%-20%，而对实际效果的影响很小。

因为大部分场景下，用户关心的就是最近的对话。

12. 记忆应该是系统能力

很多团队把记忆功能当作一个独立的我来开发——加个数据库，存一下历史，检索一下注入。

但这样做的效果往往不好。

因为记忆不是一个功能模块，而是整个 Agent 系统的底层能力。

它需要和 prompt 设计、工具调用、推理链路、错误处理深度集成。

比如：

• Prompt 需要为记忆预留位置和格式
• 工具调用的结果需要写回记忆
• 推理过程中需要动态检索记忆
• 错误发生时需要回溯历史上下文

记忆管理做得好，Agent 的整体表现会有质的提升。做得不好，就只是一个会话机器人。

13. 一些建议

以下是一些可以尝试落地的建议：

1. 不要把所有历史都塞进 prompt

很多团队的做法是，每次调用都把所有历史对话拼接到 prompt 里。这在对话轮数少的时候没问题，但规模上去后会成为瓶颈。

改成检索式注入——根据当前问题，从历史记忆里检索最相关的几条，而不是全量加载。（这里就会考量检索的能力了）

2. 区分会话记忆和持久记忆

当前对话的上下文，存在内存里就行，不需要持久化。

只有那些需要跨会话保留的信息，才写入数据库。

这样可以大幅减少存储和检索的开销。

3. 给记忆加上过期时间

就像缓存一样，记忆也可以有 TTL（Time To Live）。

一般性的对话，可以设置 7 天或 30 天过期。重要的信息，可以标记为永久保留。

定期清理过期记忆，防止数据无限膨胀。

4. 用好向量数据库

向量检索是目前最适合做语义记忆的技术。

把历史对话做 embedding，存到向量数据库里，每次根据当前问题做相似度检索。

但要注意，向量检索的召回率不是 100%，需要结合关键词索引和时间过滤。

5. 记忆要能解释

用户问”你为什么这么回答”，Agent 应该能说清楚是基于哪段历史记忆做的判断。

这需要在记忆检索时保留溯源信息——这条记忆来自什么时间、什么对话、可信度如何。

可解释性不仅是用户体验问题，也是调试和优化的基础。

14. 最后

上下文记忆和遗忘，本质上是资源分配问题。

我们只有有限的 token 预算，有限的计算资源，有限的响应时间，需要在这些约束下做出最优决策。

无限扩展上下文听起来很美好,但实际上不可行。

真正的解决方案，是学习人类的记忆机制——让重要的信息留下来，让次要的信息自然衰减。

DeepSeek 的光学压缩思路提供了一个很好的启发：遗忘不是缺陷，而是一种优化策略。

如果能把这个思路落地到 Agent 系统里，不仅能降低成本，还能提升整体的智能水平。

因为真正的智能，不是记住所有东西，而是知道什么值得记住，什么可以忘记。

从而也就无法看到一句话就完成所有的事情，需要有专业的人在旁边盯着。

甚至出现了一个新的名词：大模型善后工程师

并且那种自动多的 AI Agent ，面对的大多数是对于幻觉，有一定容错的场景，如自动化报告生成，陪伴语聊。

那些无法容错的场景， AI Agent 就必须要人工审核或者带审计的工作流来完成。

为什么在准确性要求比较高的 AI Agent 都变成了工作流？

看一下我们常见的 AI Agent 逻辑：

收到用户输入 → 判断意图 → 调用对应的模块 → 整理输出 → 返回结果

这跟我们想象中的 Agent 差距很大。理想中的 Agent 应该像一个真正的助手，能理解复杂的需求，自主规划执行路径，遇到问题能灵活调整策略。但现实是，大部分产品都在用固定的流程来约束 AI 的行为。

为什么会这样？核心原因是大模型本身的特性决定的。

大模型的能力边界在哪里

大模型确实很强大，但它有明确的能力边界。

第一个边界是可靠性。大模型的输出本质上是概率分布，每次生成都有不确定性。同样的输入，可能得到不同的输出。这种不确定性在聊天场景下可以接受，但在准确率要求比较高的生产环境中就是个大问题。比如一个财务报表分析的 Agent，我们是无法接受它今天说利润率是 15%，明天又说是 18%。

第二个边界是准确性。大模型的训练数据是有截止时间的，而且它没有实时获取信息的能力。更重要的是，它会产生幻觉——看起来很有道理，但实际上是错的。一个合同审核的 AI Agent，引用了一条根本不存在的法律条款，差点出事。

第三个边界是执行能力。大模型本质上是一个文本生成器，它不能直接操作系统、调用 API、访问数据库。所有这些能力都需要额外的工程实现。而一旦涉及到外部系统的调用，就必须有明确的权限控制和错误处理，这又把我们拉回到工作流的思路上。

第四个边界是成本。完全放开让大模型自主决策，意味着大量的 token 消耗。一个复杂任务可能需要多次推理、多次调用，成本会急剧上升。在我们做 AI Agent 之初，成本问题就是一个要着重考虑的问题。我最近用得比较多的编程 Agent，就因为成本问题，把之前的收费逻辑做了颠覆式的变化，作为一个用户，最直观的感受就是费用暴增。

使用工作流是一种现实

面对这些边界，工作流成了一个自然的选择。

工作流解决了可控性问题。通过预设的流程，我们能确保 AI 的行为在可控范围内。每一步该做什么、不该做什么，都有明确的定义。这对企业应用来说至关重要。没有哪个企业敢把关键业务交给一个完全不可控的系统。

工作流解决了准确性问题。在工作流的每个节点，我们可以加入验证和校准机制。比如在数据查询环节，直接调用数据库而不是让大模型猜测；在关键决策点，加入人工审核环节。这样既利用了大模型的能力，又避免了它的短板。

工作流还解决了成本问题。通过流程优化，我们可以精确控制大模型的调用次数和方式。简单的任务用小模型或规则引擎处理，复杂的任务才调用大模型。这种分层处理大大降低了运营成本。

更重要的是，工作流让产品可以迭代优化。每个环节的表现都可以监控和改进，哪里出问题就改哪里，而不是面对一个黑盒束手无策。

如何设计一个好的工作流 Agent

既然工作流是当前的现实，那怎么设计一个好的工作流 Agent？

1. 任务拆解。把复杂的任务拆解成多个简单、明确的子任务。每个子任务都有清晰的输入输出定义。比如一个智能客服 Agent，可以拆解为：意图识别、信息提取、知识检索、答案生成、对话管理等模块。
2. 模块化设计。每个模块独立开发和优化，通过标准接口连接。这样的好处是可以灵活替换和升级。今天用规则引擎的地方，明天可以换成机器学习模型；现在用 GPT-4 的地方，以后可以换成更合适的专用模型。
3. 状态管理。工作流需要维护整个对话或任务的上下文状态。这不仅包括用户的历史输入，还包括中间结果、系统状态等。良好的状态管理是实现复杂交互的基础。
4. 异常处理。每个环节都可能出错，需要有完善的异常处理机制。比如大模型返回了不合预期的结果怎么办？外部 API 调用失败怎么办？这些都需要提前考虑。
5. 人机协同。在关键环节保留人工介入的接口。这不是技术不行，而是业务需要。很多场景下，人工审核是合规要求，也是质量保证。总得有人背锅不是，毕竟 AI 背不了锅。

工作流的局限性

工作流虽然解决了很多问题，但也有明显的局限性。

第一是灵活性不足。预设的流程很难应对所有情况，遇到流程外的需求就无能为力。这也是为什么很多 Agent 给人感觉很”笨”的原因——它只会按照固定的套路来。

第二是开发成本高。设计一个完善的工作流需要深入理解业务逻辑，每个流程都需要大量的开发和测试。而且业务变化时，工作流也需要相应调整，维护成本不低。

第三是用户体验的割裂感。用户能明显感觉到自己在跟一个程序打交道，而不是一个智能助手。特别是当工作流设计不够自然时，这种割裂感会更强。

预想可能的发展

尽管当前工作流是主流，但技术还在快速发展。

模型能力在提升。新一代的大模型在准确性、稳定性上都有改进。特别是针对特定领域的专用模型，表现越来越好。比最新上的 Qwen3-Max 就针对工作流，工具调用有了特别的优化。这为减少工作流的约束提供了可能。

工具调用能力在增强。Function Calling、Tool Use、MCP，以及最新的 SKILLS 等技术让大模型能更好地与外部系统交互。虽然本质上还是工作流，但流程可以更动态、更智能。

多模态融合带来新可能。不只是文本，图像、语音、视频等多模态信息的处理能力都在提升。这让 Agent 能处理更复杂的任务，提供更自然的交互。

强化学习和自主学习是长期方向。让 Agent 从交互中学习，不断改进自己的策略。虽然现在还不成熟，但这是实现真正自主 Agent 的关键。

产品化的思考

做 AI Agent 产品，技术只是一部分，更重要的是产品思维。

首先要明确定位。你的 Agent 是要解决什么问题？为谁解决？解决到什么程度？不要试图做一个万能的 Agent，那样最后什么都做不好。现在很火的小鹏的机器人，其有 80 个控制点，相对于宇树的 20 个控制点，其灵活性肯定要高一些，但是其场景和定位是完全不一样的，成本也不一样。

其次是场景选择。选择那些容错率相对高、价值明确的场景。比如内容创作辅助就比财务决策更适合当前的技术水平。在合适的场景下，即使是工作流 Agent 也能创造很大价值。

然后是预期管理。不要过度承诺，要让用户清楚产品的能力边界。与其说这是一个智能助手，不如说这是一个智能工具。合理的预期能减少用户的失望，提高满意度。

还要重视数据积累。每一次用户交互都是宝贵的数据。通过分析这些数据，我们能发现工作流的不足，找到优化的方向。数据驱动的迭代是产品成功的关键。

最后是成本控制。AI Agent 的运营成本不低，必须找到合理的商业模式。是订阅制还是按量付费？是 To B 还是 To C？这些都需要根据产品特性和市场情况来决定。

实践中的几个关键点

基于这段时间的观察和实践，有几个点特别重要。

第一，不要迷信技术。大模型很强大，但它不是银弹。很多问题用传统方法解决更高效、更可靠。关键是找到合适的技术组合。

第二，重视工程实现。一个好的想法到一个可用的产品，中间有大量的工程工作。提示词优化、结果解析、错误重试、性能优化，这些看似琐碎的工作往往决定产品的成败。

第三，持续迭代。AI Agent 产品很难一步到位，需要不断根据用户反馈来改进。建立快速迭代的机制，小步快跑，逐步逼近理想状态。

第四，关注安全和合规。AI 的不可控性带来了新的安全风险。数据隐私、内容安全、决策可解释性，这些都需要提前考虑。特别是在企业级应用中，合规往往是第一要求。

第五，建立评估体系。怎么衡量一个 Agent 的好坏？准确率、响应时间、用户满意度、成本效率，需要建立全面的评估指标。只有能量化，才能持续优化。

写在最后

做 AI Agent 产品这段时间，最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI，但现实的技术约束让我们不得不妥协。

但这未必是坏事。工作流让 AI 变得可控、可靠、可用。在当前的技术条件下，一个设计良好的工作流 Agent，往往比一个不受约束的”智能” Agent 更有价值。

关键是要认清现实，在约束中寻找创新的空间。大模型的边界是客观存在的，但边界之内仍然有广阔的天地。工作流不是终点，而是通向更智能的 Agent 的必经之路。

技术在进步，产品在迭代，市场在成熟。今天的工作流 Agent，可能就是明天自主 Agent 的雏形。重要的不是等待完美的技术，而是用现有的技术创造价值，在实践中推动进步。

这个领域还很年轻，充满了可能性。无论是技术突破还是产品创新，都有大量的机会。保持理性的乐观，脚踏实地地推进，相信我们能做出真正有用的 AI Agent 产品。

毕竟，每一个伟大的产品，都是从不完美开始的。

以上。

换句话说，大家觉得 Agent 不怎么聪明。

1. AI Agent 到底哪里不聪明

可能是以下的方面：

1. 业务理解能力差。很多 AI Agent 看起来能对答如流，但一涉及到具体业务场景就开始答非所问。先不说原因，原因后面再细讲。
2. 执行能力有限。在大家的预期中 AI Agent 应该能自主规划和执行任务，但实际上大部分所谓的 AI Agent 还停留在”问一句答一句”的阶段。我们想像中的一句话需求，如”帮我分析这份财报并生成投资建议”，大部分 AI Agent 是搞不定的，类似于 Manus 这种勉强可以的，但其结论是否能参考也是存疑的。
3. 可控性差。我们一方面希望 Agent 有自主能力，能像人一样灵活处理问题；另一方面又希望它的行为可预测、可控制。这本身就是个悖论。结果就是，要么 Agent 太死板，只能按预设流程走；要么太「聪明」，经常做出一些让人意外的操作。
4. 定制成本高。这本来不是聪明的问题，但这是聪明的代价，每个企业的业务都有自己的特殊性，要让 Agent 真正理解并适应这些特殊性，需要大量的定制化工作。但问题是，很多企业并没有这个技术能力或者预算来做深度定制。

2. 为什么会出现这些问题

我觉得主要是三方面的原因：

1. 过高的预期。过去一年，AI Agent 的概念被炒得太热了。各种厂商都在宣传 Agent 能够”完全替代人工”、”自主完成复杂任务”。但实际上，现在的技术水平离这个目标还有很大距离。有的老板，听了厂商的宣传后，真的以为买个 Agent 产品就能替代掉几个员工。结果上线后发现，不仅没法替代人，反而需要专人来”照顾”这个 Agent，教它怎么工作，纠正它的错误。
2. 模糊的产品定位。现在市面上的 Agent 产品，很多都想做成”万能助手”。但越是想什么都做，越是什么都做不好。反而是那些专注于特定场景的 Agent，比如专门做客服的、专门做数据分析的，效果会好很多。
3. 技术栈的割裂。做好一个 Agent，需要模型能力、工程能力、业务理解能力的深度结合。但往往懂模型的不懂业务，懂业务的不懂模型，懂工程的可能两个都不太懂。这种割裂导致做出来的产品总是差那么一些。

3. 当前谁最有优势？

答案是：SaaS 公司。

在 AI Agent 落地上，SaaS 公司有着天然的优势。

SaaS 公司最大的优势是接近客户和数据。他们天天跟客户打交道，知道客户的真实需求是什么，痛点在哪里，实际的业务流程是怎样的。更重要的是，他们手里有大量的业务数据和场景数据，这些数据对于训练和优化 Agent 来说是无价之宝。

举个例子，一家做 CRM 的 SaaS 公司，如果要做销售 Agent，它有几个天然优势：

第一，它知道销售的真实工作流程是什么样的。不是理论上的流程，而是实际操作中的流程，包括各种例外情况和潜规则。

第二，它有大量的销售数据。什么样的话术转化率高，什么时间打电话效果好，不同行业的客户有什么特点，这些数据都在它的系统里。

第三，它有现成的客户界面。不需要重新教育客户怎么使用 Agent，可以直接嵌入到现有的产品里。

第四，它有持续优化的能力。客户每天都在使用它的产品，产生新的数据，这些数据可以用来持续优化 Agent 的表现。

相比之下，纯做 AI 的公司，虽然模型能力很强，但在落地时往往会遇到各种水土不服的问题。

4. 垂直场景的突破

在个人粗浅的认知中，Agent 的突破口在于垂直场景，而不是通用场景。在于需要 Konw-How 的场景。

为什么？因为垂直场景有几个优势：

第一，需求明确，专注。不需要 Agent 什么都会，只需要它把一件事做好就行。

第二，数据充足。垂直场景往往有大量的历史数据可以用来训练和优化。

第三，容错率高。因为场景固定，出现意外情况的概率较低，即使出现了也比较容易处理。

第四，ROI 清晰。在垂直场景下，Agent 的价值很容易量化。

比如法律文书撰写、行业分析、代码生成这些场景，都是合适的 Agent 应用场景。这些场景有明确的输入输出，有清晰的质量标准，有大量的历史数据，非常适合 Agent 来处理。

5. 可预测与可掌控的矛盾

在 ToB 场景下，企业客户最怕的就是不确定性。如果一个 Agent 今天的回答和明天的回答不一样，或者在关键时刻做出了意料之外的决策，那对企业来说不可接受的。

但是，客户又希望 Agent 有自适应能力，能够灵活处理各种情况。

当前的解决方案基本上是两个极端：

1. 完全用 Workflow 来定义 Agent 的行为。每一步做什么都规定得清清楚楚，Agent 只是一个执行者。这样做的好处是完全可控，坏处是太死板，失去了 Agent 的灵活性。
2. 完全放开，让 Agent 自己去学习和适应。这样做的好处是灵活，能处理各种意外情况，坏处是不可控，你永远不知道它下一步会做什么。

比较理想的方案应该是两者的结合：在关键决策点上用 Workflow 来控制，在具体执行上给 Agent 一定的自主权。但这说起来容易，做起来很难。需要对业务有深入的理解，知道哪些地方需要控制，哪些地方可以放开。

6. 模型能力 vs 工程能力

要解决这些矛盾和问题需要模型和工程两方面的提升，并且现阶段工程能力可能比模型能力更重要。

为什么？

因为现在的大模型能力其实已经不错了，GPT-5、Claude、DeepSeek 这些模型的理解和生成能力都很强。真正的瓶颈在于如何把这些能力转化成实际的业务价值。

这就需要大量的工程工作：

• 如何设计合理的 Prompt，让模型理解业务需求
• 如何构建知识库，让模型能够获取必要的信息
• 如何设计工作流，让模型的输出能够被系统消费
• 如何做异常处理，保证系统的稳定性
• 如何做监控和优化，持续提升系统表现

这些工作属于比较累和碎的活儿，不如训练模型那么「高大上」，但却是 Agent 能否落地的关键。

7. 安全问题

AI Agent 的安全问题不仅仅是数据泄露，更大的问题在于，Agent 可能会做出一些不当的决策或者操作。

比如，一个有权限访问企业数据库的 Agent，如果被恶意引导，可能会删除重要数据或者泄露敏感信息。一个负责采购的 Agent，如果判断失误，可能会下错订单，造成巨大损失。如此种种……

现在的解决方案主要是加各种限制和审核机制，但这又回到了前面的矛盾：限制越多，Agent 就越不「智能」。

8. 可能的未来

基于目前的情况，我觉得接下来的一段时间 Agent 的发展会有几个趋势：

第一，从通用到垂直。越来越多的 Agent 会专注于特定的场景和行业。

第二，从替代到增强。Agent 的定位会从「替代人工」转变为「增强人工」。

第三，从单点到系统。不再是一个个孤立的 Agent，而是多个 Agent 协同工作的系统。

第四，从产品到服务。Agent 不再是一个买来就用的产品，而是需要持续优化的服务。

这些趋势意味着什么？

意味着 Agent 市场会越来越理性，泡沫会逐渐消失，真正有价值的应用会脱颖而出。

9. 最后

回到标题：AI Agent不够聪明

确实不够聪明，至少没有我们期望的那么聪明。

但这不意味着 Agent 没有价值。就像早期的计算机，虽然功能有限，但在特定场景下已经能创造巨大价值。关键是找到合适的场景，用合适的方式，解决真实的问题。

AI Agent 的发展还处于早期阶段，现在下结论还为时过早。但有一点是确定的：那些能够深入理解客户需求，扎实做好工程实施，持续优化产品体验的公司，最终会在这个市场上站稳脚跟。

至于 AI Agent 什么时候能真正「聪明」起来？我觉得还需要时间。可能是一年，可能是三年，也可能是五年。但在这个过程中，我们需要做的不是等待，而是不断探索、试错、优化，一步步接近那个目标。

毕竟，罗马不是一下子建成的，AI Agent 也不是。

以上。