在多 Agent 系统里，上下文怎么传，决定了系统的稳定性上限、成本下限、以及排障时的血压。

最开始，很多团队把它当成「把聊天记录拼一拼」的问题。上线后就会这样的问题：

• 同样的输入，输出飘得离谱。这里的问题是上下文污染和信息密度不稳定。
• Token 成本控不住。明明一个任务只需要 10 句关键信息，每次都喂 200 句。
• 自动化评测很难做。回归集跑出来波动大到没法设阈值，最后只能靠人工验收。

从工程的角度简单定义一下「上下文传递」：在一条多步协作链路里，把下游完成任务所需的信息，以可控成本、可追踪方式送到它面前。这里面有两个关键词：可控、可追踪。

下面聊下我理解的 4 种主流策略拆解：原理、适用场景、落地细节、坑、性能和效果的取舍。

先定义一下上下文

很多争论的根源是大家说的「上下文」不是一个东西。可以在团队里先把上下文分层，后面所有策略都能对齐。这里我们把「上下文」拆成 4 类：

1. 任务上下文：当前这一步要干什么，验收标准是什么。
2. 状态上下文：链路运行到哪了，已经产生了哪些中间产物。
3. 记忆上下文：用户偏好、历史约束、长期设定，和当前任务不完全同一层级。
4. 证据上下文：引用了哪些原始材料（文档片段、对话原句、文件、数据库记录），用于追溯和评测。

策略 1：共享状态或黑板模式

这套是 LangGraph、CrewAI 这类框架最常见的默认选项。工程上它像一个「全局状态对象」，也像一个「写满便签的白板」。

机制

• 所有 Agent 对同一个 State 读写。
• Agent A 产出结果写入 State 的某个字段。
• Agent B 读取字段，继续处理，再写回。

如果我们不想把大对象放内存，也可以用文件系统或对象存储做「外置状态」，State 里只放路径和元信息。像 Manus 文章中说的「将文件系统作为存储，直接共享文件系统的路径，渐进式披露」，就是这么个逻辑：把大内容放外面，把指针放 State 里。

什么时候用

• 复杂图流转：有回路、有分支、有重试、有人工介入的链路。
• 任务跨度长：要做断点续跑、要保留每一步证据，方便回放和审计。
• 需要可视化排障：一个状态树摆在那，定位问题快很多。

这类场景里，黑板是省心的。我们不用操心「A 怎么把消息发给 B」，大家都围着同一块板子写字。

落地时的坑

坑 1：状态对象会长成「垃圾堆」

共享状态天然会诱导人偷懒：什么都往里塞。结果一周后 State 变成一个混杂体：

• 当前任务指令
• 全量聊天记录
• RAG 检索结果
• 中间产物全文
• 模型输出草稿

后果是下游 Agent 读到的信息密度越来越低，注意力越来越散。我们会直观感受到「同一个 Agent，越跑越不稳定」。

共享状态可以用，前提是要给 State 立规矩。规矩不是写在 Confluence 上那种，是写进代码和评测里那种。

常用的做法是给 State 分区，至少三块：

• 「control」：流程控制字段（步数、路由、重试次数）
• 「artifacts」：产物指针（文件路径、对象存储 key、哈希）
• 「capsules」：给 LLM 的上下文胶囊（后面会讲）

State 里尽量少放大段文本，放「引用」和「摘要」。

坑 2：并发写

多 Agent 并行时很容易出现：

• 两个 Agent 同时更新同一字段，后写覆盖前写。
• 一个 Agent 基于旧 State 做决策，写回时把别人新写入的字段抹掉。

解决思路按分布式系统处理：

• 字段级别乐观锁（版本号 / compare-and-swap）
• append-only 日志字段，避免覆盖（把「更新」变成「追加事件」），Gemini Cli 就是这个逻辑
• 把「写入」限定为少数字段，其他字段只读

坑 3：评测没法做「输入对齐」

共享状态经常带来一个隐性问题：每次运行 State 的非关键字段变化很大，导致没法保证下游 Agent 的输入一致。回归测试时同一条用例，今天多了两段日志，明天多了一个草稿，指标就会飘。

建议：评测时固定「胶囊输入」，State 可以变，但进入 LLM 的那段上下文要可快照、可对比、可复现。

成本 vs 效果的取舍

• 效果：流程可扩展，复杂图最好用。
• 成本：需要治理 State 的 schema、并发、版本、清理策略。
• 性能：状态越大，序列化 / 反序列化越痛；如果每一步都把 State 发给 LLM，更是直接烧钱。

共享状态是一把大锤。能砸钉子，也能把玻璃砸碎。关键看有没有「状态卫生」这件事。

策略 2：消息传递与直接调用

这套有点像微服务架构：上游把消息打包发给下游，下游处理完再回一个结果。

机制

• Agent A 产出一个「消息」发给 Agent B。
• 消息可以走 HTTP、RPC、队列，也可以是框架内的函数调用。
• 每条消息都应该有明确的结构和版本。

什么时候用

• 流水线式任务：每一步都很明确，上游输出就是下游输入。
• 要强可观测性：链路追踪、审计、回放都好做。
• 团队边界清晰：不同组负责不同 Agent，接口契约能拉齐。

这类场景用消息传递灵活性更强一些，但是如果规模不大，直接单体应用来搞，函数间调用吧。

落地时的坑

坑 1：消息里塞进「全量上下文」

很多团队为了省事，会把上游拿到的所有东西都塞进消息里。看起来省了裁剪逻辑，实际上把问题推给了下游：下游 LLM 要在一堆噪声里找信号。

如果走消息传递，消息必须有「字段语义」。比如：

• 「task」字段是当前要做的事
• 「constraints」字段是硬性限制
• 「evidence」字段是引用（原文片段或路径）
• 「history」字段如果存在，必须明确是「最近 N 轮且强相关」

这里的关键词是「必须明确」。否则会出现消息看着结构化，内容依然是散装的。

坑 2：接口版本失控

多 Agent 系统迭代快，接口字段会频繁变动。如果经历过一次「某个 Agent 升级后，下游全挂」就会理解版本的重要性。

建议至少做到：

• 每条消息带「schema_version」
• 下游支持 1~2 个旧版本的兼容解析
• 重要字段改动要有灰度期，别全量切

Agent 世界里「prompt 和策略」变化太快，不做版本控制就是赌博。

坑 3：把「LLM 输出」当成接口返回

LLM 输出天然存在幻觉。如果我们直接把自由文本当成 RPC 返回，然后让下游再去解析，事故率会非常高。

有一个简单的方法：固定栏位的轻量输出格式，别一上来就上复杂 schema，也别放任自由发挥。它在工程上有一个很大的价值：解析稳定，回归测试有抓手。

类似于这样：

PROMPT:
...

NEGATIVE:
...

PARAMS:
- aspect: 16:9
- notes: ...

成本 vs 效果的取舍

• 效果：可追踪性强，调试体验好。
• 成本：要做接口契约、版本管理、兼容逻辑。
• 性能：网络开销和序列化开销可控；真正的成本往往来自传了多少无用字段。

如果业务链路更像「微服务编排」，消息传递会比共享状态更干净。

策略 3：上下文压缩与自然语言传递

核心思路：下游 Agent 不该负责考古。

把「长历史」变成「短胶囊」，把「噪声」变成「任务卡」，再交给执行 Agent。

机制

上游做三件事：

1. 从历史里抽取和当前任务强相关的信息
2. 把冲突的约束做决策或提出澄清问题
3. 输出一个高密度、可控的自然语言指令

「上下文胶囊（context capsule）」

把给下游 Agent 的输入，固定成一个胶囊，结构大概是：

• 必须给：任务卡（Planner 压缩/改写后的自然语言描述）
• 可选给（按需）：

  • 最近 N 轮「与任务强相关」的对话原句（最多 3–8 句）
  • 一段「用户偏好/风格记忆」摘要（1–3 句）
• 坚决不直接给：全量聊天记录（除非做的就是风格延续式创作，而且做了脱敏）

它解决的是「你能不能控制它理解什么」。

示例：

任务卡：生成一张用于电商 banner 的图。主体是一只穿宇航服的柯基站在月球上，远处能看到地球。风格写实摄影，冷色调，高对比，电影感侧逆光。横向 16:9。不要任何文字、logo、血腥或恐怖元素。用户偏好极简、冷色、不要文字。若信息缺失请提 1–3 个澄清问题，否则直接输出可用于生图的 prompt 与 negative prompt。

这段话有几个关键点：

• 主体、场景、风格、画幅、禁忌、用户偏好都在
• 有「缺失信息时的行为规则」
• 不需要表单，依然可评测、可回归

工具描述要写成「契约」

工具描述很重要。

我更喜欢把工具说明写成「契约」，至少包含：

• 工具支持的参数（prompt / negative / size / seed / style 等）
• 哪些信息必须出现（画幅、用途、限制）
• 输出必须遵守的格式（哪怕只有 PROMPT/NEGATIVE/PARAMS）

可能翻车的地方

以一个增强提示词的 Agent 为例

翻车 1：指代延续没被写进任务卡

用户说「按刚才那张风格」「把她换成红裙子」，Planner 如果没有把「刚才那张」总结成可引用的描述，下游增强 Agent 根本无从得知。

补救方式使用「证据上下文」：把关键原句作为 1~3 条引用附在胶囊里。

翻车 2：约束冲突没被处理

用户一会儿要极简纯色，一会儿又要复杂赛博城市场景。Agent 去解决冲突会很糟糕，因为它的职责是「增强表达」，不是「做产品决策」。

冲突要在 Planner 层解决：要么做裁决（按最新指令为准、按用户偏好为准），要么问澄清问题。别把锅甩给执行 Agent。

翻车 3：压缩带来的信息损失

上下文压缩是有损的。 压缩做得越狠，成本越低，翻车概率越高；压缩做得越松，成本越高，稳定性也未必更好，因为噪声会上来。

建议做一个「胶囊长度预算」，按任务类型分档：

• 低风险任务（格式化、简单问答）：胶囊可以短到 200~400 tokens
• 中风险任务（生成、改写、推理）：600~1200 tokens
• 高风险任务（工具调用、多约束、多回合创作）：1200~2000 tokens，再往上就该考虑别的策略了

这样，可以让成本和稳定性可控一些。

成本 vs 效果的取舍

• 效果：稳定性提升非常明显，Token 成本能压下来，评测也更容易做。
• 成本：要多一个 Planner/Summarizer 步骤，链路延迟会上升；压缩质量要靠回归集打磨。
• 工程判断：这套是「多 Agent 真正开始像工程系统」的起点。

策略 4：路由分发与层级管理

如果说策略 3 解决的是「给下游喂什么」，策略 4 解决的是「谁有资格看到什么」。

我喜欢用「最小信息原则」去设计多 Agent：每个 Agent 只拿自己需要的那一部分上下文，别让它看到不该看的东西。

机制

• 一个 Supervisor（主管）拿到全量上下文。
• Supervisor 拆任务、选 Agent、裁剪上下文。
• 子 Agent 只看到被裁剪后的输入，产出结果回传 Supervisor。
• Supervisor 汇总，决定下一步。

把「路由」和「信息裁剪」集中起来做，能显著减少上下游互相污染。

这本质就是一个主从的逻辑。

什么时候用

• 权限和合规敏感：有 PII、有商业机密、有分级数据。
• 子 Agent 职责清晰：比如「检索」「评审」「生成」「合规检查」。
• 系统要长期维护：人员流动、策略变动、模型替换都很频繁。

层级路由把复杂性收敛到 Supervisor 这一点上。依赖它，也更容易把它做好。

落地时的坑

坑 1：Supervisor 变成性能瓶颈

所有东西都过 Supervisor，它会成为热点：吞吐、延迟、可用性全压在它身上。

解决办法通常有三种：

• Supervisor 只做「路由与裁剪」，不要在它身上做重推理
• 对路由做缓存（同一类任务走同一条路径）
• Supervisor 逻辑尽量确定性，LLM 参与度降低

我见过很多团队把「大脑」写成一个超级 prompt，然后让它既拆任务又生成内容又做审查。这样迟早会蹦。

坑 2：裁剪策略一开始过度依赖「拍脑袋」

裁剪不是凭感觉。裁剪是一套数据工程问题：哪些字段必须给，哪些字段给了会干扰。

用「失败用例驱动」去迭代裁剪：每次线上翻车，都回放当时给子 Agent 的胶囊，问一个很残酷的问题：

• 该给的没给，是哪一类信息缺失？
• 不该给的给了，是哪一类噪声触发了跑偏？

把这两类问题沉淀成裁剪规则，会越做越稳。

坑 3：子 Agent 之间产生「隐性耦合」

很多系统表面上是层级的，实际上子 Agent 会通过共享外部资源互相影响，比如：

• 共用同一个向量库检索空间，检索结果被不同策略污染
• 共用同一个临时文件目录，路径命名冲突
• 共用同一个「用户偏好记忆」，写入时缺少版本控制

如果走 Supervisor 模式，「写入边界」会比较重要：哪些 Agent 允许写记忆，哪些只能读；写入要不要审批；写入是否带证据引用。

成本 vs 效果的取舍

• 效果：稳定性和安全性非常强，复杂系统更容易控住。
• 成本：Supervisor 设计难度高，容易成为瓶颈；需要更完善的可观测性和回放能力。
• 工程判断：当开始被「数据泄露」「上下文污染」「责任边界不清」折磨时，Supervisor 往往是解药。

选择策略时，如何判断

可以用四个可执行的问题来选方案：

1. 谁需要看到全量上下文？谁只需要胶囊？
   如果答案是「大多数都只需要胶囊」，策略 3 和 4 优先级会上来。

2. 要不要并发？要不要异步？
   需要并发、异步，策略 5 的价值会非常直接。

3. 失败主要来自哪里：信息缺失，还是噪声过多？
   信息缺失优先补证据引用；噪声过多优先做裁剪和胶囊预算。

4. 是否真的在做回归评测？
   没有回归，就别指望系统会「越调越稳」。上下文传递策略的好坏，最终都要落在可复现输入上。

小结

不做结构化，并不等于不做「约束与契约」。

我见过的高质量落地项目，往往走的是「看起来很自然，实际上约束很硬」的路线。用户体验上像聊天，工程实现上像协议。

如果准备做多 Agent 的上下文传递，至少把三件事落下来：

• 「上下文胶囊」：任务卡 + 少量强相关原句 + 记忆摘要
• 「工具契约」：写清楚工具能力边界和必填信息
• 「受控输出格式」：固定栏位，解析稳定，评测可做

这三件事做完，再谈共享状态、Supervisor、消息传递，才有意义。

以上。

在 AI 编程逛飙的年份，到当前的阶段，能感觉到速度在加快，形式也在不断的迭代，写代码这个事情也变得门槛很低。

X 上有人在讲「AI 让软件开发成本接近零，所以 SaaS 价值也接近零」

美股前段时间也因此大跌了一波，但当前这个价值为零的逻辑还是不成立的。

这里有一个概念混淆：构建软件的成本 vs 拥有软件的成本。AI 主要压低前者，后者还在，甚至在很多公司里变得更贵。

在各种自媒体、AI 编程培训或者博眼球的报道中，「一个下午做出 Linear 替代」「一个周末写完 Stripe 替代」这种话，我不觉得完全是吹牛。用 Claude Code 这类工具，把界面、CRUD、简单流程、甚至一些边角的自动化都拼出来，确实快。

但在做出来的那一刻，资产没增加多少，负债突然多了。尤其是碰钱、碰身份、碰合规、碰客户数据的时候。

以做了一个 Stripe 为例，我把 Vibe Coding 一个周末后，「现在拥有了什么」用更工程的语言翻译一下：

• 拥有了 规则持续变化 的税务与开票适配：欧盟 VAT、各国电子发票、免税/退税、税率变更、发票作废红冲。
• 拥有了 审计与认证的对话成本：PCI DSS、SOC 2、ISO 27001、渗透测试报告、供应商安全评估问卷。企业客户要的往往不是「你写得对不对」，是「谁在对这件事负责」。
• 拥有了 支付与账务的边界条件：拒付、部分退款、重复扣款、汇率、四舍五入、账期、对账差异、资金在途、延迟入账。
• 拥有了 全球化的坑：货币重估、货币小数位变化、地区性监管、某个国家突然要求强制 3DS、某个渠道突然不支持某种卡组织。
• 拥有了 数据与权限的事故半径：某个字段脱敏没做好、某个导出接口忘了做权限校验、某个后台操作没有审计日志。
• 拥有了 7×24 的值班现实：系统降级策略、容量、限流、重试风暴、第三方故障兜底、SLA 与赔付条款。

这些事大概率不是「可能发生」。按行业经验只是早晚问题。自从拥有系统开始，就等于自己签了那张无限期维护合同。

回想一个问题，SaaS 是什么？软件即服务，核心是服务，根本就没有提代码。

很多团队在内部系统上很执着，原因很直接：控制感强、改需求快、看起来省钱。上线半年以后，气氛通常变得不太好：需求排队、线上出过几次事故、业务抱怨响应慢、研发觉得自己在打杂。

这时候再看 SaaS，价值就很清晰了：SaaS 的核心商品是「运营表面积」的转移。

代码只是其中一层，除了代码还有：

• 基础设施与部署：多区域、容灾、备份恢复演练、变更管理。
• 安全：漏洞扫描、依赖升级、密钥轮换、权限最小化、WAF、DDoS。
• 合规：隐私条款、数据驻留、审计证据、流程制度落地。
• 可靠性：监控告警、事故复盘、容量规划、灰度发布、回滚策略。
• 支持与客户成功：工单、排障、培训、文档、FAQ、升级沟通。

当我们把软件「买回来」自己跑，这些都要自己补齐。很多公司低估的就是这一块。这也是为什么很多公司在 AI 赋能后，「运营表面积」的转移速度要慢于「代码」的转移速度。除非这些对公司不重要，如果这些都不重要， 这个系统可能也不重要了。

从 SaaS 的生命周期来看，AI 提升的是「0 到 1」，然而从成本的角度看，最贵的是「1 到 ∞」

这件事可以拆成两条曲线：

• vibe coded 工具：初期成本很低，后期成本增长很快。越多人用、越多数据、越多流程依赖，它的「改动风险」和「维护面」指数上升。
• 成熟 SaaS：初期采购成本看着不低，后期增长更接近线性。因为供应商把大量共性维护摊薄到所有客户身上。

AI 把 0→1 压得更便宜，直觉上会让人误判「买 SaaS 更不划算」。实际情况常常相反：AI 让 1→∞ 更贵了，因为我们会更频繁地改、更大胆地接更多业务进来，系统的负债增长速度被我们自己加速了。

这个成本不仅仅是 SaaS 软件的。

AI 让一个工程师单位时间产出更高，但单位工程小时的机会成本同步上升。

至少当前的认知是这样的，可能到终极形态，完成不用人介入的时候，这个机会成本也会消失掉。

那是另一个话题了。

所以我对「AI 让 SaaS 价值归零」的判断是反的：AI 越强，成熟 SaaS 越值钱，前提是它真的把服务做扎实，真的帮我们把运营表面积吃掉。

SaaS 本质上还是一种服务。

如果 SaaS 只是「界面更好看的 CRUD」，那这样的 SaaS 确实会死掉一批。

这些 SaaS 太薄了。

在 AI 时代要想活得更好，SaaS 通常需要如下的一些特征：

• 规则密度高，正确性要求高
• 合规与安全负担重
• 生态变化快，需要持续跟进
• 故障代价高，客户不想背锅
• 接口与集成复杂，长期维护吃人

Stripe、WorkOS、Cloudflare 这类产品的共同点很明显：它们难点不在「写出来」，难点在「长期把它跑对」。正确性要靠无数细碎决策堆出来，运营水位要常年拉满。

AI 始终会改写 SaaS，整体逻辑会有一些变化。这里的 AI 改写过程，肯定不是「加一个聊天框」「做一个总结」「做一个生成报表」。

我觉得至少有三个点在当前阶段能快速跟进：

1. 意图驱动，SaaS 的用户最终都是想通过 SaaS 完成工作，以前靠 UI 引导的，现在可以让用户意图表达，然后把意图落为可审计的操作序列，不管是用 MCP，还是 SKILLS；
2. 更关注结果，传统 SaaS 交付的是工具，客户负责把工具嵌进流程。AI 让厂商有机会把流程吃进去，直接交付结果，比如「自动完成对账」「自动完成入职」「自动完成工单分流」。关键点在「责任」
3. 定制方式的迭代，企业客户永远会提定制。以前定制意味着项目制和人力黑洞；AI 让「生成」变得便宜，但不要把生成等同于可维护，可以允许客户用自然语言提出规则，系统把规则编译成可测试、可审计的约束，每次变更都能跑回归校验，出问题能定位到规则版本与变更人。

我们常听到对于自研和购买 SaaS 的一个判断逻辑是：「核心业务自研，非核心买 SaaS」。

这句话太粗，没有啥指导意义。

如下一个判断清单，可以做为决策的一些依据：

适合买 SaaS 的场景 ：

• 领域合规重：支付、税务、身份、隐私、审计
• 失败代价高：一出错就上新闻、上法务、上客户群
• 生态变化快：标准常变、监管常变、攻击手法常变
• 需要对外背书：企业客户会问「谁负责」「有没有认证」「有没有 SLA」

这种场景自研的隐性成本巨大。AI 再强，也只是让我们更快地把「维护合同」签在自己身上。

适合自研的场景

• 强差异化：流程就是你的竞争力，外部产品很难贴合
• 业务规则变化快，且只对内部负责：错了能快速纠正，不会引发合规事故
• 生命周期短：一个季度就会重构或下线的东西
• 数据高度敏感，且已经有成熟的数据治理与安全团队

这里自研的价值很实在：迭代速度、贴合度、数据控制。

AI 时代的「自研陷阱」会更隐蔽

以前自研失败，多数死在「做不出来」。现在会死在「做出来以后一路堆债」。

AI 会在早期持续正反馈：

• 功能做得快
• Demo 好看
• 业务觉得爽
• 老板觉得省钱

债务也在同期累积：

• 没有威胁建模
• 没有权限与审计体系
• 没有数据分级与脱敏
• 没有灾备演练
• 没有 SLA 与值班机制
• 没有供应链安全策略（依赖库、镜像、密钥）

等到系统进入关键路径，会发现自己已经没有退路。再想补课，代价是「停业务」或者「带病重构」。

这也是我反复强调「拥有软件是负债」的原因。负债不会因为 AI 变聪明就消失，它只会增长得更快。

AI 把「做一个能用的软件」变成了常态，把「把软件长期跑对」推成了门槛。薄 SaaS 会被挤压，真正提供服务、背负责任、把运营表面积吃掉的 SaaS，会更值钱。

以上。

最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。

在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例：

团队有个复杂遗留系统，典型「多线程 + 历史包袱 + 不敢动」组合。模型先给了一个方案：加锁、等待、条件变量、再加一层保护，几百行代码，逻辑像一团湿毛线。能跑，理论上也对，但你让我把这玩意儿上线？我不敢。

我让它「再想想，能不能避免这些锁和等待」。它又跑了很久，最后给了一个极简方案：之前那些锁啊等待啊都删了，思路干净到让我怀疑它刚才在干嘛。

那一刻我脑子里冒出来的不是「AI 真强」，而是一个更别扭的问题：

我到底起了什么价值？

背景上下文？它从代码库里能 infer 掉绝大多数。设计约束？很多也能从调用关系、线程模型、运行时指标推出来。所谓「design taste」？我甚至可以写成 Markdown 规则让它照做。

过去资深开发的硬价值之一是 reasoning 的过程：拆问题、找不变量、选折中、落地细节。现在模型也能做，还能做得很快。

我绕了一圈，最后落在一个很不体面的结论上：人的价值被压缩到极小概率的「否决权」里。

99% 的时候，我是在给 AI 的解「盖萝卜章」：嗯，看起来没错。
剩下那 1% 的时候，我得站出来说：不行，这条路走不通，换解空间里的另一个点。

这个角色像保险。你买的时候就知道大概率用不上，但真出事的时候要能扛住。更像现在的 L2-L4 自动驾驶：人坐在方向盘前，99.9% 的时间无事可做，为了那 0.1% 的「可能发生也可能不发生」。

问题来了：这 1% 会不会也被另一个 agent 替掉？再给一个「专职 reviewer」去 challenge 写代码的 agent，让它把那 1% 找出来。

那人还剩什么？

以及这会把程序员的岗位推向哪里。

很多讨论卡在「AI 写代码快，所以程序员要失业」这种口号里。工程上更真实的变化是两条曲线的剪刀差：

• 代码生成成本下降得很快：写一段能跑的实现、补齐样板、迁移接口、写单元测试骨架，这些都接近「文本补全」。
• 承担后果的成本上升：上线事故、性能回退、并发死锁、数据一致性破坏、合规风险、供应链安全。AI 让改动频率变高，系统的「变更面」变大，出事概率跟着涨。

我现在看 AI 产出的 patch，经常有一种荒诞感：
改动本身很漂亮，解释也很漂亮，真正要命的点藏在「系统级不变量」里，而那部分恰好最难被 prompt 描述清楚，也最难被静态检查覆盖。

所以讨论「程序员价值」别从「写代码」切入，从「为系统负责」切入。写代码只是责任链条里最便宜的一环。

聊回到前面大佬分享的案例。

为什么模型会先给「复杂加锁方案」，再给「极简方案」

这不是模型「变聪明了」，更像搜索策略切换。

我自己复盘过很多次类似现象，模型第一次给复杂方案，常见原因有几类：

• 目标函数不清：模型默认把「不出错」权重大幅拉高，并发问题里，模型的默认倾向是「保守」：能锁就锁，能等就等。因为它无法确认你的系统允不允许重构线程模型，也不知道你能承受多少延迟和吞吐损失。一句「能不能避免」其实是在改目标函数：把「简单性」和「可维护性」的权重抬起来，把「局部可证明正确」的偏好压下去。

• 它没拿到关键不变量：并发优化的核心不是技巧，是不变量。例如：哪些数据必须线性一致，哪些允许最终一致；哪些操作必须串行化，哪些可以交换；线程间共享状态的「所有权」到底属于谁；是否存在天然的「单 writer」路径。模型第一次通常拿不到这些，它会用锁把未知包起来。你追问一次，相当于逼它去反推不变量，或者提出重构以创造不变量。

• 在「局部最优」里打转：遗留系统经常有局部约束：你动不了某个模块，改不了调用方，不能引入新队列，不能改变线程亲和性。

人的价值最终会被压到 1%

这事已经发生了。

如果把「写实现」交给模型，人还剩什么？

我现在更愿意把角色拆成四层，分别看哪些会被自动化吃掉：

1. 执行层：写 CRUD、搬接口、补样板、按规范改文件结构
   这层基本被吃穿。
2. 局部推理层：读一段代码、定位 bug、做局部重构
   这层大幅被压缩，速度优势在模型。
3. 系统推理层：跨模块不变量、性能上界、故障模式、发布策略、回滚路径
   这层短期很难完全自动化，原因是信息不完备且目标冲突。
4. 责任层：线上事故谁背、合规谁签、业务损失谁扛
   这层本质是组织结构问题，不是智能问题。

很多资深工程师过去主要靠第 2 层吃饭：你会拆、会想、会写出「更优雅」的实现。现在模型把这层的边际价值压得很薄，于是人的价值看起来就剩「在模型犯错时否决」。

这就引出一个很工程的问题：能不能用另一个 agent 把「否决」也自动化？

答案是：能覆盖很大一部分，但永远留洞。洞的大小取决于你怎么搭系统。

那 1% 到底是什么：哪些场景必须有人类 override

我现在把「必须 override」的场景分成几类，每一类都对应一套工程信号。我们可以用这些信号去训练 reviewer agent，也可以用来提醒自己别当「只会点 approve 的人」。

• 需求语义存在空洞，代码再正确也没意义：常见现象： PR 描述是「修复偶现 bug」，但没有可复现条件，没有失败判据；业务方说「按之前逻辑」，但「之前逻辑」存在灰度分支、历史例外。这类问题 AI 很难凭空补齐。它会把空洞当成「默认值」，然后写出一份自洽的实现。你看起来也挑不出毛病，直到线上行为偏了。override 的动作往往不是改代码，而是卡住合并，逼需求补齐验收条件和反例。
• 系统级不变量被破坏，局部看不出，全局会炸：典型不变量：

  • 计费、库存、资金流的幂等与去重
  • 订单状态机的单向性
  • 写路径单 writer，读路径可并发
  • 缓存一致性策略：写穿、失效、双写窗口
  • SLA 约束下的超时与重试预算

模型能理解这些词，但它很难知道「你们公司真实的不变量是什么」。很多不变量写在事故复盘里，写在某个老同事的脑子里，写在那段「不要动」的注释里。

override 的动作通常是把不变量显式化：写进 ADR（架构决策记录）、写进测试、写进发布 checklist。写完再让模型改。

• 代价函数冲突：延迟、吞吐、成本、可维护性互相打架这些对尾延迟很要命。你让它「简单化」以后，它可能会走向另一个极端：过度重构，侵入面太大，风险高得离谱。这类冲突靠 prompt 很难一次调对，得靠基准测试 + 真实流量回放。人类 override 的价值在于：你知道线上哪条曲线最敏感，知道预算是多少，知道哪里可以牺牲。

• 生产环境的「脏现实」：测试覆盖不到 包括但不限于：

• 时钟漂移、时区、闰秒
• 依赖服务的抖动、限流、半开连接
• 数据脏写、历史脏数据格式
• 热点 key、倾斜分片、长尾用户行为
• 灰度期间的双版本共存

AI 可以写出很干净的逻辑，干净得像从未上过线。

人类 override 的价值在于：你知道哪些脏东西真实存在，知道一旦触发会损失多少钱。

• 安全与合规：模型会「帮你越线」

安全问题里最阴的是「看起来像优化」：

• 为了排查问题把敏感字段打进日志
• 为了方便把权限校验挪到上层，结果漏掉某些调用路径
• 为了提高命中率调整缓存 key，结果造成跨租户数据串读

这类问题 reviewer agent 能抓一部分，靠规则匹配和数据流分析。但组织里真正要命的合规约束往往来自外部：合同、监管、审计口径。模型很难内建你们的合同条款。

只留了 1%，那么大公司删人游戏才刚开始，接下来组织会怎么变？有前司裁员了一半。

AI 带来了两件具体的事：

• 单位时间的变更量上升
• 对稳定性与合规的要求不会下降

组织会自然把资源往两端挤压：

• 一端是「产出变更」的能力：更少的人能产出更多 patch
• 另一端是「控制风险」的能力：测试、发布、SRE、安全、平台工程会更吃香

中间那层「靠手写实现体现资深」的位置，会被挤得很难受。我们会看到更多岗位变成：

• 平台/工具链负责人
• 质量与发布工程负责人
• 架构与技术治理（不变量、规范、依赖治理）
• 领域负责人（把业务语义写成可执行的约束）

如果还把价值押在「我写得快、我写得优雅」，会被模型直接碾过去。

那我们该何去何从？

我更建议把自己训练成「系统负责人」，别训练成「提示词手艺人」

很多人看到 AI 就去卷 prompt。prompt 当然有用，但它属于「表达能力」，不属于「护城河」。

我更建议把成长路线拆成三条，按你自己的背景选一条主线，另外两条补短板。

路线 A：系统与可靠性（适合后端、架构、TL） 要能回答这些问题：

• 这个系统的核心不变量是什么？写在哪里？谁维护？
• 出了事故，最可能的故障模式是哪几类？怎么提前打点？
• 一次改动上线，回滚点在哪里？数据怎么保证不被写坏？

这条路线的硬技能是：可观测性、故障注入、容量规划、发布治理、数据一致性策略。
AI 会让这条路线更值钱，因为改动变多，风险更高。

路线 B：平台与工具链（适合喜欢搞基建的人） 把「盖章」自动化掉。

要能把下面这些做成产品：

• 代码生成与改动的规范化输入（任务模板、约束模板）
• 自动化评审（多 agent + 规则 + 静态分析 + 安全扫描）
• 针对你们域的测试体系（尤其是并发、回归、流量回放）
• 一键灰度、一键回滚、发布可视化

这条路线的本质是：把工程经验固化成流水线能力。模型越强，平台越重要。

路线 C：领域语义与业务工程（适合对业务理解深的人） AI 最弱的地方之一是「公司特有的业务语义」。能把语义变成约束，价值就会变硬。

要能做的是：

• 把业务规则写成状态机与不变量
• 把验收条件变成测试与监控
• 把历史例外收敛掉，减少「口口相传」

这条路线听上去不像「技术」，但在 AI 时代，它会决定你是不是不可替代的那批人。

我不押「永远需要人」这种安全说法。我更愿意给一个工程化的判断：

• 在约束清晰、环境封闭、回滚容易的系统里，人类接管的概率会持续下降。很多内部工具、数据管道、非核心链路会率先做到「几乎无人值守」。
• 在约束隐含、环境开放、后果昂贵的系统里，1% 会长期存在。典型是资金、合规、核心交易链路、跨组织协作系统。这里的问题从来不只是智能，还包括责任与审计。

更关键的一点：就算模型能覆盖 99.99%，组织也未必允许完全无人。原因很现实：责任链条需要一个签字的人。

我写到这里，还是没法给一个让人舒服的答案。AI 把很多我们曾经引以为傲的能力变成了廉价品，这是事实。难受也正常。

但工程世界一向认结果。模型写得再快，只要系统一炸，组织就会把注意力拉回到「谁能把它跑住」。把自己训练成能跑住系统的人，价值就不会跟着 token 价格一起下跌。

以上。

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

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 在长期任务中更一致、更便宜、更可靠。

以上。

做 RAG 经常会效果不行，就算是把模型换了更大的，回答依然飘；把向量库换了更贵的，召回还是不稳；把 Prompt 改了很多版，效果依然起起落落。

RAG 的瓶颈大多不在「生成」，而在「检索」。检索做不好，生成只能在不完整的输入上硬编；检索做得稳定，模型反而没那么挑。

今天我们聊讲 5 个在工程中里最常用、ROI 比较高的策略：

1. 多向量检索
2. 人工切分打标
3. 标量增强
4. 上下文增强
5. 增加多类型向量

0. 优化什么

RAG 的检索链路，拆开看就两件事：

• 召回：把“可能相关”的材料尽量找全
• 排序：把“真正相关”的材料尽量排前

这两件事对应的常见失败模式也很固定：

• 同义相似但不相关：语义像，但不是答案需要的证据
• 关键词命中但语义不近：专有名词、编号、表格字段，向量不敏感
• 被切碎：答案跨段、跨页，chunk 切断了前后依赖
• 证据形态不对：表格、图片、公式、目录结构，直接 embed 很容易失真
• 同一问题在不同时间答案不同：版本、日期、渠道不清，检索到旧材料

下面的 5 个策略，分别解决这些问题中的一个或多个。

1. 多向量检索

给同一份内容提供多种“检索入口”

1.1 核心思路

多向量检索的关键点不是「存更多向量」这么简单，而是把用于检索的表示和用于回答的原文解耦：

• 检索阶段：用更适合相似度搜索的表示去匹配（比如摘要、问题式描述、表格的自然语言总结、图片的文字说明）
• 生成阶段：把原始内容（全文、原表格、原图片引用）交给模型做答案合成，避免摘要丢细节

这种逻辑可以用把 RAG 从「只适合纯文本」扩展到表格、图片等半结构化/多模态内容：
用总结去检索，用原始材料去回答（尤其表格场景很典型：总结容易被召回，但回答必须看原表格字段和数值）。 这种

1.2 什么时候最值

多向量检索在三类数据上收益很稳定：

• 半结构化文档：表格 + 段落混在一起（财报、年报、审计报告、制度文件）
• 多模态文档：图片、图表、扫描件（说明书、投标文件、报告 PDF）
• 长文档：同一个主题分散在多个章节，单一 chunk embedding 容易错过

1.3 工程落地

落地要解决三件事：

1. 拆分元素类型：把文档切成“文本块 / 表格 / 图片”等元素
   用 Unstructured 这类工具做 partition：先抽取图片块，再用布局模型拿到表格边界、标题候选，再把标题下面的文本聚合成块。

2. 为每类元素生成可检索的文本表示

   • 文本块：可以生成更短的摘要、关键词式描述、可能的问题集合
   • 表格：生成“表格讲了什么”的自然语言摘要（用来检索）
   • 图片：常见的是「先用多模态模型把图片转成文字摘要，再当文本检索」
3. docstore 里保留原件
   检索命中的是 summary，但最后喂给 LLM 的是原文/原表格/原图引用。

1.3 常见坑

• 摘要写得太像原文：检索没变强，只是多存了一份噪声
  摘要应该更「检索友好」：更短、更结构化、包含实体名、指标名、时间范围。
• 一个元素生成太多向量：向量数暴涨，召回变慢、成本变高
  做到「足够覆盖检索入口」即可，别追求花样。
• docstore 的映射不稳定：summary 与原件的 id 对不上，线上会出现“召回到 A，返回了 B”的事故
  id 设计要从第一天就稳定，元素级别的主键要可复现。

2. 人工切分打标

用最便宜的方式把「结构」和「业务语义」补回来

2.1 为什么需要人工介入

很多团队一开始会追求「全自动 ingest」，但现实是：

• 同一套自动切分规则，放到不同类型文档上效果差异很大
• 文档里真正有用的结构信息，往往不在文本里，而在排版、目录、章节层级、表格布局里
• 业务里最关键的“可用性信息”（版本、适用范围、地区、产品线、口径）不一定在正文可直接抽出来

人工切分打标解决的是：把检索需要的结构和语义先做扎实，后面的向量、排序、重写才有发挥空间。

2.2 切分的三个规则

1. 按语义边界切，不按长度切
   章节、小节、条款、定义、流程步骤、FAQ 一问一答，是天然边界。
   “为了 token 均匀”硬切，很容易切断定义与约束条件。

2. 切分粒度为「可引用证据」服务
   能够被引用、被追溯、被定位的最小单元更重要：

   • 条款编号
   • 表格标题 + 表格整体
   • 小节标题 + 小节正文
   • 定义段落（不要拆）
3. 保留层级关系
   只存平铺 chunks，后面很难做「向上取整段/向下补上下文」。
   最少保留：文档 → 章节 → 小节 → 段落/表格。

2.3 优先打「可过滤、可路由」的标签

别一上来就做很细的本体论，先打最值钱的：

• 文档类型：制度 / 产品手册 / 合同模板 / 会议纪要 / 财报
• 业务范围：地区 / 产品线 / 客户类型 / 适用系统
• 时效性：生效日期 / 版本号 / 是否废止
• 可靠性：来源系统 / 审批状态 / 是否正式发布
• 访问控制：部门、角色、密级

这些标签后面都能进入“标量增强”和“路由策略”，直接影响线上稳定性。

2.4 常见坑

• 打标体系不收敛：每个人一套标签名
  解决办法很朴素：拉一张白名单表，允许的 key 固定，value 做枚举或正则。
• 把「主题」当标签：主题不稳定，且和 embedding 重叠
  标签更适合放「硬约束条件」和「业务边界」。

3. 标量增强

让检索从「相似」走向「可控」

这里的「标量」指的是：时间、版本、来源权重、权限、质量分、业务线等可以过滤或打分的字段。它们不靠向量表达，靠规则或数值逻辑表达。

3.1 标量增强解决什么问题

• 同一问题，不同时间答案不同：检索到旧版本会直接翻车
• 同一概念，不同地区/产品线口径不同：向量相似度分不出来
• 噪声文档混进知识库：相似度很高但质量很差
• 需要可解释、可审计：为什么给出这条证据，要说得清

把这些交给向量相似度，基本靠运气；交给标量逻辑，结果更可控。

3.2 两种最常用的做法

做法 A：先过滤，再向量检索
先用 metadata 把候选集缩小到“可能正确的范围”，再做语义召回。
典型过滤条件：

• 生效日期 <= 查询时间
• 版本号 = 当前版本
• 适用产品线包含用户所属产品线
• 权限满足访问控制

做法 B：向量召回后，用标量重打分
向量给你 TopK，标量给「业务优先级」：

• 新版文档加分，旧版扣分
• 官方来源加分，草稿扣分
• 被引用次数高/被人工验真过的内容加分

最后把两类分数合成一个总分再排序。

3.3 标量增强的关键点

• 标量字段要可维护：自动抽取优先，其次半自动，再其次人工
• 默认值要保守：缺字段宁可不加分，也别乱加分
• 线上要留日志：每个命中结果，把过滤条件、加分项写清楚，排障会省很多时间

4. 上下文增强

补回 chunk 被切断的前后依赖

上下文增强不是「塞更多文本」，它指的是：让每个可检索单元在被 embed 或被召回时，带上必要背景，避免「孤句误读」。

4.1 你会在哪些场景明显感到缺上下文

• 规章制度里一条规定引用了前面的定义
• 财报里一个指标只在章节开头定义一次，后面全是缩写
• 表格字段含义在表格上方说明里
• 会议纪要里“同意/不同意”要回看讨论对象是谁

这些内容即便向量召回命中了，模型也很容易误解，因为证据不自洽。

4.2 上下文增强常用的三种实现

实现 1：Embedding 前拼接轻量上下文
把 chunk 的标题路径、章节名、文档名等拼到 chunk 前面，再去做 embedding。
目标是让向量表达里包含“这句话属于哪里”。

实现 2：Parent / Window 思路（召回后扩窗）
先召回一个小块，然后按层级关系取它的父节点（小节/章节）或前后窗口。
这样不会让向量库里每个 chunk 变得巨大，但模型看到的上下文更完整。

实现 3：结构化索引 / 树检索（长文档很常用）
这类方法直接承认“文档是有层级结构的”，检索时先在结构上定位，再下钻到具体段落。

以 PageIndex 为例：它会生成类似「目录」的树结构，然后用 LLM 在树上做推理式检索，强调 No Vector DB、No Chunking、Human-like Retrieval，并且给出可追溯的页码/章节引用。

4.3 常见坑

• 上下文拼太多：embedding 变“平均化”，相似度反而变差
  只拼最有区分度的：标题路径、定义短句、字段解释。
• 扩窗没有边界：一扩就把整章塞给模型，成本和噪声都上来
  扩窗要有上限，优先拿“同小节”而不是“同文档”。

5. 稠密/稀疏两种向量一起用

使用 BM25 集成，把「关键词命中能力」补回来

稠密/稀疏向量是什么。

• 稠密向量检索（Dense / Embedding）：
  适合语义相近的表达，用户措辞变化大也能匹配到。
• 稀疏检索（Sparse / BM25）：
  适合精确词匹配，尤其是专有名词、编号、字段名、错误码、产品型号、合同条款号。

工程上最常见的现象是：
用户问了一个带编号/字段名的问题，向量检索给你一堆语义很像的段落，但就是没有那个编号对应的条款；BM25 往往一搜就中。

BM25 能给我们带来：

• 召回包含关键字的证据，避免向量漏召
• 对“必须精确命中”的问题更稳（例如政策条款号、表格字段、系统接口名）
• 对混合语料更友好（中英混排、代码片段、缩写、符号）

5.1 集成方式

工程里常用两种

方式 A：并行召回 + 合并去重 + 重排

• BM25 TopK 一份
• 向量 TopK 一份
• 合并成候选集，去重
• 用统一的 rerank（或简单规则）排出最终 TopN

这个方式的优点是直观，问题也直观：候选集会变大，要控制 K 和 rerank 成本。

国内阿里云的向量数据库有多维向量的逻辑，可指定权重召回。

方式 B：BM25 做第一阶段召回，向量做第二阶段精排（两段式）
适合语料特别大、向量检索成本高的场景。BM25 先把范围缩小，再在小集合里做语义相似度和重排。

5.2 常见坑

• 把 BM25 当主力：BM25 对同义改写不敏感，用户表达一变就丢召回
• 权重拍脑袋：BM25 和向量的分数尺度不同，直接线性加权经常不稳定
  更稳的做法通常是：先归一化，再做合并；或者交给 rerank 做最终裁决。
• 分词质量不过关：中文 BM25 的效果强依赖分词/词典
  词典里把产品名、缩写、字段名补齐，收益很实在。

6. 小结

以上的策略也不是一定要一起上，可以按阶段实施：

1. 人工切分打标：先把结构、版本、权限、范围做干净
2. BM25 集成：把关键字硬命中能力补齐，减少离谱失败
3. 上下文增强：解决「切碎」和「孤句误读」
4. 标量增强：把线上结果变得可控、可解释、可审计
5. 多向量检索：针对表格/图片/长文档，把跨形态检索打通

这 5 个策略并不冲突，实际生产系统基本是叠加使用：
BM25 兜底精确命中，向量负责语义召回，标量负责边界条件，上下文负责可读证据，多向量负责多形态内容。

在这些策略的基础上，我们可以使用如下的一些评估方式来判断是否优化有效：

• 召回层指标：TopK 是否包含正确证据（有无命中）
• 排序层指标：正确证据在 TopK 的位置分布（越靠前越好）
• 答案层指标：带引用的正确率、引用的可追溯性（页码/条款号/表格位置）
• 线上指标：无答案率、澄清率、人工升级率、重复追问率

尤其建议把「无答案率」和「引用可追溯性」拉出来单独看，它们最能反映检索链路是否健康。

以上。

去年 Vibe Coding 突飞猛进，AI 编程已经逐渐普及。 很多团队对于写代码这件事的定义开始有一些变化。变化在于产出代码的方式：越来越多的代码来自模型，程序员更多时间花在和模型聊天，把问题说清楚、把边界卡住、把结果验明正身。

我愿意称之为「程序指导员」。写代码仍然在发生，但我们的动作从「逐行敲」转到「聊天与校验」。

1. 程序指导员在做什么

把一段需求交给 AI，得到一段能跑的代码，然后多聊几句，一个功能就完成了。但是这个功能是不是可维护、可上线、可回滚、可观测、可审计，就不太确定了。

程序指导员的核心工作通常包括这几件事：

1. 把需求翻译成可执行的任务
   需求里混着业务语言、边界条件、历史包袱、隐含约束。模型的信息中这些可能是缺失的。我们要先做一次结构化翻译：输入是什么、输出是什么、失败怎么处理、性能底线是什么、兼容范围是什么。

2. 把任务拆成模型能稳定完成的块
   一次性让模型写完一个完整功能，也可以，让 CC 多跑一段时间，但成功率不稳定。更稳的方式是拆成小块：数据结构、接口定义、核心逻辑、错误处理、测试、文档、迁移脚本，各自生成、各自验证，然后再组装。这种方式让我们更有掌控力，知道发生了什么，过程可控。

3. 给足约束，减少「自由发挥」空间
   约束要可检验：必须用现有依赖、必须兼容某版本、必须遵守公司日志规范、必须不新增公网访问、必须在某条 SLA 内、必须覆盖某些用例。

4. 验收与兜底
   模型会给出看起来合理的实现，也会在边界上“编”。程序指导员要像做 code review + 测试负责人那样工作：读关键代码、跑测试、补测试、压测、看日志、看回归风险、看安全风险。最后要能回答一句话：这段代码出问题，谁来修、怎么定位、怎么回滚。

这套工作方式和当前的 CC 一把梭相比，并不先进，甚至有些落后。

和以前相比，以前也有模板代码、脚手架、复制粘贴、搜索引擎。不同点在于：AI 把「生成」能力推到台前，生成速度极快，错误也更隐蔽，导致「指导与验证」的权重被迫上升。

2. 变了什么

2.1 输入从「代码」变成「任务说明书」

以前的输入主要是我们写的代码和我们改的代码。现在多了一种主要输入：我们写给模型的任务说明书。

这份说明书的质量，直接决定产出质量。写得好，模型像一个执行力强的中级工程师；写得差，模型像一个自信的实习生。

说明书里最重要的内容通常包括：

• 目标：要解决什么问题，做到什么程度算完成
• 环境：语言版本、框架版本、已有目录结构、现有依赖、运行方式（一般在规则上下文中给出）
• 接口：入参、出参、错误码、异常策略、幂等、重试、超时
• 约束：性能、资源、兼容、安全、合规、日志、监控
• 验收：必须通过哪些测试，用哪些样例验证，输出应满足哪些断言

把这些写清楚，能把 80% 的返工挡在模型生成之前。

2.2 工作节奏从「连续编码」变成「短回路迭代」

传统编码经常是长回路：写一段、跑一遍、再改。AI 编程的高效来自短回路：AI 生成完成，自动编译构建，自行测试，然后马上验收，发现偏差、立刻补约束再生成。

短回路的关键在于每一轮都要带着明确的失败信息回去：哪条测试挂了、哪个接口不对、哪个边界漏了、哪个依赖版本冲突。模型对这种「可定位的反馈」反应更稳定。

2.3 代码量不再是效率指标

代码生成变快之后，代码量会失真。以前一个人一天写 500 行算多，现在模型十秒能吐 500 行，一天几千行可用的代码随随便便。

更有意义的度量指标会转向：

• 需求到可用版本的周期
• 线上缺陷率与回滚率
• 变更影响范围（改动越小越好）
• 可维护性（复杂度、重复度、依赖扩散）
• 测试覆盖与回归效率

如果团队还用「写了多少行」「提了多少 PR」来衡量，会很快走偏：大家都能刷产出，系统质量却下降。

2.4 「看懂代码」变得更重要

模型写的代码往往「像那么回事」，也可能更长、更绕、更喜欢堆抽象。程序指导员必须能快速识别几类问题：

• 关键路径上不必要的复杂度
• 隐性性能问题（多余的拷贝、无界缓存、低效循环）
• 错误处理缺失（吞异常、错误码混乱、重试风暴）
• 并发与资源泄漏（锁、连接、文件句柄）
• 安全问题（注入、越权、敏感信息日志、依赖风险）
• 与现有系统契约不一致（字段含义、时序、幂等等）

以前也需要这些能力，但当代码产出速度暴涨时，「看懂与筛掉问题」的能力会直接决定我们能不能把速度兑现成质量。

3. 没变什么

变化再大，有些东西一直没变，而且变得更值钱。

3.1 对业务的理解仍然是门槛

模型可以补全语法、补齐样板、生成测试，但它很难替我们承担「业务正确性」。尤其在边界条件、例外流程、历史债务、灰度策略上，错误经常不是编译错误，而是业务事故。

谁最懂业务，谁最知道「哪些地方不能动」「哪些数据不能算错」「哪些流程不能重试」，谁就更能驾驭 AI 编程。

换一个大家更常用的词语，就是领域知识要在线，否则错了你也不知道错了。

3.2 系统设计能力仍然决定上限

模型擅长在给定结构里填充实现，不擅长从零做合理设计。系统边界怎么划、数据怎么流、接口怎么稳、状态怎么管理、失败怎么收敛、观测怎么做，这些决定了系统能不能长久演进。

如果把“设计”也交出去，模型会给一个看似完整的方案，但常见问题是：

• 组件拆得漂亮，运行链路混乱
• 过度抽象，改一处牵一片
• 忽略现有基建与规范
• 缺少可观测与运维视角

当然，这些问题都可以通过提示词来解决，不过对于系统设计的认知还是需要我们来把握，至少我们得知道什么是好什么是坏。

系统设计这件事，仍然需要人来负责，并且要更早介入。

3.3 责任边界没有变化

代码是模型生成的，并不改变责任归属。线上出了事故，审计追责、复盘改进、长期治理，仍然落在团队身上。

在群里看到一个消息，最近有一个团队 AI 生成的导致线上数据全部被覆盖，团队绩效今年基本和他们没有关系了。

所以「让模型写」不是免责理由，反而要求流程更严：评审、测试、灰度、回滚、监控、告警、应急预案，一个都不能少。

4. 程序指导员需要哪些基础认知

4.1 对模型能力边界的认知

模型的强项：

• 快速生成代码、接口定义、CRUD、数据转换
• 根据已有代码风格补齐实现
• 生成测试用例框架、mock、基础断言
• 把自然语言需求翻译成「看起来像」工程方案

模型的弱项：

• 对真实业务语义的可靠理解（尤其隐含规则，，因为其没有上下文，甚至有些隐含规则我们自己也没有意识到）
• 对运行时约束的自发遵守（性能、资源、稳定性）
• 对项目历史约定、隐性依赖的自动继承
• 对安全与合规的默认正确
• 对「细微但关键」的一致性（字段含义、状态机、时序）

程序指导员要把弱项当成默认风险。

4.2 任务拆解能力

拆解不是把大需求拆成很多小需求就结束了，而是拆成“可验证”的单元。

可验证的含义是：
每一块都能用编译、单测、静态检查、契约测试、跑一段 demo 来确认对不对。

拆解时常见的顺序：

1. 先定接口与数据结构（契约优先）
2. 再做核心逻辑（关键路径先跑通）
3. 补错误处理与边界（把失败收敛）
4. 加测试与观测（让后续修改可控）
5. 最后做重构与清理（收敛复杂度）

这个顺序能减少返工，也更适合把生成结果分段纳入工程体系。

4.3 约束表达能力

约束要写成「可执行」的规则。

常见可执行约束：

• 依赖：禁止新增依赖；必须使用项目已有库
• 版本：必须兼容某版本运行环境
• 性能：某接口在某数据量下耗时上限
• 幂等：重复请求的处理方式
• 日志：必须打哪些字段；禁止打印哪些字段
• 错误：错误码范围；异常抛出策略；重试策略
• 兼容：老接口字段不可删；新增字段默认值策略
• 安全：输入校验、权限校验、敏感信息处理

当我们把这些写清楚，模型就可以更规范的交付了。

4.4 验证习惯与测试能力

验证还是要靠工程化手段。

最低配置的验证链路：

• 静态检查：lint、类型检查、依赖扫描
• 单元测试：关键逻辑与边界条件必须有断言
• 集成测试：接口契约与关键链路
• 回归策略：哪些模块必须跑全量，哪些可抽样
• 观测：日志、指标、链路追踪的基本补齐
• 灰度与回滚：发布策略与开关方案

把这些链路搭好，AI 才能变成稳定的生产力工具。否则它更像一个加速出错的发动机。

5. 小结

程序员变成程序指导员，不是职位变了，是工作重心变了：写代码的时间变少，把问题讲清楚、把系统守住、把风险挡住的时间变多。

最近阿里出来的 P10 毕玄，在其创办的公司贝联珠贯中宣布不再按传统的专业分工，所有的人都叫 Agent 全栈工程师。

我想象中的团队也是这样，通过合并工种，减少沟通，让 AI 发挥出更大的价值。

在做这些之前，我们需要问一下自己三个问题：

• 我们的验收标准有没有变得更清晰
• 我们的测试与观测有没有跟上生成速度
• 我们有没有把隐含知识变成显性规则

答案越清楚，AI 带来的就越接近真实效率。否则只是把编码速度提上去，把返工和事故也一起提上去。

以上。

当 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. 最后

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

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

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

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

以上。

老家。

酒后！

去年的所有文章有 90% 以上的内容都是 AI 写的。这篇总结就不用 AI 了。

为什么用选择这个主题呢，原因很简单，因为刷视频的时候刷到了刘震云老师的一段话：

不要后悔你曾经的所有决定，哪怕做错了，你都不要后悔，因为在当时那个条件下，你的认知就决定了，你只能做出那个选择。
你人生所有的决定都是为你自己的认知而买单。
所以不念过去，不畏将来，活在当下。
人生没有白走的路，对错都算数。 做你该做的事，你脚下的这条路，就是最好的路。

有点鸡汤，但是却真实。

想起刚毕业时的选择，有一回团建，刚好和万兴的 HR 老大在同一个车，在车上，忘记聊到了什么，现在还记得的是结婚是门当户对以及结婚是要：想好了，想清楚了，想明白了。

当时不觉得什么，这么多年过去了，这句话时常在耳边回响。

越来觉得这是一个非常深刻且富有哲理的话题，尤其是当时我这种刚毕业进入 社会的萌新、面对人生重大抉择的阶段，这句话体现认知决策的三个递进层次（当时并不觉得）。

想好了

「想好了」通常指在面对一个选择时，已经做出了最终的决定，并且愿意为这个决定承担责任。这是一个行动导向的层面。

在这个层面，我们：

1. 停止纠结： 不再在 A 选项和 B 选项之间反复横跳。比如在婚姻中，不再犹豫“是不是还有更好的”，而是认定“就是这个人了”。
2. 承诺： 意味着你准备好投入所有（时间、金钱、情感）。
3. 接受现状： 承认目前的条件是做出该决定的基础。

想清楚了

「想清楚了」是理性的我。它要求我们不仅要有决心，还要对事情的前因后果、利弊得失、潜在风险有清晰的推演。这是一个逻辑导向的层面。

此时的我应该做了：

1. 可行性分析： 能够罗列出支持这个决定的客观条件。比如，为什么说我们是“门当户对”的？是因为消费观一致？还是教育背景相似？
2. 风险预判： 知道最坏的结果是什么。如果结婚，双方家庭会有什么矛盾？贫贱夫妻百事哀的概率有多大？如果门不当户不对，差异带来的鸿沟怎么填补？
3. 未来规划： 知道接下来该怎么走。不仅仅是决定结婚，还想清楚了婚后住哪里、钱怎么管、孩子怎么带。

想明白了

最后一个层次，有点属于智慧的范畴。

「想明白了」意味着透过现象看到了本质，理解了自己为什么要做这个选择，以及这个选择对我们的终极意义。这是一个哲学与自我导向的层面。

在这里，我们会有：

1. 自我认知： 知道自己到底是个什么样的人，想要什么样的人生。不是因为父母觉得好，不是因为社会觉得对，而是因为这符合我当时的追求。
2. 接纳不完美： 深刻理解「世事无完美」。想明白了的人，不会因为婚后的一地鸡毛而崩溃，因为他早就理解婚姻的本质就是合作与妥协，而不是童话。

回到工作中，后面有一个自己的感悟，当选择工作时需要想清楚:

• 团队是什么样的团队
• 领导是什么样的领导
• 业务是什么样的业务

团队是我们每天要面对的人，是我们工作的环境，它直接决定了我们的工作体验和执行效率。

就和当前面试一样，如果一个人你看第一眼觉得不舒服，那就不要聊了。

领导是职场中最重要的变量，他掌握着我们职场中的资源分配、绩效评价和升迁路径。

看眼缘和沟通风格，是事必躬亲型还是放权型？是暴躁型还是温和型？

找到和你能匹配上的，相处舒服的。

业务决定了赛道，天花板和市场价值。

以上的选择在不同的时期优先级并不一样：

• 在刚毕业时，优先选领导或团队。
• 随着经验的增加，优先选业务或领导
• 最后你成熟了，可以优先选业务或团队。

可以琢磨一下为啥是这样？欢迎留言探讨。

2025 真的过去了，40 了。

这一年，真要谢谢努力的我们，为了生活起早摸黑，努力奋斗。

在烟火缭绕里谋生，在诗情画意里寻梦。

自始至终未曾虚度，也从未轻言放弃。

再苦再累也咬紧牙关撑过。

感谢这一年坚强努力的我们，希望所有的奔赴都有意义。

不谈过往，不说如果，只希望我们的 2026 越来越好!

这一年，改变，成长，完结；

下一年，希望，迭代，向前，期待。

新年，旧年，皆甜。

写得很虚，没有什么数据和具体的逻辑，就这样吧。

以上。

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，最终要进入的是流程、合规和交付，而不是聊天。

以上。