比较常见的状态是知识走一条 RAG 管道，用户记忆走一个独立的 memory 服务，工具使用经验干脆没有沉淀机制，靠 system prompt 里手写的几条注意事项撑着。跑长周期任务时问题集中爆发：第三十轮时 Agent 忘了第五轮的约束；召回了一段错误文档，事后想归因，向量库只给一个相似度 0.83，别的什么都没有。

这两个 case 背后是同一个架构缺陷：上下文没有被当作一个独立子系统来设计，它只是若干条数据管道的松散集合。

最近把火山引擎开源的 OpenViking 看了一遍，它把自己定位成「面向 AI 智能体的上下文数据库」，GitHub 上 27.2k star。这个定位本身就是一个架构主张：上下文应该是 Agent 架构里一个有统一接口、有存储模型、有检索语义、可观测的独立组件，地位类比业务系统里的数据库。

沿着这个主张往下拆，它有几个设计决策对做 Agent 架构的人有一些参考价值。

统一存储模型

Agent 架构里第一个要回答的问题：记忆、知识、技能这三类上下文，存储模型是分开还是统一。

分开是多数团队的现状，也是我们踩过的坑——三套 schema、三套检索接口、三套更新逻辑，Agent 侧要维护三种访问心智。OpenViking 的选择是统一：全部抽象成文件，挂在 viking:// 协议下的虚拟文件系统里，每个条目一个唯一 URI。它给出的目录结构：

viking://
├── resources/              # 资源：项目文档、代码库、网页等
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/
        │   └── private_project/
        ├── skills/
        │   ├── search_code
        │   └── analyze_data
        └── peers/
            └── web-visitor-alice/

Agent 用 ls、tree、find 浏览自己的上下文。

从架构角度来看，这个统一带来两个收益。第一，定位从概率性变成确定性。扁平向量库里想精确更新某个用户的编码习惯记忆，只能靠 metadata filter 打补丁；文件系统里就是一个路径寻址，viking://user/{user_id}/memories/preferences/coding_habits，增删改查全部确定。多租户隔离也顺带解决了——user/{user_id} 这层目录天然就是隔离边界，商业版文档里明确把多租户共享和隔离列为核心场景。

第二，Agent 与上下文之间的接口收敛成了一套文件操作原语。这一点对架构的影响比看起来大。我们之前自研记忆系统时设计过一套 memory.query(scope, filter, ...) 风格的 API，模型调用的出错率明显高于让它直接操作路径。文件系统是 LLM 预训练语料里高频出现的心智模型，ls 和 tree 的语义模型天然理解，不需要在 prompt 里教。接口设计顺着模型先验走，省下的是持续的 prompt 工程成本。

代价在写入侧的分类决策。内容归置到哪个路径，做错了后续检索会系统性偏航，扁平向量库至少没有「放错文件夹」这种失败模式。OpenViking 靠写入时的自动语义处理来做归置，这个环节的质量上限决定了整棵文件树的可用性，我认为是它工程上最脆弱的一环。

预算分层供给

第二个架构问题：上下文以什么粒度供给给模型。

传统 RAG 的答案是 chunk 全量——检索 top-k 塞进 prompt，k 靠拍脑袋。这在架构上等于把上下文预算的管理责任丢给了一个魔法数字。OpenViking 的方案是写入时预计算三层表示：

• L0（摘要）：约 100 tokens，一句话总结，快速判断相关性
• L1（概览）：约 2k tokens，核心信息和使用场景，供规划阶段决策
• L2（详情）：完整原始数据，确有必要时才读

每个目录也带自己的 .abstract 和 .overview，Agent 读任何完整文件之前，先花 100 个 token 判断这个方向值不值得深入。

放到 Agent 的执行循环里看，这三层恰好对应了三个阶段的信息需求：候选筛选阶段用 L0 扫一遍，规划阶段对少数目标加载 L1，执行阶段只对必要条目读 L2。上下文供给从一次性的赌博变成了跟随 Agent 决策流程的渐进加载，粒度和阶段对齐了。

数据上，OpenViking 0.3.22 在 LoCoMo 长对话记忆评测里，三种 Agent 集成的准确率到 80–83%，原生记忆只有 24–57%；输入 token 减少 34.3%–91.0%，查询时延降低 58.45%–66.10%。token 降幅区间这么宽，说明收益高度依赖任务形态：判断型任务能省九成，需要全量细节的任务省不了多少。评测脚本在仓库 ./benchmark 目录，可自行复现。

架构上的 trade-off 转移到了写入路径。L0/L1 由模型生成，每次数据摄入都有一笔推理开销，且是异步的——README 明确提示 add-resource 不加 --wait 时语义处理需要等待。写入吞吐敏感或数据高频变更的场景，这条路径会成为瓶颈。更隐蔽的风险是摘要写歪：L0 错了，后续所有基于它的相关性判断连带出错，等于在检索链路最上游埋单点。官方提供 ov reindex <uri> --mode semantic_and_vectors 重新生成语义产物再刷新向量，说明他们自己也预期摘要需要返工。

即便不引入 OpenViking，「写入时预计算多粒度表示、按 Agent 决策阶段供给」这个模式可以直接抄进自建架构。

检索即导航

检索组件在 Agent 架构里通常被实现成一个无状态函数：query 进，top-k 出。OpenViking 把它改成了一个有过程的导航。

先通过意图分析生成多个检索条件；向量检索定位初始切片所在的高分目录；在该目录下二次检索，高分结果更新进候选集；有子目录就逐层递归；最终返回最相关的上下文，连同周边语境一起。

一句话概括：先锁定高分目录，再向下精细探索。

这解决的是扁平 top-k 在 Agent 场景下的一个结构性缺陷——碎片没有语境。命中一个 chunk，Agent 不知道它前后是什么、属于哪份文档的哪个章节，拿到的是信息孤岛。导航式检索的返回结果自带位置和邻居：这段内容出自 API 文档的鉴权章节，同目录下还有 endpoints 说明。对代码库问答这类强依赖结构的任务，这个差异是决定性的。

代价：多轮向量查询加上可能的多次判断，单次检索的绝对延迟一定高于一把梭的 ANN。前面提到的时延降低 58%–66%，我的理解是端到端口径——省下的 token 让生成阶段变快，摊平了检索阶段的开销。架构选型时要按流量形态判断：Agent 任务型场景，单次任务价值高、容忍秒级检索，划算；高 QPS 低延迟的在线检索，这套递归策略不合适。

全链路留痕

Agent 架构的可观测性讨论，通常止步于工具调用日志。OpenViking 把留痕做进了检索内部：每次查询都保留完整的目录浏览轨迹，结果不对时能看到它出自哪条路径。

做过 RAG 生产运维的人知道 bad case 归因有多难。用户投诉答案错了，排查下来只能看到「这几个 chunk 相似度最高所以被召回」，正确内容为什么没进 top-k，向量空间不会解释。最后退化成调 embedding、调 chunk 大小、调 k 值的炼丹循环。

轨迹留存把归因变成可逐步 debug 的过程：检索在哪个目录拐错了弯、哪一层的 L0 摘要误导了判断，路径上每一步可查。修复动作随之有了着力点——重写某个目录的 abstract，或者调整文件归置，都对应到具体操作。配套的 OpenViking Helper 桌面端（Beta，支持 macOS 和 Windows x64）能解析 Claude Code、Codex、Trae 的会话，展示召回、Prompt 注入、MCP 调用、捕获和提交事件，Agent 与上下文系统之间的全部交互摆在明面上。

这一条我建议所有做 Agent 基础设施的团队照抄，无论用不用 OpenViking：把「检索决策可回放」写进架构的非功能需求。存储和埋点的成本，第一次生产事故排查时就能收回来。

经验回写闭环

多数 Agent 架构是开环的：任务执行完，除了对话历史什么都不留，下次遇到同类任务从零开始。OpenViking 在架构里补了一条回写路径：会话通过 session.commit() 显式提交后，系统异步提取两类内容写入长期记忆——用户偏好，和 Agent 经验，落到对应的 /memory 目录下。

用户偏好各家都在做。Agent 经验这条更值得看：从任务执行结果里提取操作技巧、工具使用经验，供后续同类任务复用。tau2-bench 的数据：经验记忆让任务成功率在 Retail 提升 6.87 个百分点，Airline 提升 11.87 个百分点，对比同一 LLM 无记忆基线。模型没动，纯靠架构里加一条经验沉淀回路，拿到两位数以内的成功率增量。

对比另一条提升路线——攒数据做 SFT 或 RL 微调，周期以周计，成本以万计。经验记忆改的是上下文而非权重，迭代周期是每次会话。两条路线不互斥，但在架构演进的排序上，外置经验回路的边际成本低得多，应该排在微调前面。

两处要留神。一是提取质量：异步抽取本身是 LLM 调用，抽错等于往长期记忆注入脏数据，且脏记忆会在后续任务里持续生效，危害大于一次性的错误回答。二是显式 commit 这个设计——记忆更新由开发者主动触发而非全自动，「哪些会话值得沉淀」的裁量权留在应用层。我们内部一度想做全自动沉淀，现在倾向于保留这个开关，至少在提取质量有验证机制之前。

接入成本

把这套东西放进现有 Agent 架构的成本，不高。

Python 3.10 以上，pip install openviking --upgrade，openviking-server init 走交互式向导——支持火山引擎、OpenAI、Codex OAuth、Kimi、GLM 和本地 Ollama，选 Ollama 还能按硬件拉合适的模型。openviking-server doctor 启动前体检配置、Python 版本、提供商连通性和磁盘空间。有官方 Docker 镜像和 Helm 部署。

集成面很宽：Claude Code、Codex、OpenClaw、Hermes、Cursor、Trae、OpenCode、pi、MCP 客户端、LangChain / LangGraph 都有官方接入，集成做的事是把召回注入 Agent 上下文并自动提交会话记忆。如果你的架构本来就走 MCP 或 LangGraph，接入成本主要在配置层。

许可证要过法务。主项目 AGPLv3，crates/ov_cli 和 examples 是 Apache 2.0。AGPLv3 自用没问题，基于它对外提供网络服务会触发传染性条款的开源义务。商业版 OpenViking Service 承诺与开源版共享同一套代码内核，差异在托管运维、基于 VikingDB 的规模（宣称万亿级向量、百亿数据毫秒级检索）、SLA 和企业级安全合规，有至多 50 个文件的免费试用和迁移工具。开源版默认本地存储加单机向量引擎，数据规模上去后的可靠性要自己扛，架构容量规划时要计入。

背后有论文支撑：VikingMem（arXiv:2605.29640），已被 VLDB 2026 接收，开源版实现了论文描述的部分核心能力。团队在按数据库系统的标准做存储和检索设计，这在 Agent 记忆类项目里少见。

需要注意的点

三点。

其一，整个体系的地基是写入时的自动语义处理——摘要、概览、目录归置全靠模型生成，这些产物没有质量下界。LoCoMo 和 tau2-bench 覆盖的场景有限，换到术语密集的企业知识库，L0 摘要的准确率会不会崩，要拿自己的真实数据验证，别信 benchmark 直接上生产。

其二，导航式检索的延迟特性划定了适用边界，架构选型时按流量形态判断，前面说过了。

其三，项目还早，README 自己承认「要做的事还很多」。1813 次 commit、92 个 open issue、320 个 PR，迭代活跃，反面是 API 稳定性存疑，核心链路重度依赖它要做好跟版本的准备。

回到 Agent 架构本身。「上下文作为独立子系统」「统一文件存储模型」「按决策阶段分层供给」「检索决策可回放」「经验回写闭环」，这五个设计每一个都能脱离 OpenViking 独立存在。

以上

对于 RAG 的优化，一种线路是继续优化传统 RAG：切块更细一点，召回器多堆几层，重排再优化，最后把 prompt 拼得更精致。另一条线路是开始换问题定义：如果知识检索本身的建模方式就不对，后面那一长串补丁是不是从第一步就已经输了。

SAG 和 OpenViking 属于第二种。

这两个项目看起来也不在一个层面上。SAG 讨论的是检索架构，OpenViking 讨论的是 Agent 的上下文系统。但我看下来，它们都是在解决同一类问题：RAG 之所以越来越重，往往不是因为模型不够强，而是因为我们把「知识」和「上下文」这两个对象建模得太糙。

过去一年，团队在 RAG 上花的钱和精力，主要耗在三个地方：

• 文档切块以后，语义边界被打碎；
• 多跳关联靠 embedding 硬撞，召回经常断链；
• 想补结构化能力，就往 GraphRAG 走，结果离线构图、实体归一、增量更新把系统拖住。

这里的问题是这条路线会把系统带向复杂化。

SAG

SAG 的核心论文《SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges》提出了一种非常精妙的架构。它不是传统 RAG 与 GraphRAG 的简单拼接，而是一套用自己的数据模型和执行路径替代二者的原创检索架构。

它的核心思想可以总结为八个字：轻量离线，动态建图。

1. 数据模型

传统 GraphRAG 把文本切碎，试图把所有知识都抽象成 (Subject, Predicate, Object) 的三元组。这种做法丢失了文本原本的上下文语义，导致最后召回出来的都是一些干瘪的关系链，LLM 很难根据这些碎片生成高质量的回答。

SAG 重新设计了数据模型：

• Chunk  Event（事件）：一个语义完整的文本块（Chunk）被映射为一个 Event。Event 承载该 Chunk 的完整上下文，它是最终输出和溯源的边界，不再被拆成彼此独立的三元组。
• Chunk  Entities（实体）：从该 Chunk 中抽取多个 Entities。这些实体只负责索引和扩展，不替代事件本身所承载的完整含义。
• Event  Entities：建立事件与实体之间的关联，共同定义了一条潜在的超边（Latent Hyperedge）。

+-------------------------------------------------------------+
|                         Original Chunk                      |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|                         Event (完整语义)                     |
+-------------------------------------------------------------+
            /                  |                  \
           v                   v                   v
+------------------+   +------------------+   +------------------+
|     Entity A     |   |     Entity B     |   |     Entity C     |
+------------------+   +------------------+   +------------------+

这个设计让事件和实体各司其职。实体只用来做连接的「钩子」，而事件负责保留完整的语义。

2. 查询时动态超边

SAG 不预先构建、也不全局维护任何静态图谱。所有的关系推理，都是在检索发生的那一瞬间，通过关系型数据库的 SQL JOIN 动态计算出来的。

当一个用户查询（Query）进来时，在线检索流程如下：

1. 种子定位：通过语义（向量）与词法（全文检索）信号，找到与查询最相关的「种子实体」和「种子事件」。
2. SQL 动态扩展：利用关系型数据库的 SQL JOIN 查询，沿着这些种子实体，将共享相同实体的事件连接起来。
3. 局部超边实例化：在查询时，仅针对当前查询所需的局部结构实例化「超边」，不进行任何全局图遍历。
4. 证据还原：将筛选出的事件映射回原始 Chunk，去重后作为最强证据提供给 LLM 生成带引用的回答。

在这个过程中，我们不需要 Neo4j，不需要复杂的图算法，底层的存储与查询完全依赖标准的数据库基础设施（如 SQLite、PostgreSQL、LanceDB 等）。

因为超边是查询时动态计算的，所以当有新文档导入时，不需要重算或重构全局图谱。新 Chunk 只需要并行抽取自身的 Event、Entities 并写入数据库即可。这让系统天然支持了高并发的增量写入。

从跑分数据来看，在相同的 BGE-Large-EN-v1.5 Embedding 与 Qwen3.6-Flash LLM 配置下，SAG 在 HotpotQA、2WikiMultiHopQA 和 MuSiQue 的 9 项 Recall@1/2/5 指标中取得了 8 项最佳成绩。其平均 Recall@2/Recall@5 达到了 79.30%/88.18%，而 HippoRAG 2 仅为 68.14%/83.28%。

一些问题

SAG 不是银弹，还存在一些问题。

抽取质量依然依赖 LLM。Event 的切分和 Entity 的抽取用的还是大模型，模型抽错了，后面的动态连接就是在错误的实体上做 JOIN。SAG 降低了实体的语义负担，但没消除抽取本身的不确定性。这块的鲁棒性得拿自己的语料实测。

查询时的实体提取是另一个隐患。动态超边的起点是从 Query 里提出核心实体，如果用户的提问很口语、实体表达很模糊，种子定位偏了，后面整条链就歪了。这个环节的召回率我认为是整个系统最脆弱的地方，值得单独压测。

还有并发下的延迟分布。JOIN 在数据量大的时候，SQL 的执行计划、索引命中情况会直接影响尾延迟。其底层继承了数据库的并发能力，在海量数据情况下需要观察其延迟分布。

OpenViking

聊完 SAG，看下 OpenViking。它跟 SAG 不是同一个层面的东西，我把它俩放一篇文章里，是因为它们代表了同一个方向上两种不同深度的探索。

SAG 解决的是「怎么把知识检索得更准」。OpenViking 解决的是「Agent 的上下文该怎么组织」。前者是检索问题，后者是上下文工程问题。

火山引擎把它定位成一款面向 AI Agent 的上下文数据库，基于开源的 OpenViking 内核构建的全托管云服务。核心思想它自己概括成四句：虚拟文件系统、分层上下文、目录递归检索、可观测与自迭代。

万物皆文件

OpenViking 把 Memory、Resource、Skill 三样东西统一抽象成文件，全部映射到 viking:// 协议下的虚拟目录，每个条目有唯一的 URI。

这个抽象是 Agent 发展到现在的一种沉淀，这里最早是 Manus 在实践的逻辑。Agent 领域现在最乱的就是上下文管理。你有用户的长期记忆、有外部知识资源、有工具和技能定义，这三样东西各自用各自的存储、各自的检索方式，代码里到处是特判。OpenViking 把它们收敛成同一套文件语义之后，Agent 就能用 list、find 这种统一指令去操作所有上下文。

从模糊的语义匹配变成确定性的文件操作，这个转变对调试很有帮助。向量检索是个黑盒，你不知道为什么这次召回了这几条、漏了那几条。文件系统是白盒，路径、目录结构摆在那，Agent 走了哪条路一目了然。

分层加载

OpenViking 在上下文写入的时候，就自动把它处理成三层。

L0 是一句话摘要，用来快速判断。L1 是概述，包含核心信息和使用场景，供 Agent 在规划阶段决策。L2 是完整原始数据，Agent 确有必要时才深入读取。

这个设计针对的是一个很现实的成本问题。把海量上下文一次性塞进提示词，token 烧钱、容易爆窗口、还引入噪声。分层之后，Agent 在规划阶段只看 L0 和 L1 就能做大部分决策，只有真正要用某份资料的时候才去拉 L2。

我算过一笔账。一个复杂的多步 Agent 任务，如果每一步都把候选上下文的全文塞进去，token 消耗是指数级的。分层供给相当于给 Agent 一个「先看目录再翻正文」的能力，规划阶段的 token 成本能压下去一大截。具体压多少取决于你的任务形态，但这个方向省的钱是实打实的。

目录递归检索

OpenViking 的检索不是单次向量召回。流程是这样：先通过意图分析生成多个检索条件，用向量检索快速定位初始切片所在的高分目录，然后在这个目录下做二次检索，把高分结果更新到候选集合；如果目录下还有子目录，就逐层递归重复二次检索；最后拿到最相关的上下文返回。

「先锁定高分目录，再精细探索内容」，这套策略把向量检索的语义定位能力和文件系统的层次结构结合起来了。单纯的向量检索找到的是孤立的片段，它不理解片段所在的完整语境。目录递归能顺着文件的组织结构，把一个片段周围的语境一起带出来。

这个思路和 SAG 的动态超边其实有相通之处。两者都意识到孤立的语义片段不够用，都想在检索时把「关联」这层信息补回来。SAG 用的是共享实体的 SQL JOIN，OpenViking 用的是目录层级的递归遍历。一个走关系代数，一个走树形结构。解决的底层痛点是同一个。

可观测与自迭代

OpenViking 的检索过程，每次的目录浏览、文件定位轨迹都被完整留存，能看清问题根源、指导检索逻辑优化。

对做过 RAG 调优的人来说，这个能力的分量不用多解释。传统向量检索出了问题，你几乎无从下手，只能瞎调 embedding、瞎调 chunk size。有了完整的检索轨迹，你能精确复盘 Agent 每一次信息获取走了哪条路径，哪一步偏了。

自迭代那部分是通过 session.commit() 主动触发的。会话结束时，系统异步分析任务执行结果和用户反馈，自动更新到 User 和 Agent 的 /memory 目录下。它既更新用户偏好，也从任务执行经验里提炼操作技巧和工具使用经验。

这个闭环我持谨慎乐观。自动提炼记忆听着很美，但提炼的质量、更新的边界、错误记忆的污染问题，都是需要长期跑才能暴露的。我不会一上来就把它当成生产依赖，会先在低风险场景里观察它更新出来的记忆到底靠不靠谱。

SAG 和 OpenViking

写到这，我把 SAG 和 OpenViking 放到一起，讲讲我看到的相同点。

传统 RAG 的世界观是扁平的。所有知识被切成等长的 Chunk，拍平进一个向量空间，检索就是在这个空间里找最近邻。这套世界观简单、好扩展，但它主动丢弃了知识之间的结构信息。Chunk 和 Chunk 之间是什么关系，谁包含谁，谁引用谁，谁是谁的上下文，全都被拍平的过程碾掉了。

SAG 和 OpenViking 从两个不同的方向，试图把这层被碾掉的结构信息找回来。

SAG 找回的是「实体关联」这层结构。它承认知识点之间存在通过共享实体建立的隐式关联，并且用查询时的 SQL JOIN 把这层关联即时重建出来。它的贡献在于证明了这层结构不需要离线物化成一张昂贵的全局图，用关系型数据库现成的关联能力就能在查询时高效算出来。

OpenViking 找回的是「层次组织」这层结构。它承认知识天然有目录、有层级、有从属关系，并且用虚拟文件系统把这层组织显式地保留下来，检索的时候顺着这个层级递归下去。它的贡献在于把 Agent 的上下文从一堆散落的切片，重新组织成了一个可导航、可追溯的结构。

两者都在做同一件事：扁平化的向量检索丢失了太多结构，而这些结构恰恰是复杂查询和长程任务真正需要的东西。它们的分歧只在于用什么载体去承载这层结构。SAG 选了关系表和 SQL，OpenViking 选了文件系统和目录树。

怎么选

落到实际决策，可以分两个场景。

如果核心诉求是知识库的多跳检索精度，语料相对静态、增量频繁、又要给用户看得见的原文引用，建议评估 SAG。它的动态超边在多跳上的数据摆在那，增量友好和溯源能力恰好解决了之前方案的问题。部署门槛低，本地就能验，评估成本几乎为零。

如果做的是 Agent 产品，痛点在长程任务的上下文管理、记忆沉淀、多 Agent 协作，建议去评估 OpenViking。它解决的是比检索更上一层的问题，文件系统抽象和分层加载对控制 Agent 的 token 成本、提升可调试性比较有用。

这两个东西不冲突。理论上一个成熟的 Agent 系统，底层完全可以用 SAG 这类引擎做精准的知识检索，上层用 OpenViking 这类框架做上下文的组织和调度。一个管「检索得准」，一个管「组织得清」，各司其职。

检索这条路走到今天，值得关注的方向已经从「怎么把向量算得更快」转到了「怎么把结构找回来」。SAG 和 OpenViking 是这个转向上两个具体的答案，一个在检索层，一个在上下文层。

以上。

现在我们看到很多的 AI 产品，，本质上还是「把聊天框做得更厚一点」。用户打开一个窗口，对着通识大模型说需求，模型在一个长 session 里记上下文、调几个工具、写几段内容、偶尔执行点操作。这个模式我称它为「Session First」。

「Session First」的模式跑得起来，落地也快。过去一段时间，桌面端的很多产品，包括一些 codex cc 一类的形态，都是这么长出来的。先有聊天，再把能力缝进去。先有 session，再把工具挂上去。整个产品又快又省，因为它继承的是大模型最自然的交互方式：对话。

但如果把时间线拉长，我觉得 Session First 像是一个过渡层。它把大模型带进软件，却没有真正重写软件。

另一个逻辑是 「Agent First」。

这里说的 Agent First，不是把 prompt 包一层 workflow 就算 agent。这里说的是一种更彻底的软件设计取向：系统从一开始就假设调用者不只是人，也包括 agent；系统的能力边界、接口形态、文档组织、安全机制、运行时观测，都优先围绕 agent 来设计。聊天只是入口之一，不再是核心结构。

过去我们是在和「通识大模型」对话，未来更多时候，我们是在和「带有领域知识、工具能力、任务规划能力的专用 agent」协作。再往前走，单一 agent 很可能都不够，基于 MaaS 的 agent teams 会逐步成为复杂任务的常态。Sakana AI 这类工作给了行业一个很有代表性的信号：多智能体协作，不只是研究兴趣，它在复杂探索任务上确实可能优于单体。

这种两种不同的范式，其实也没有高级和低级之分。二者背后的系统假设不同，工程代价不同，性能瓶颈不同，能解决的问题类型也不同。

Session First 和 Agent First 的不同

Session First 和 Agent First，表面上都可能长得像「用户输入一句话，系统输出一个结果」。很多人可能会觉得两者只是包装差异。其实差异蛮大的。

Session First 的中心对象是「会话」。系统假设一切能力都围绕一个持续增长的上下文展开。用户说一句，模型接一句；模型靠历史消息理解意图，靠当前 prompt 决定行为。工具调用存在，但工具通常是会话的附属物。它们由模型在 session 内临时选择、临时编排、临时解释。

所以在 Session First 里，能力组织方式通常是这样的：

1. 先有一个大而全的聊天入口；
2. 再有一组工具函数；
3. 再在 system prompt 或 tool spec 里告诉模型什么时候调用它们；
4. 复杂任务靠更长的上下文、更复杂的提示词、更精细的 few-shot 去兜。

这个模式最大的好处，是产品和研发都能快速起跑。我们不需要先把系统抽象成可组合能力，也不需要先考虑 agent 的长期运行、恢复、权限边界、状态持久化。只要模型够强、上下文够长、工具挂得上去，很多事情都能先做出来。

Agent First 的中心对象则是「行动体」。系统假设执行任务的主体是 agent，它会自己读取规范、规划步骤、调用工具、检查结果、重试修正。人在这个系统里依然重要，但人不再是唯一的控制中心。更准确地说，系统从「为人类交互而生」转向「为可委托执行而生」。

这个变化会连锁改写很多设计决策。

传统软件里，人是第一类公民。系统主要通过 UI 提供能力，文档写给人看，按钮给人点，异常信息也默认人会读。Agent First 里，agent 变成第一类公民。系统的关键界面不再是页面和按钮，而是 API、工具协议、语义化描述、状态机、权限模型、回调事件、执行日志。

传统模式是：

• 人读文档；
• 人理解业务逻辑；
• 人决定点哪个按钮；
• 人承担串联流程的责任。

Agent 模式是：

• Agent 读取规范；
• Agent 形成计划；
• Agent 调用工具；
• Agent 分析返回值；
• Agent 根据反馈继续执行或者回滚。

这不是交互方式的小修小补，这是控制权和复杂性承载位置的转移。

Session First 把复杂性藏在会话里。
Agent First 把复杂性显式地放进系统结构里。

我更倾向后者。因为在规模化阶段会 Session First 开始需要大量的修补并且还不合脚。

Session First 的红利

Session First 也不是说不行了，落后了，它只是有自己的舒适区或边界。

它为什么会成为大多数团队的第一个选择？因为它天然适合模型的原生能力。

大模型最成熟的接口就是聊天接口。你给它上下文，它续写；你给它 instruction，它服从；你给它工具定义，它在概率空间里学着调用。这是当前已经成熟了的，并且对于大家的谁知来说没有门槛的。。产品经理能理解，前端能接，后端能包，用户也能马上用。

从落地顺序看，Session First 有三个明显优势。

交付速度快

最早一批 AI 应用能起量，基本都吃到了这个红利。做一个对话框，叠一层历史上下文，挂几类工具，外加 prompt 工程和少量业务逻辑，一个可卖的产品就出来了。

如果团队处在探索期，需求还没稳定，任务边界也不清晰，Session First 的性价比很高。因为我们可以把大量未定型的业务规则临时编码进 prompt，而不是过早地固化到接口和状态机里。说白了，它适合试错。

交互弹性高

很多需求在早期根本说不清。用户自己也不知道该点哪个按钮，只知道「我想把这堆信息处理一下」。这时聊天入口比传统 UI 更自然。Session First 天然适合承接模糊需求，尤其适合开放式任务、咨询类任务、内容类任务。

对通识模型友好

Session First 依赖的是模型在语言理解和上下文整合上的强项。很多场景下，不需要精细建模世界状态，只需要让模型在一个较长的 session 里维持语义连贯，效果就已经够用了。

所以如果一个产品主要解决的是下面这些问题，Session First 我认为完全合理：

• 单轮或短链路任务；
• 任务结果主要是文本、建议、草稿、分析；
• 工具调用数量少，失败代价低；
• 用户愿意在回路中持续确认；
• 业务状态变化弱，对幂等性和恢复能力要求不高。

比如代码解释、文档问答、简历润色、轻量报表分析、知识库检索助手，这些都很适合。

问题出在很多团队做着做着，把它用到了不该用的地方。

Session 的代价

Session First 最大的问题，不是效果问题，而是系统复杂性的位置不对。

我们可以把 session 理解成一个不断膨胀的黑盒。任务描述、历史记录、工具调用痕迹、失败重试信息、用户偏好、临时约束，全都塞进去。模型在黑盒里靠注意力机制和 token 预算自行判断什么重要、什么该忽略、什么该继续执行。

短任务还行。链路一长，问题就开始多了。

状态污染

会话越长，状态越容易脏。一个典型问题是历史上下文对当前决策的隐性干扰。模型没有传统意义上的干净状态管理，它只有一段被不断续写的上下文。早期的一句错误假设、一次失败调用、一个过时约束，都可能在后续步骤中持续影响行为。

工程上我们会看到一些很烦的现象：

• 明明用户已经修改目标，模型还沿着旧计划跑；
• 明明工具返回了失败，模型把失败结果当成成功上下文继续推理；
• 明明当前任务和上个任务无关，模型还把旧 session 里的偏好带进来。

这些都不是 prompt 多写两句能解决的。因为根因在于 session 本身不是一个严谨的状态容器。

上下文成本失控

Session First 很吃上下文。任务越复杂，历史越长，系统 prompt 越复杂，tool spec 越多，token 消耗越惊人。很多团队前期盯着模型单价，后期才发现账单真正膨胀的是「无效上下文」。

更糟的是，这部分成本并不总能换来线性收益。超过某个长度以后，模型对上下文的利用率明显下降。你花了更多 token，只换来更模糊的关注分布、更高的遗漏概率。

有一些系统，一次复杂任务真正有价值的工作 token 可能只占总 token 的 20% 到 30%，剩下的都在重复喂历史、喂规则、喂工具描述、喂先前失败记录。这样的系统，成本结构很难看。

工具选择不稳定

在 Session First 里，工具往往是通过提示词暴露给模型。模型根据自然语言描述决定什么时候调哪个工具。这种方式灵活，但稳定性一般。尤其当工具数量上来以后，工具间语义重叠、参数边界相近、返回格式不一致，模型的选择质量会迅速下降。

一个常见误区，是以为给工具写更长更详细的 description 就能解决。实际经验正相反：description 越长，竞争工具越多，模型越容易在语义相邻区域摇摆。最终你会发现，问题不是模型笨，而是整个工具层根本没有被设计成适合被模型消费。

可恢复性差

Session 是连续流，不擅长离散恢复。任务执行到一半，模型挂了、超时了、工具限流了、用户关闭页面了，系统怎么从中间恢复？很多 Session First 产品的恢复策略要么是重放整个对话，要么让模型读历史「自己想起来」。

这个策略在低风险任务里还能接受，在执行型任务里就很危险。因为它没有明确的检查点，没有确定的已完成步骤，没有结构化的执行日志，恢复质量完全依赖模型在长上下文里的自我理解。

可观测性弱

你问一个 Session First 系统：「为什么它刚才这么做？」答案通常很难给。因为真正的决策过程埋在 session 和模型隐状态里。你最多能看到 prompt、工具调用记录和输出，但很难形成稳定的、可归因的行为分析。

这会直接影响调试、评估、审计和优化。团队很容易陷入一种很熟悉的工作流：改 prompt、跑样例、感觉好一点、上线、再出新问题、继续改 prompt。系统像在「训一头很聪明但脾气不稳定的动物」，而不是在维护一个可控软件。

转向 Agent

Agent First 出现，本质上是在回答一个问题：当任务不再是聊天，而是委托执行时，系统该怎么设计？

用一名话来概括：Session First 优先组织对话，Agent First 优先组织能力、状态和约束。

这两者的差别，在简单场景里不明显；一旦任务变成多步骤、长周期、高风险、强工具依赖，这个差别会迅速放大。

Agent First 的核心变化有三层。

第一层，agent 拥有独立的任务身份。
它不再只是当前聊天窗口里的一个响应函数，而是一个可启动、可暂停、可恢复、可审计的执行单元。它有自己的目标、记忆、工具权限、运行环境和生命周期。

第二层，系统能力被显式结构化。
什么能力能调用，输入输出是什么，失败怎么表示，重试边界在哪，副作用怎么隔离，全部要写清楚。因为 agent 不是靠「猜」来用系统，它得靠规范来用系统。

第三层，任务执行被流程化和可观测化。
agent 的计划、步骤、结果检查、异常处理、人工介入点，都需要成为系统的一部分，而不是 prompt 里的一段希望。

这就是为什么我说 Agent First 更像软件设计理念，而不只是交互升级。它要求开发者从一开始就考虑 agent 的接入体验。注意，这里的「接入体验」不是 SDK 文档写得漂不漂亮，而是系统有没有把 agent 当成真正的使用者来对待。

对人友好的系统，重点是 UI。
对 agent 友好的系统，重点是 API、协议、文档、沙箱、日志。

这个顺序一换，整套架构都会变。

第一类公民

传统软件的第一类公民是人。因为系统操作链条默认由人承担：读页面、理解状态、做选择、点按钮、确认风险、处理异常。

Agent First 的变化在于，这条链路开始迁移给 agent。系统如果还保留「很多关键信息只藏在页面里、很多操作只能靠人脑理解、很多异常只有人看得懂」的设计，那 agent 就只能在外面绕路，最后产品体验会非常拧巴。

所以所谓「agent 是第一类公民」，落到工程上至少意味着四件事。

能力必须接口化

页面点击不是能力，API 才是。
表格展示不是能力，结构化查询和变更才是。
人工读懂的描述不算完成，机器可消费的 schema 才算完成。

很多团队表面上说在做 agent，实际上只是让模型去模拟用户点页面，或者让 Playwright 去跑浏览器自动化。这能用，但我通常把它看成过渡手段，不会把它当成长期基建。因为 UI 自动化的脆弱性太高，成本也太高。一旦页面变了、字段换了、弹窗多了、权限策略改了，整个链路就坏了。

如果一项业务能力值得被 agent 使用，那它应该先被抽成稳定接口。

语义必须外显

我们靠经验猜按钮含义，agent 不行。我们得把操作语义、字段含义、约束条件、异常语义都写出来。很多传统系统文档的问题，不是文档少，而是文档默认阅读者是熟悉业务的人。里面有大量省略、上下文跳跃、术语别名、口头约定。

人能脑补。agent 不会脑补，它会误解。

机器友好的文档，不是把原文档丢给 RAG 就结束了。它要求内容可索引、可切片、可定位、可引用、可验证。最好还能区分「定义」「约束」「样例」「反例」「危险操作」「返回码语义」。

权限必须细粒度

给人开的权限，往往是按角色开的。给 agent 开权限，粒度要更细。因为 agent 的调用频率高、组合能力强、自动化程度高，任何一个权限放大，都可能把小问题变成系统性事故。

我见过一些团队初期为了快，直接给 agent 一个「管理员 token」，想着先把链路跑通。跑通确实跑通了，后面风控和审计基本没法收场。Agent First 里，权限模型必须从 day 1 就设计进去。至少要做到工具级、资源级、动作级的边界清晰。

结果必须可审计

如果 agent 能执行动作，那所有关键动作都要留痕，谁发起、为什么发起、使用了哪些上下文、调用了哪些工具、拿到了哪些结果、做了什么决策、是否有人确认，都得能追出来。

这不是为了满足审计部门，而是为了我们自己能把系统维护下去。没有可审计性，复杂 agent 系统很快会变成「偶尔非常惊艳，偶尔完全失控」的黑箱。

四层结构

如果我们把 Agent First 的工程原则压缩成一个递进结构，它可以拆成四层：能力层、理解层、连接层、信任层。

API 优先

最底下是能力层，也就是 API 优先。它解决的是「Agent 能做什么」。

很多 AI 团队容易犯一个错误：先做 prompt，再做工具，再补 API。顺序反了。只要你准备认真做 agent，API 就应该先于 prompt 存在。

因为 prompt 负责引导决策，API 才负责承载能力。没有稳定能力面，agent 的执行质量永远靠运气。

我看一个系统适不适合 Agent First，第一眼就看它的 API 长什么样。重点不在 REST 还是 GraphQL，也不在用不用 MCP，而在这几个问题：

• 接口语义是否单一清晰；
• 参数是否结构化且有约束；
• 返回值是否可判定成功失败；
• 幂等性是否明确；
• 长任务是否支持异步和回调；
• 副作用操作是否支持 dry-run 或预检查；
• 错误码是否可用于 agent 自恢复。

举个很实际的坑。很多内部系统的 API 是给前端页面写的，不是给 agent 写的。于是你会看到：

• 一个接口返回几十个业务无关字段；
• 失败时只返回「操作失败，请联系管理员」；
• 同一个字段在不同接口里名字还不一样；
• 创建和更新共用一个入口，副作用混杂；
• 数据查询支持模糊匹配，但没有稳定过滤条件。

这种 API 给前端开发凑合能用，给 agent 基本就是灾难。因为 agent 消费接口时最怕三件事：语义不稳定、返回不可判定、失败不可恢复。

API 优先不是一句口号，它意味着你要为了 agent 重写一部分服务边界。代价不小，但省下的是后面无数轮 prompt 补丁。

机器文档

有了能力层，还不够。Agent 知道系统「能做什么」，不代表它知道「怎么正确地做」。

这就是理解层，也就是机器友好文档。

很多团队对文档的理解还停留在「给模型塞进知识库」。坦白说，这一步最多算资料接入，不算文档工程。机器友好文档要求内容本身就是为 agent 理解和执行设计的。

我们写文档喜欢写背景、写故事、写注意事项穿插在长段落里。机器文档要反过来，尽量消除叙事性，强化检索和判定性。什么场景能用哪个接口，前置条件是什么，参数组合有什么限制，成功条件是什么，失败后应该重试还是终止，全部要能被定位出来。

我比较推崇一种写法：把文档拆成五类最小单元。

1. 定义单元：术语、对象、字段、状态含义。
2. 操作单元：动作描述、输入输出、前置条件、后置条件。
3. 约束单元：权限要求、配额、时序、互斥关系。
4. 异常单元：错误码、成因、恢复建议、是否可重试。
5. 样例单元：正确示例、错误示例、边界示例。

这样写出来的文档，对人读可能不友好，但对 agent 非常友好。因为 agent 需要的不是阅读体验，而是最短路径上的高密度语义。

还有一个容易被忽略的点：文档版本化。
如果系统能力在变，而 agent 依赖旧文档决策，事故几乎是必然的。机器文档必须带版本、带生效范围、带弃用说明。更进一步，文档变更最好能够被 agent 订阅或者被平台主动推送。否则你会得到一堆「以前能跑今天突然不行」的鬼问题。

协议层

再往上一层是连接层，也就是标准化协议。我们都知道 MCP，它当前重要性确实在上升。

Agent First 一旦进入平台化阶段，连接成本会成为瓶颈。每接一个系统都重新对工具做 schema 包装、鉴权对接、错误语义映射、流式交互适配，团队很快就会被集成工作拖死。标准协议的价值就在这里：让 agent 对外部能力做到尽可能低摩擦的即插即用。

协议不是为了优雅，是为了降低耦合和重复劳动。它至少解决三个问题：

• 能力发现：agent 如何知道外部提供了哪些工具和资源；
• 调用协商：参数 schema、返回 schema、流式能力、状态反馈如何统一；
• 安全边界：认证、授权、调用隔离、资源限制如何标准化表达。

MCP 这类协议的意义，不只是统一 tool calling 的表面格式，更重要的是把「能力元数据」变成平台可理解的对象。一旦元数据标准化，很多平台能力才能长出来：自动装配、权限编排、调用治理、能力市场、兼容性检查、离线评测。

协议统一不会自动带来效果统一。现实里最常见的问题是：大家都说自己支持标准，结果 schema 质量参差不齐，语义粒度不一致，错误处理风格也不同。最后 agent 虽然能连上，依旧很难稳定用好。

所以协议层只是接入下限，不是体验上限。系统方如果指望「支持 MCP 了，agent 就能用了」，十有八九会失望。

信任成本

最上面一层是信任层：安全、沙箱、可观测性。它解决的是「Agent 如何被安全地使用」。

这层往往是被低估的。因为很多团队在前期更关心效果演示，安全和观测总想放后面补。等 agent 真开始执行动作，补起来就很痛苦。

Agent 系统的风险和传统自动化脚本不完全一样。脚本通常路径固定、输入有限、行为可枚举。Agent 的输入是开放的，计划是动态的，工具组合是可变的，自修正带来恢复能力，也带来行为不可预测性。这种系统如果没有信任层，部署规模一上来迟早出事。

信任层可以分为三块。

安全边界

包括权限控制、数据隔离、密钥管理、配额限制、危险操作确认机制。所有高风险动作都要能分级：只读、可写、可执行、不可逆。不同级别的动作，对应不同的确认和审计策略。

还有一件事必须单独说：prompt injection。
只要 agent 会读取外部内容、再基于内容调用工具，prompt injection 就不是附加风险，而是基本风险。你不能假设模型会自己免疫。系统层必须有输入隔离、指令优先级控制、工具调用白名单、敏感动作二次确认、结果验证。

沙箱执行

如果 agent 能运行代码、操作文件、访问网络，就必须有沙箱。别指望靠「模型会守规矩」来兜底。资源限制、网络出口策略、文件系统隔离、进程生命周期管理，这些都是必须项。

很多桌面端产品今天还在用一个比较重的本地 session 容器去承接 agent 行为，这在早期合理，因为本地环境天然带着用户上下文和工具可得性。但一旦平台化，执行环境一定要可控、可回收、可复制。否则你会发现 bug 根本没法稳定复现。

可观测性

这一块经常被做得太浅。普通日志不够。你需要的是面向 agent 的运行时观测：任务级 trace、步骤级事件、工具调用链、上下文快照、计划变更、重试原因、人工接管点、最终结果评估。

有了这些数据，很多事情才有可能做：行为分析、失败归因、离线回放、A/B 对比、策略优化、合规审计。

我甚至会说，没有可观测性，Agent First 根本不成立。因为你没法持续优化一个你看不见的系统。

单体与团队

再往前一步，Agent First 还会带来一个自然演进：从单一 agent 走向 agent teams。

这个趋势不难理解。单体 agent 的优势是简单、上下文统一、决策路径短。缺点也明显：任务一复杂，规划、执行、验证、知识检索、异常恢复全压在一个主体上，容易出现上下文拥堵和角色冲突。模型一边要想战略，一边要写细节，一边还要检查自己，稳定性会下降。

多 agent 协作的思路，是把不同职责拆开。比如规划 agent 负责分解任务，执行 agent 负责调用工具，验证 agent 负责检查输出，审计 agent 负责看风险和合规。你提到 Sakana AI，我觉得它给行业的启发就在这里：复杂问题的效果上限，未必来自更大的单体，而可能来自更合理的协作结构。

但别高估 agent teams 的短期收益。它的工程成本很高。

第一，通信成本会增加。
agent 之间传递的信息如果不够压缩，token 成本会迅速膨胀。很多团队做多 agent，最后账单翻倍，效果提升却不明显，问题就出在这里。

第二，错误归因更难。
单体 agent 出错，你还知道看一条链。多 agent 出错，很可能是上游规划有偏差、中游执行误解了任务、下游验证规则又太松。没有细致的 trace，很难定位。

第三，协作协议本身就是复杂度。
谁能给谁发任务，谁对谁有覆盖权，冲突怎么解决，结果以谁为准，失败是否回滚，人工在什么点介入，这些全得定规则。规则一多，系统会变得很重。

它是复杂任务的方向，但不是所有产品都该急着上。很多团队连单体 agent 的能力边界、观测体系、权限模型都没建好，就直接跳多 agent，最后只会把问题放大。

个人的判断

如果今天让我给团队定路线，我不会在所有场景里一刀切推 Agent First，也不会继续把 Session First 当主架构。

我的判断是这样的：

凡是以「理解、生成、陪伴、咨询」为主，任务链条短，用户始终在线，副作用低的场景，Session First 依然是最有效率的方案。别把简单问题搞复杂。一个高质量 session 产品，照样能有非常强的竞争力。

凡是以「委托执行、跨系统操作、长周期任务、可恢复流程、强审计要求」为主的场景，应该尽早转向 Agent First。拖得越久，后面迁移成本越高。因为你的 prompt、工具、日志、权限、数据结构都会按 Session First 的惯性越长越歪，最后很难矫正。

从行业演进看，我认为我们会经历三个阶段：

第一阶段，通识模型 + 聊天入口主导。
第二阶段，聊天入口还在，但底层逐步 agent 化，能力和状态开始结构化。
第三阶段，很多系统默认面向 agent 开放，我们反而通过 agent 间接使用软件。

今天大多数团队还处在第一阶段和第二阶段之间。很多产品表面上已经在说 agent，骨子里还是 session 产品。这个阶段没什么丢人的，行业本来就处在过渡期。问题在于，团队自己得知道自己在哪，不要把一个 prompt-heavy 的聊天系统误以为已经完成了架构升级。

小结

Session First 帮行业把 AI 快速带进了产品。它的重要性不用否认。没有这一阶段，大量需求不会被激活，很多团队也不会积累起对模型能力边界的真实理解。

但它的问题也越来越明显：状态管理松散、成本结构失真、工具使用脆弱、恢复和审计能力薄弱。任务越复杂，缺点越放大。

Agent First 把软件重新组织了一遍：把会话里的隐含复杂性，搬回系统里显式管理；把面向人的操作界面，扩展成面向 agent 的能力界面；把「模型偶尔能做成」变成「系统可稳定交付」。

如果要走这条路，我们就需要重写 API，补文档债，需要重做权限和日志，就会发现以前很多偷过的懒都要补回来。可如果我们的目标不是做一个会聊天的功能，而是做一个能被委托工作的系统，这些账早晚都要还。

所以我现在看一个 AI 产品会更关心它底下埋的是 session，还是 agent。前者决定它今天看起来多聪明，后者决定它一年后还能不能继续长。

以上。

是的，AI 发展太快了，回望去年的这个时候，我们写代码的方式还不一样，问问题的方式还不一样。

我不是焦虑效率的问题，也不是那种怀旧式的「古法编程才有灵魂」。我想的是：当生成成本持续下降，一个工程师最稀缺的能力，正在从「产出内容」快速转移到「做判断」。判断接口该不该拆，技术债该不该还，需求方嘴里的「必须」到底有多必须，模型给出的十种方案里哪一种能进生产，哪一种看上去漂亮、上线就炸。

这些事情，AI 没替我们做。相反，它把问题放大了。

因为现在最大的问题不再是「不会做」，而是「太容易做」。不会做的时候，人天然会慢一点，会查资料，会多问一句依赖边界，会想清楚为什么。太容易做的时候，团队最常见的路径就是：先生成，后理解；先上线，后治理；先把东西拼起来，再假设以后有时间收拾。

然而，「以后」通常没有以后。

越发觉着：AI 时代我们应该给自己保留一块慢思考的区域。这个「慢」不是拖延，不是低效，也不是故作深沉。它是一种刻意建立的认知阻尼：在系统已经足够快的时候，给判断过程增加必要的摩擦，避免人被工具的流速裹走。

那应该在哪里慢呢？

第一类，涉及不可逆成本的决策。架构选型、数据模型、权限边界、组织职责划分、供应商绑定、长期协议、核心链路改造，这些事情一旦定错，后面修复成本不是线性增加，而是指数级外溢。这里多花的两天，常常能省掉半年。

第二类，涉及复杂因果的问题。线上事故、质量下降、组织失灵、协作冲突、项目延期，这些问题都很讨厌，因为表象清楚，因果混乱。你以为是人不行，实际是流程激励错了；你以为是系统不稳，实际是变更策略太激进；你以为是模型效果差，实际是评测集污染了。这里如果追求快，通常只会更快地走向错误归因。

第三类，涉及个人能力沉淀的问题。写作、复盘、独处、长时间运动，我都把它们看成工程能力的一部分。它们看上去不产出代码，也不直接提升 QPS，但它们在训练更底层的东西：抽象能力、因果判断、注意力稳定性、抗噪能力。

「慢」也不是对抗效率，它是在给不同问题分配不同的时钟频率。流水线可以高频，人脑不能一直高频。CPU 长时间拉满会降频，人也一样。

如果有人问如何让自己慢下来，我觉得可以试试「写作，跑步，独处」

如果让我只保留一种慢思考训练方式，我大概率会选写作。

写作有几个好处。第一，成本低。你不需要设备，不需要场地，也不需要别人配合。第二，反馈直接。你只要写到第三段，就会发现自己到底有没有想清楚。第三，它能留下痕迹。很多模糊的感受，过几个月再回头看，你能看到自己当时的盲区和惯性。

作为技术人可以写些什么？个人觉得可以写如下的三类：

一类是方案备忘录。不是给别人看的那种完整文档，而是给自己看的判断草稿。问题是什么，已知事实有哪些，未知变量有哪些，我现在倾向哪个方案，为什么，最大的风险是什么，什么证据会让我改变主意。字不用多，关键是强迫自己把判断摊开。

一类是事故后记。不是标准复盘模板，而是写自己当时的认知过程。告警出现时，我第一反应是什么；我为什么排除了某条线索；我在哪个时间点开始被带偏；哪些历史经验帮了我，哪些历史经验害了我。这种东西写多了，慢慢会形成个人的故障判断档案。

还有一类，是长期主题写作。比如我们持续观察 AI 对研发组织的影响，或者持续观察某种架构范式在公司里的落地摩擦。这个过程很像做一个长期实验。每写一次，你都在更新自己的认知模型。它的回报不是立刻可见，但一年以后，你和大多数只看热闹的人会拉开明显差距。

写作最大的价值，是它逼你把借来的观点变成自己的结构。很多人平时听播客、看文章、刷帖子，输入很多，但脑子里一直是别人搭好的脚手架。只有自己写，才知道哪些梁是空的。

现在的信息环境非常密集。微信、钉钉、飞书、邮件、群消息、监控告警、PR 评论、AI 对话框，人的注意力被切成很多片。更麻烦的是，AI 还在不断提供一种幻觉：只要你卡住了，马上可以问，马上有回应，马上有一个差不多能用的答案。

久了之后，人会失去和一个难题长时间待在一起的能力。

而很多真正重要的问题，都不适合马上回答。一个组织为什么在扩张后决策质量下降，一个平台为什么越做越重，一个团队为什么开始迷恋短平快，一个技术负责人为什么明明很忙却越来越没有关键产出。这些问题都需要没有输入干扰的时间。你要让问题在脑子里发酵，要允许一些不舒服的空白存在。

AI 时代，人越来越容易只活在符号系统里：文档、消息、代码、表格、指标、提示词。跑步这种事的价值，在于让你暂时脱离符号洪流，回到一个更低带宽、但更连续的状态。这个状态对思考质量很重要。

当然，不一定非要跑步。长距离步行、游泳、骑行，甚至一个人安静地做家务，都可能进入类似状态。关键不在运动形式，在于持续、低干扰、有节律。

上面这些动作最终都是为了让自己有更好的判断力。

那如何构建判断力？

经常有人说「多见世面就有判断力」。这么说是有点空的，判断力当然和经验有关，但经验要看是怎样的经验。一个人做了十年项目，也可能只是把一年的经验重复了十次。

所以判断力要长出来，我觉得至少需要四样东西。

第一，能区分事实、解释和决策。浅一点，就像我和娃经常说的，这是一个观点还是一个事实。

第二，多想几步。

第三，能在不完整信息下做下注，决策。

第四，能复盘自己的错判。

就个人来说，一直在坚持的也就是写作了：

写作。不是为了发什么，也不是为了做内容号，也不是为了经营人设，就是把脑子里的判断落到纸面上。很多混乱的感觉，落到纸面上就清晰了。同时也是为了让有一个固定的和 AI 独处的时间。

我对「ai 时代，让自己慢下来」的理解，大概就是这么个意思：该快的地方拼命快，该慢的地方死守住。别把自己的大脑训练成一个只会接提示、吐结果的中转器。工具越来越强，人更不能放弃那部分缓慢、笨重、但决定上限的能力。

很多年后回头看，一个工程师、一个技术负责人，判断其能力强弱，大概率都不在他一小时能生成多少内容，而在他面对复杂局面时，能不能稳住，能不能看深一层，能不能在一堆看似正确的答案里，挑出那个真正应该做的决定。

这个能力，快不出来。

后记：

其实这篇文章也是在早上慢慢骑车的时候，忽然蹦出来的一个想法，周六还在想这周写点什么呢。

慢一点，也好。

以上。

这一轮 AI（LLM），引发了组织的变化，不限于裁员，裁员只是一个表象，根本的逻辑是组织里「信息如何流动」「决策如何形成」「责任如何落地」这些变了。我们所看到的多了一个写文案、写代码、做 PPT 的工具，或办公室里多了几个自动化插件等等只是改变过程中的一些小的细节。从改动的范围来看，可以看到改了分工边界，改了岗位能力结构，改了系统设计方式。

LLM 的本质是概率，而组织的运行机制长期建立在确定性流程之上。两者天然有张力。

我们先从这个张力聊起。

AI 的概率

LLM 本质上在做什么，其实没那么复杂。它不断预测下一个 token 的概率分布，然后选一个输出。工程上当然有大量细节，训练、对齐、采样、上下文窗口、推理优化，全都很重要，但如果站在组织设计和系统设计的角度看，本质抓这一条就够了：它是一个基于统计规律生成结果的系统，不是一个内置事实表的确定性引擎。

这种概率会带来三种情况。

第一，它擅长处理语言空间里那些「没有唯一标准答案，但存在高质量分布」的问题。写一封邮件、总结会议纪要、整理需求文档、把一段含糊的人话翻译成结构化任务、把一段自然语言转成代码、把代码转成测试思路，这些都在它的甜品区里。因为这些任务的目标，通常不是 100% 唯一真值，而是「大致正确、结构合理、表达顺畅、足够可用」。

第二，它天然会出错，而且错误方式不稳定。这个不稳定比单纯出错更麻烦。传统程序的 bug，很多时候是可复现的；概率系统的错误，经常和上下文、提示词、检索片段、采样参数甚至前面对话历史相关。你今天问它一个问题答对了，明天换个表述可能就偏了。组织里一旦把这类系统直接挂到核心流程上，没有护栏，事故几乎是必然事件。

第三，它的价值密度和上下文质量高度相关。LLM 不是知道很多事，它是「在给定上下文里，尽量生成一个看起来最合理的延续」。上下文差，输出就漂；上下文乱，输出就幻觉；上下文冲突，输出就迎合最新、最强、最显眼的片段。很多团队说模型不行，实际问题常常不在模型，而在输入的上下文是脏的、散的、旧的。

所以我不太赞成把 LLM 讲成一个无所不能的智能体。它先是一个概率生成器，然后才有机会在工程体系的约束下，表现出接近「助手」「代理」「协作者」的形态。顺序不能反。顺序一反，组织判断就会出偏差。

AI 擅长什么

AI 擅长处理「高信息密度、强语言接口、允许一定容错」的工作。

这句话可以分成三层。

先看「高信息密度」。很多工作不是体力活，也不是纯计算活，而是信息压缩和信息展开。比如把一小时会议录音压成一页决策摘要，把十几页 PRD 展开成研发任务清单，把客服历史对话归纳成问题分类，把一段用户吐槽整理成产品缺陷候选列表。这里面的核心动作，是抽取、改写、重组、归纳、补全。这些正好是 LLM 的长项。

再看「强语言接口」。凡是系统入口是文字，或者能被文字中介的任务，LLM 都容易插进去。人和人之间的沟通是这样：邮件、会议纪要、汇报材料、招投标文档、制度说明、客服回复、法务初稿。人和机器之间也一样：代码、SQL、脚本、配置说明、API 调用说明、测试用例、运维排障问答。语言是组织里成本最低的通用接口，LLM 恰好是一个超强的语言接口适配器。

最后是「允许一定容错」。这个很关键。生成营销草案，错一个措辞问题不大；会议纪要漏掉一个次要背景，人工补一下也能过；代码写得不优雅，工程师重构即可。可一旦到了财务记账、医学诊断、风控审批、合规审查、生产数据库变更，容错空间急剧收窄，这时单靠 LLM 就不成立了，必须引入外部约束和确定性校验。

很多人喜欢问：AI 最适合创新吗？它在很多场景里看起来有创造力，本质上还是在高维语料分布里重组已有模式。你把它放在头脑风暴、方案发散、草稿生成、风格迁移这些位置，它常常很好用；你让它承担关键判断、原创理论、复杂博弈中的最终拍板，就容易高估。组织里最危险的一种误判，就是把「表达上的流畅」误当成「认知上的可靠」。

幻觉成本

既然本质是概率，幻觉就不是偶发现象，而是系统特性。工程上不能用「尽量减少幻觉」这种空话处理，得把它转成成本模型。

AI 输出错误带来的成本可以分成四档。

第一档是可忽略成本。比如内部 brainstorm、文案初稿、十几种标题备选、图片风格探索、非正式知识问答。这里错了，最多浪费几分钟。这个区间可以大胆上，用得越多收益越明显。

第二档是可复核成本。比如需求摘要、代码初稿、测试建议、客服回复草稿、制度文件初稿。AI 先出，人再审。这里的关键不是「AI 准不准」，而是「人工审核的单位成本有没有明显下降」。如果 AI 生成 10 分钟、人工审 15 分钟，比纯手工还慢，那系统就没有价值。

第三档是高代价成本。比如财务报表解释、合同条款分析、生产事故归因、管理层决策备忘、对外承诺邮件。这里可以用 AI，但只能把它放在材料整理、信息召回、风险提示、版本比较这些环节，不能让它直接输出结论然后裸奔进入流程。

第四档是不可接受成本。比如自动放款、自动诊断、自动封禁、自动执行线上高危操作。这个区间里，AI 可以当辅助组件，不能当最终裁决者。谁要是说可以靠 prompt 把风险压下去，我建议他先自己签事故责任书。

很多 AI 项目上线后口碑崩掉，不是因为模型太弱，而是因为组织没有做这四档划分，把一个只能承受第一、第二档错误的系统，硬塞进第三、第四档流程里。然后一出事故，大家又反过来得出一个结论：AI 不靠谱。这个结论也粗。不是 AI 靠不靠谱的问题，是你把概率系统放错了位置。

语言接口

AI 先改变的是沟通层。

组织里大量时间，其实消耗在信息传递损耗上。会议里讲一遍，纪要里写一遍，IM 再同步一遍，邮件里再确认一遍，系统里再录一遍。每传一次，信息就损耗一次。很多管理动作看起来是流程，底层其实是语言重编码：同一个事实在不同角色之间用不同表达方式重复流动。

AI 它能把组织内部大量低效的语言重编码吞掉。

比如会议。以前最常见的问题不是没人开会，而是会开完之后没人知道结论是什么、责任人是谁、时间点是什么。AI 介入之后，会议纪要生成只是最表层的能力，真正有用的是把会议内容自动结构化成「决策」「待办」「风险」「争议点」「需要补充的数据」。再往前走一步，它还能把这些结构化结果投递到项目系统、工单系统、邮件系统。这样一来，会议不再只是一次同步动作，而是流程触发点。

再比如客服。传统客服系统里，知识库维护和话术更新一直是重活，因为产品变化快、用户问题脏、运营表达不统一。AI 能做的不是简单替代客服，而是在对话中动态把用户语言映射到组织内部知识表示，再反过来生成可发送的话术。这里的重点在映射，不在生成。生成只是最后一公里。

文件和邮件也是同理。大量中层管理者的工作，本质上就是把上层要求翻译成执行语言，再把执行结果翻译成汇报语言。这种岗位在 AI 时代不会消失，但能力要求会变。以后拼的不是谁更会写四平八稳的材料，而是谁能把复杂上下文压成清晰约束，再让 AI 快速出一个高质量草稿，然后自己做判断、修正和承担责任。

我自己的观察是，组织里越依赖文字流转的部门，越早感受到冲击。产品、运营、市场、售前、客服、法务、人力、PMO，变化都会很快。研发部门也会变，但方式不同，因为研发除了语言，还有执行环境、依赖关系、可验证结果。

代码接口

人和机器的沟通，影响更深。

写代码这个场景特别有代表性，因为它处在语言和确定性的交界处。你可以用自然语言表达需求，再把它落成代码；代码又能被编译、测试、运行、监控。这意味着代码场景天然适合做 AI 闭环：生成、执行、验证、修复。

所以过去几年里，很多人对 AI 编程非常兴奋，这个兴奋也不是没道理。代码生成看起来像是 LLM 最接近「生产力爆炸」的场景之一。但我想泼点冷水：AI 对研发组织的改变，远不是「工程师以后只写提示词」这么简单。相反，它会把研发团队里原来被掩盖的问题全部放大。

先说它为什么有效。

代码是一种形式化程度很高的语言。相比普通自然语言，代码的局部约束强得多。函数签名、类型、编译器报错、单元测试、lint、运行日志，这些都是天然的反馈信号。LLM 在这种环境里有很大的补偿空间：哪怕第一次写错，也能根据错误信息继续修。这和纯文本写作不同，后者很多时候没有硬反馈，模型会一直在表面流畅里打转。

再说它为什么危险。

AI 生成代码最容易制造一种幻觉：速度很快，所以大家误以为生产率变高了。其实你仔细分析，会发现它提升的是「局部代码生成速度」，压缩的是「从想法到可运行草稿」的路径。可软件工程的大头从来不只是写那几百行代码，还包括需求澄清、边界识别、数据模型设计、兼容性判断、上线策略、回滚方案、异常监控、技术债控制。AI 把代码产出变快之后，如果团队没有同步升级评审、测试和架构约束，结果通常不是交付加速，而是债务积累加速。

这个阶段最吃香的工程师，不会是最会背 API 的人，而是能把模糊问题压成清晰约束的人。因为当生成代码越来越便宜，真正稀缺的是「定义问题」「拆解边界」「识别风险」「验证结果」这些能力。说白了，认知成本上升了，体力成本下降了。

分工重排

很多组织对 AI 的讨论还停留在岗位替代，这个视角太窄。更真实的变化是分工重排。

过去一个团队的分工，通常建立在技能稀缺性上。谁会写 SQL，谁来取数；谁会做 PPT，谁来写汇报；谁懂接口，谁来串系统；谁写字快，谁来出方案。AI 进入之后，这些技能门槛在快速下降，至少在初稿层面下降得非常明显。于是边界开始模糊。

产品经理能直接拉出接口草稿，运营能自己写分析脚本，客服能生成复杂工单摘要，销售能快速定制方案材料，研发能自己产出一版文档和测试清单。这不是说岗位没了，而是说原来靠工具门槛形成的协作边界在被打破。

边界一旦模糊，组织就会出现两个结果。

一个结果是协作效率提升。很多以前必须跨团队流转的小请求，可以在本地闭环完成。流程变短，等待减少，中间人变少。

另一个结果是责任变模糊。谁对输出质量负责？谁有权发布？谁能修改生产配置？谁来判断数据口径？如果一个运营通过 AI 生成了 SQL，查出了一个结论，然后管理层按这个结论做了决策，出了问题算谁的？这类问题不会自动解决，甚至会因为 AI 提高了跨界操作能力而变得更尖锐。

所以组织设计在这个阶段不能只盯着效率，还得重画责任边界。我的想法是：把「可以生成什么」和「可以决定什么」拆开管理。生成权限可以放宽，决策权限必须收紧。让更多人能借助 AI 产出草稿、跑分析、搭流程，但涉及发布、审批、执行、对外承诺、线上变更这些动作，要保留明确的责任人和系统审计链路。

很多公司推进 AI 时，最大的管理失误就是只降门槛，不补治理。最后结果是人人都能做点什么，但谁都说不清最后谁负责。

认知升值

我越来越强烈地感觉到，AI 时代组织里最昂贵的资源不是执行力，是认知带宽。

为什么这么说。

因为 AI 会把大量表达型工作、整理型工作、模板型工作压缩掉。以前一个人花两小时整理材料，现在十分钟就能出草稿。表面看，省下来的是时间；实际上，组织会要求你把这些省下来的时间拿去处理更复杂的问题。于是岗位的价值锚点变了。

以前很多岗位的竞争力来自熟练度。你熟悉流程、熟悉模板、熟悉系统，就能稳定地产出。以后这部分价值会明显贬值。你当然还是需要熟练，但熟练本身不再稀缺。稀缺的是你能不能快速理解问题本质，给出高质量约束，判断 AI 输出哪里不对，以及在信息冲突时做取舍。

这对中高级工程师和技术管理者的影响尤其大。

对工程师来说，以前你可能因为写得快、写得稳而表现突出。以后只靠这个不够。你得更擅长做抽象、定接口、控复杂度、识别隐藏依赖。AI 可以帮你铺代码，帮你补测试，帮你查文档，但它不会替你承担架构失误。

对管理者来说，变化更快。很多管理动作原本依赖信息不对称：你更会写、更会总结、更会汇报，所以你能组织信息、控制节奏。AI 把这些能力普及后，管理者如果没有更强的判断力和取舍能力，很容易被削弱。以后优秀管理者的核心能力，会更靠近「问题 framing」「优先级治理」「跨团队对齐」「责任闭环」。

说得尖锐一点，AI 会让大量「会做事的人」继续有价值，但会让大量「只会把事情说得像做过一样的人」很难藏住。

组织断层

AI 进入组织后，最先出现的不是全面升级，而是断层。

我见过最典型的断层有三种。

第一种是个人能力和组织能力断层。个别人用 AI 用得飞起，产出效率暴涨；组织层面却没有对应流程，结果这些人的经验不可复制，也无法沉淀。今天靠几个高手撑着，明天人一走，系统就归零。

第二种是试点效果和规模效果断层。小范围试点很好，因为样本少、参与者强、容忍度高、问题可人工兜底。一旦放大到整个部门，问题类型骤增，脏数据、异常输入、权限冲突、口径不一致全部冒出来，体验迅速下滑。

第三种是演示价值和真实价值断层。很多 AI 产品特别适合 demo，因为第一次体验会让人有明显惊艳感。但组织采购和持续投入看的是复用率、稳定性、接入成本、维护成本、风险成本。演示阶段觉得很聪明，上线三个月后发现调用成本高、准确率不稳、业务方懒得喂上下文，项目就慢慢凉了。

所以组织推进 AI，不能只看「有没有亮点」，要看「能不能沉淀成机制」。机制包括什么？标准输入模板、可复用技能库、权限体系、日志与审计、评测数据集、人工接管流程、失败降级路径、知识更新责任人。这些东西听着不性感，但没有它们，AI 只是一次性加速器，成不了组织能力。

落地顺序

如果让我给一个技术管理者提建议，我会把落地顺序排成下面这样。

第一步，选高频、低风险、文本密集的场景。别一上来碰核心交易、核心审批、核心生产控制。先从会议纪要、客服辅助、文档问答、需求整理、代码辅助、工单分类、邮件草稿这类场景切入。因为这些地方反馈快，容错高，容易形成正循环。

第二步，先做人机协同，再谈自动化。别急着追求全自动闭环。先把 AI 放到能明显减少机械劳动、但又有人工复核的位置。只要业务方真的感到省时，它就会继续用；只要继续用，你才有真实数据去迭代。

第三步，补上下文工程。很多团队重模型、轻上下文，这是典型的投入错位。实际效果往往更取决于知识源治理、提示词模板、结构化输入、检索策略、输出格式约束、反馈闭环，而不是你是不是又换了一个更贵的模型。

第四步，建立评测。没有评测，所有讨论都会退化成主观感受。要按场景建立问题集，按任务拆指标：准确率、引用命中率、人工修订时长、任务完成率、错误类型分布、拒答率。别追求一个万能分数，要看具体任务有没有带来净收益。

第五步，设计治理。权限、审计、数据隔离、人工接管、敏感信息处理、错误追责，这些要尽早补，不然项目越成功，后面的风险越大。

第六步，再考虑跨系统的 Agent 化。等你已经有稳定的工具接口、清晰的权限模型、成熟的场景评测，再让 AI 跨多个系统串任务。不然就是把一堆不稳定因素绑定在一起。

##= 管理代价

AI 项目有个常见误区：只算模型调用成本，不算管理代价。

真正的成本大头，经常不在 token，而在组织摩擦。

比如知识库项目。模型费用也许不高，但文档清洗谁做、知识责任人是谁、旧制度谁下线、权限怎么打通、错误答案谁负责、用户反馈怎么回流，这些全是管理成本。没人认领，项目一定烂尾。

再比如研发辅助。买个编程助手不贵，但代码规范要不要调整、评审机制要不要变、测试覆盖要不要补、低级任务减少后初级工程师怎么成长、团队怎么防止过度依赖 AI，这些才是长期代价。

还有培训。很多公司一提 AI 培训，第一反应是教大家怎么写 prompt。我觉得这只覆盖了很小一部分。更重要的是教大家怎么定义任务、怎么验证结果、怎么识别幻觉、怎么决定什么时候该信、什么时候该停。组织如果没有这套基本素养，AI 用得越多，错误传播越快。

所以从 CTO 或技术负责人角度看，AI 项目不能只挂在创新部门，必须和流程 owner、系统 owner、数据 owner 绑在一起。谁的业务，谁就要接住治理责任。否则最后很容易演变成技术团队做了一个看起来聪明、实际上没人真正负责的系统。

中层变化

再聊一个很多人不愿意正面说的话题：中层会被 AI 挤压，而且这个挤压不是简单裁员，而是价值重估。

组织里有一部分中层，长期承担的是信息搬运、状态同步、材料润色、向上翻译、向下转述。这类工作在过去很重要，因为组织规模一大，信息协调本身就是价值。AI 进来之后，这部分价值会被削掉很多。

会议纪要自动生成，周报自动整理，跨部门进展自动汇总，方案初稿自动起草，风险点自动抽取。原来要几轮流转才能完成的信息压缩，现在几分钟就能出一版。于是中层如果还停留在「我负责把信息传一传」这个层面，位置会越来越尴尬。

中层未来可能在的地方：定优先级，做冲突裁决，处理例外情况。因为组织最难的从来不是信息传递本身，而是在目标冲突、资源有限、责任交叉的时候拍板。AI 可以把信息准备得更快，但冲突不会因此消失，甚至会因为流转速度提升而更早暴露。

所以中层要升级，不是学几个工具就结束了，而是把自己的工作重心从「搬运和表达」转向「判断和组织」。这一步很多人会不适应，因为过去靠熟练流程获得的安全感会明显下降。

最后

我一直觉得，讨论 AI 对组织的影响，问裁了多少人没有啥实际的意义，因为对企业来说，该裁还是会裁的。于个人来说，如何在这一波浪潮中留下来是最重要的；于企业来说，哪些事情变便宜，哪些错误放更大，哪些能力变稀缺是更重要的。

LLM 作为概率系统，决定了它天生适合进入语言密集、容错较高、反馈较快的工作带。RAG、工具、技能、评测、治理，这些东西的存在，就是为了把一个概率生成器约束进组织需要的确定性边界里。边界画得好，它是杠杆；边界画不好，它就是噪音放大器。

从组织角度看，最大变化不是有没有 AI 岗位，而是岗位之间原有的分工边界在松动和模糊，表达型劳动在贬值（部分），认知型劳动在升值，责任体系必须重新梳理优化。谁先把这套新平衡建立起来，谁就能把 AI 变成持续生产力。

以上。

如果一个团队真的想做 AI-Native 研发组织，第一步是改组织契约：谁可以让 AI 产出代码，谁对代码负责，什么质量底线不能退，什么流程可以砍，什么流程必须更重。

AI 现在太会写代码了，但是这就会导致一个问题：它把「产出代码」这件事的成本做到很低，低到组织里原本那些靠角色边界、流程延迟、评审机制勉强维持的质量平衡，突然失效了。

过去一个 PM 提需求，前端写页面，后端写接口，测试回归，整个链条慢，但慢本身也是一种摩擦力。现在 PM 自己就能把页面跑起来，AI 一下午能写出几十个组件，速度是上去了，但系统开始更脆弱了。

先说 AI-Native 组织不是什么。 AI-Native 组织它不是「让所有人都开始写代码」，也不是「研发岗位会被提示词工程师替代」。

它是把软件组织里的逻辑重排。

以前文档是入口，代码是结果。现在代码变成入口，文档变成派生物。 以前角色按工种切，PM、设计、前端、后端、测试各守一段。现在角色要按责任切： 谁定义业务闭环，谁维护系统护栏，谁提供稳定契约，谁为线上事故买单。

今天我们先聊组织契约，再聊角色重构，然后再把一条研发流水线拆开聊聊。

组织契约

没有组织契约，AI 进团队只会把烂流程放大。

合理预期

在某些 Demo 场景，或者脚本类场景，10 倍是一个合理的预期。 但是对于一个组织来说，10 倍是一个不科学的场景，因为在组织里面，在产品研发过程中，写代码并不是整个生产过程中最耗时的部分。

所以，我们要先摈弃一个幻觉：不要拿 10 倍产出当目标。

AI 在研发组织里的收益区间，我一直认为是 1.5 到 2 倍，高质量前提下的 2 倍。为什么呢？ 因为代码生成速度和有效交付速度不是一回事。AI 能把编码阶段压缩掉一大块时间，但需求澄清、边界判断、异常处理、联调、测试、观测、回滚，这些成本不会自动消失。很多时候还会更高。

如果团队盯着 10 倍，结果一般都一样：PR 数量暴涨，代码体积暴涨，Review 质量下降，线上回归问题增加，半年后开始集中还债。这就是技术债积累速度第一次超过了团队消化速度。

所以合理预期应该写进团队共识里：我们追求的是 2 倍高质量交付，不追求 10 倍低质量代码喷射。

所有权

每个 AI 输出都必须有所有者。

谁发起生成，谁提交 PR，谁 approve merge，这中间可以分层，但最终必须落到一个明确的人身上。这个人要能够面对一句话：如果这段代码挂上你的名字，你愿不愿意负责。要是答案是否定的，这段代码就不该进主干。

这条规则听起来像废话，实际上很多团队做不到。因为 AI 会制造一种错觉：代码好像不是谁写的，是系统吐出来的。人变成了搬运工。只要团队接受这种错觉，质量就开始漂移。一个有所有权的流程大概是这样：

• PR 模板里要求声明 AI 参与范围
• 提交人对业务正确性负责
• Reviewer 对工程质量负责
• 合并人对上线风险负责

责任可以分工，但责任不能悬空。

质量顺序

质量第一，数量第二。

团队如果不显式声明这一点，默认会被 AI 拖向另一个方向：先铺功能，再补治理。这个方向对 demo 团队成立，对正式业务组织通常是灾难。因为 AI 特别擅长快速补齐显性功能，却不擅长主动建立长期维护结构。它会顺着需求走，不会替你守架构。

AI 时代必须把一些以前属于「好习惯」的东西升级为「强制门槛」，也就是我们之前经常强调的规范，流程等等，如测试、监控、CI/CD、单测等等。

• 没有测试，不进主干
• 没有异常处理，不进主干
• 没有监控埋点，不进主干
• 没有 feature flag，不上线
• 不能被 reviewer 解释清楚的代码，不 merge

当代码供给能力暴涨时，质量约束必须同步加码，否则系统会很快从可控变成不可控。

交付代码

传统产品研发里，PRD 是上游，代码是下游。这个模型的问题大家都熟：PRD 经常过期，设计稿和实现偏移，字段定义藏在飞书文档、接口平台、聊天记录和前端代码里，最后没有一个地方是真正可靠的。

AI-Native 组织里：代码作为唯一源，文档从代码反向提取。

从代码出发

现在 PM 借助 Codex、Claude Code（最近又有同事被封号了）、Cursor 这类工具，已经可以生成带交互的页面、Mock 数据、状态流转，很多场景下甚至能直接把核心业务路径跑通。既然这样，就不要再让 PM 先写一份长 PRD，再让研发去猜什么叫「列表为空时的引导态」。让页面先跑起来，再从页面反推需求定义，效率和准确率都更高。

这里有个好处：讨论变得具体了。

以前评审会上大家讨论一句文档描述，脑子里各自渲染不同 UI。现在把页面摆出来，点击路径、字段结构、交互反馈、错误提示都变成可观察对象。对齐成本直线下降。后端也不需要看十页文字说明，只要看这个页面最终需要什么数据结构，就知道接口该怎么供给。

文档反向生成

代码是唯一真相源，不等于不要文档。让文档变成派生物，而且是自动派生物。

流程大概如下：

1. PM 先生成并跑通前端页面，带 Mock 数据
2. AI 从页面代码、组件 props、Mock schema 中逆向提取字段说明、交互流程、状态机描述
3. PM 对这份自动生成的文档做人审
4. 后端按确认后的 JSON Schema 或 TypeScript Interface 实现接口
5. 联调时再根据真实契约让 AI 回写文档

这样处理后，文档不再是一个独立维护成本很高的系统，而是代码的视图层。它可以读给人看，但它的源头来自真实实现，而不是空想。

建议把接口契约标准化为 JSON Schema 或 TypeScript Interface

角色重构

AI-Native 组织可能会有一些角色的变更，但是也可能会裁掉一些角色，因为我们是重写角色边界。如果当前人不合适，或者适应不了，就需要换，否则就会变成打造新组织过程中的阻碍。

很多人讨论这件事喜欢走两个极端。一个极端是「以后人人都是全栈」。另一个极端是「AI 只会替代初级岗位，核心角色不变」。这两个判断都不够准确。

真正发生的变化是：低门槛生产能力下放，专业门槛上移。简单说，更多人能做出东西，但真正有价值的岗位，会向规范制定、质量兜底、系统抽象和复杂问题处理集中。

PM 变成产品工程师

在这个新组织中，变化最大的角色是 PM。

过去 PM 的主要输出物是 PRD、流程图、原型图和口头解释。现在这些东西很多都可以收敛成一个交互可运行的页面。于是 PM 的角色自然往「产品工程师」移动：他不再只描述需求，他直接构造需求的运行形态。

但这里一定要说清楚，PM 写了前端代码，不等于 PM 变成前端工程师。PM 的责任边界还是业务逻辑，不是工程治理。

PM 需要对什么负责：

• 用户路径是否闭环
• 页面状态是否完整
• 文案、条件、分支、空态是否符合业务预期
• Mock 数据结构是否表达真实业务语义
• 生成代码是否遵守团队规定的基础组件和样式约束

PM 不需要对什么负责：

• 全局状态架构是否优雅
• 包体积是否最优
• 路由切换是否引入副作用
• 渲染性能是否达标
• 工程抽象是否可复用

这些后者还是需要专业前端要接住。

问题不是让 PM 承担更多，而是让 PM 把过去停留在文档层的业务表达，直接推进到代码层。这样整个团队拿到的是可执行的业务定义，不是抽象说明书。

设计师变成立法者

设计角色也会变。

当 PM 可以直接借助 AI 生成页面时，设计师如果还把大量时间耗在单页面高保真稿上，投入产出比会快速下降。更有价值的位置，是维护设计系统和机器可消费的样式规范。

设计师的工作重心会变成：

• Design System
• 样式 token
• Visual QA

也就是把颜色、间距、字体、圆角、阴影、组件状态、可访问性规范，从设计稿资产转化成代码和配置资产。比如 Tailwind config、CSS variables、组件规范、图标集、交互动效约束。这些东西一旦进入 AI 生成上下文，PM 或其他角色在生成页面时就不容易跑偏。

说白了，设计师从「画每一张图」转向「制定法律」。立法做得越完整，AI 和 PM 生成的页面越像一个系统，而不是一堆拼起来的截图。

前端变成守门员和重构者

前端是最容易被误读的角色。很多人看到 PM 可以生成页面，就开始下结论：前端会被干掉。实际情况通常相反。前端从体力活里解放出来之后，工程价值反而被放大了。

因为 PM 生成的页面，最常见的问题不是「长得不对」，而是「能跑但脆」。

可能会有大量这类代码：

• 一个组件里塞满请求、状态、渲染、事件处理
• loading、error、empty 三种状态缺两种
• useEffect 依赖写错
• 切页面回来状态丢失
• 没有 abort controller，快速切换导致竞态更新
• 表单校验只校 happy path
• 直接把 mock 字段名写死在视图层，后续接口一改全炸

这些问题不是 PM 能解决的，也不是 AI 自己会主动解决的。前端真正的工作变成三块：

第一块，Review。
不是审美式 review，也不是找缩进。重点看稳定性、边界条件、状态管理、组件职责、可维护性。

第二块，Refactor。
把单文件逻辑拆成组件、hooks、domain service，把团队组件库接上，把状态流收敛，把重复逻辑抽掉。这个过程需要持续迭代，做到团队规范中，给到 PM 生成的上下文中。

第三块，Integration。
把 Mock 替换成真实 API，处理鉴权、缓存、错误回退、重试、并发、路由守卫、埋点、监控。

这个阶段的前端，更像体验架构师和质量守门员。

后端变成能力供应商

后端角色也会收缩：提供稳定、安全、确定性的能力边界。

如果前端页面能更快被构造出来，后端的价值就不在于「接收一份文档然后写 CRUD」，而在于把系统能力以 API 或 Tools 的形式稳定暴露出来。尤其是 AI Agent 场景下，后端实际上在扮演工具供应商。

后端重点关注四类问题：

• 契约稳定性
• 权限与安全
• 幂等性与确定性
• 可观测性与审计

前端、PM、Agent 都可能直接消费这些能力。一旦接口设计漂、错误码混乱、鉴权模型含糊，整个上层生成式开发就会持续返工。AI 会把不稳定接口的问题放大得很明显，因为它极度依赖上下文中的确定性。

流程重构

只讲角色变化不够，需要把研发流程改成适合 AI 的形状。下面是一版比较能落地。

需求具象

第一阶段，需求不再先写成长文档，而是先具象成可运行页面。

PM 独立生成前端

PM 拿着明确业务目标，直接在受控环境里生成页面代码。这个页面至少要包含：

• UI 布局
• 基本交互
• 主要状态流转
• Mock 数据
• 核心校验逻辑
• 空态、错误态、加载态

特别强调最后三项。很多团队让 PM 生成页面，只盯着主流程，结果页面演示时很漂亮，一联调全是坑。空态、错误态、加载态必须在这个阶段一起生成，否则后面每一轮都要补票。

禁止黑盒交付

PM 生成页面这件事，最怕黑盒。也就是只看效果图对不对，不管代码是否落在团队跑道上。

所以团队必须先准备好脚手架和护栏。比如：

• 必须使用指定组件库
• 必须使用既定样式 token
• 必须遵守目录结构
• 必须使用指定的数据获取模式
• 必须输出可运行测试脚本
• 必须带 feature flag 接入点

否则 PM 生成的代码看似完成任务，实际是给前端制造二次工程。

不要让 PM 从空白页面开始提示 AI，而是给一个完整的基础模板，再让 AI 在模板内填充。这个模板的价值极高，它决定了团队是让 AI 在高速公路上开车，还是在野地里乱冲。

契约握手

第二阶段，前端页面和后端能力正式握手。

前端反定义接口

以前是后端先定义接口，前端去适配。现在很多场景可以反过来：前端页面里需要什么数据结构，先自然长出来，再把这份结构抽取成契约。

这里的关键点是「自然长出来」之后，必须立刻标准化。不能停留在 JS 对象字面量和口头描述。最好直接生成：

• JSON Schema
• TypeScript Interface
• 字段说明
• 校验规则
• 错误码预期
• 状态迁移说明

做到这一步，后端看到的就不是「我要一个用户列表接口」，而是一个明确的数据契约：字段、类型、可空性、分页、排序、过滤、异常响应、鉴权要求，全都摆明。

这一步会明显减少沟通损耗。后端可以少看很多无效文档，直接围绕契约开发。

后端提供确定性能力

后端接手后，不建议只机械实现接口。要借这个机会把系统能力做成稳定工具层。

如果团队本身就在做 Agent 或工作流系统，这里更应该统一成 Tools 注册机制，而不是散落一地的临时 API。因为未来调用这些能力的，未必只有前端页面，还有内部 Agent、自动化流程、运营工具、甚至外部合作系统。

后端在这一阶段最常踩的坑有几个：

第一，返回结构不稳定。
今天 success 返回 data，明天又套一层 payload。前端 AI 生成代码时非常怕这个，会反复产生错误适配。

第二，错误码语义不清。
鉴权失败、参数错误、资源不存在、限流、业务冲突全都混成一种 message，联调体验很差。

第三，幂等性缺失。
AI 驱动的调用链经常会重试，如果创建类接口没有幂等控制，很容易重复写入。

第四，缺少审计。
AI 或 PM 直接驱动系统能力时，操作路径更分散，审计日志不能省。

联调瓶颈

真正的瓶颈通常出现在第三阶段：联调、测试、排雷。

到这一步，很多团队会发现：AI 把前半段提速提得很猛，但最后这段并没有自动消失，甚至更重。因为前面生成得越快，后面积累的隐患越多。

Review 的重点

前端 reviewer 在这一阶段要非常克制。不要把 review 做成审美比赛，也不要上来就要求所有代码重写一遍。真正该看的，是那些会直接影响稳定性和维护成本的问题。

我会把检查项固定成一张表，至少覆盖这些内容：

• 异步请求是否有取消机制
• Loading、Empty、Error 状态是否完整
• 表单提交是否防重入
• 路由切换是否会遗留脏状态
• 全局状态有没有被随意污染
• 组件职责是否过载
• 是否接入统一埋点与异常上报
• 是否存在明显重复逻辑
• 是否绕过设计系统直接手写样式
• 是否引入不必要依赖

这样做的好处是，review 从个人经验驱动变成组织标准驱动。AI 时代 PR 量会明显增加，没有标准化检查单，review 质量一定掉。

测试和验收左移

如果团队已经允许 PM 直接交付前端页面，那测试必须同步左移。否则生成速度越快，测试越像消防队。

谁生成页面，谁至少生成对应的 E2E 测试脚本。这个要求不算过分。因为页面交互路径是 PM 最熟的，AI 根据这些路径生成 Playwright 或 Cypress 脚本，命中率通常不低。

在生成代码时，PM 已经完成了第一次的验收。

测试左移不是为了把测试岗位干掉，而是为了把最贴近业务逻辑的验证提前到需求具象阶段。后面的 QA 才能把精力放在组合场景和系统回归上。

发布保险

第四阶段是发布与可观测性。这在 AI-Native 组织里是核心流程。

因为一旦允许更广泛的人群借助 AI 产出代码，线上报错率几乎一定会上升。组织必须提前接受这个现实，然后把监控和发布控制建好。

前端监控

前端监控一定要上，而且要够细。

至少需要这些能力：

• 错误堆栈捕获
• Source map 还原
• 用户会话回放
• 性能指标采集
• 接口失败聚合
• 版本维度对比

像 Sentry、LogRocket 这类工具的价值，在 AI 场景下会更高。因为当报错出现时，你可以把错误堆栈、用户操作轨迹、接口上下文直接喂给 AI，让它先生成修复建议，再由责任人确认。这种协作模式对定位简单问题很有效，尤其是 UI 状态错乱、边界遗漏、类型不匹配这类故障。

但不要误解成「有了 AI 修 bug 就轻松」。线上修复的难点从来不只是生成 patch，而是确认根因、评估影响面、决定是否回滚、验证是否引入新问题。这些仍然要靠工程纪律。

灰度发布

Feature Flag 在这个模式里几乎是必需品。

原因不复杂：当业务页面大量由 PM + AI 参与生成时，组织需要一个足够便宜的试错阀门。否则每次上线都把全量用户暴露在新逻辑下，风险太高。

把 Feature Flag 从「重要功能才加」提升为默认机制。尤其是下面这些场景必须强制：

• 新页面替换旧页面
• 新流程替换旧流程
• 高价值转化路径
• 涉及支付、权限、数据修改的动作
• 首次由非传统研发角色主导产出的功能

灰度期间要明确看哪些指标，不要只看有没有报错。还要看：

• 转化率变化
• 页面停留时长
• 关键按钮点击率
• 表单提交成功率
• 接口失败率
• 用户退出路径

这些数据能帮助团队判断问题究竟出在代码稳定性，还是业务交互本身。

基建先行

前面这些流程能否跑起来，核心在于基建。没有基建，AI-Native 组织会迅速退化成提示词手工作坊。

可以先建三类基础设施。

护栏脚手架

这是第一优先级。

它包括：

• 项目模板
• 目录规范
• 统一组件库
• 设计 token
• 数据获取封装
• 表单与校验约定
• 埋点和监控 SDK
• 测试模板
• CI 预设规则

这套东西是整个组织 Harness 的部分。

Prompt 资产

很多团队低估了 Prompt Library 的价值。实际上，当非工程角色也开始产出代码时，提示词模板本身就是组织资产。

可以把高频场景沉淀成标准模板，比如：

• 列表页生成模板
• 表单页生成模板
• 详情页生成模板
• 多步骤流程模板
• 异常状态模板
• E2E 测试生成模板
• 文档反向提取模板
• 重构任务模板

这些模板不是为了追求文风统一，而是为了把团队积累的工程约束嵌进去。你希望 PM 每次生成页面都自动包含 loading、error、empty、feature flag、埋点、测试入口，那就别靠口头提醒，直接写进模板。

CI/CD 闸门

AI 时代，CI/CD 不能只是跑个 lint。它必须承担质量闸门职责。

最低限度我会要求：

• Lint
• Type check
• Unit test
• E2E smoke test
• Bundle size 检查
• 安全扫描
• 依赖合规检查
• 自动化预览环境
• 灰度发布流水线
• 一键回滚

如果团队现在连这些都没有，先别急着搞 PM 交付前端代码。真把口子放开了，组织会先被事故教育一遍。

常见误区

这是几个最常见的误区。

把 AI 当外包

这是第一类坑。很多团队使用 AI 的方式，本质上和用廉价外包没区别：把需求甩出去，拿回代码，自己不理解也不维护。

这个模式短期可能看起来很省，长期一定出问题。因为系统复杂度没有消失，只是被包进了你看不懂的代码里。等线上出事，你会发现团队没有形成任何新的内生能力。

只提速前半段

第二类坑是，只提速需求到页面这一段，不提速后面的治理、测试、发布、观测。结果就是项目看板前面一片绿，最后两列全堵死。

AI 会把组织瓶颈照得更亮。以前慢慢暴露的问题，现在两周就能堆出来。你不改后半段流程，前半段越快，堵得越严重。

容忍脏代码，也容忍脆弱代码

我能接受 PM 生成的代码不够优雅。变量命名一般、文件拆分普通、抽象层次一般，这些问题都能后续治理。真正不能接受的是脆弱代码：没异常处理、没监控、没测试、状态流断裂、提交会重复、接口失败直接白屏。

脏和脆是两回事。组织必须把这条线划清楚。

用 AI 替代判断

第四类坑最隐蔽。团队开始迷信 AI 给出的架构建议、重构建议、性能建议，仿佛它给出了答案，工程判断就可以省掉。

这是错的。AI 非常适合提供候选方案、加快实现、缩短试错周期，但它不拥有系统上下文，不承担线上责任，也不会为半年后的维护成本买单。架构判断、边界判断、风险判断，最终还是人做。

最后

如果一定要用一句话概括我对 AI-Native 软件研发组织的理解，那就是：把代码生产普遍化，把工程责任集中化。

前者意味着更多角色可以直接参与构造软件。PM 可以交付可运行页面，设计可以把规范直接编码，后端可以把能力做成工具供全组织消费。后者意味着系统质量不能民主化。责任必须更清晰，护栏必须更强，发布必须更克制，观测必须更细。

「PM 交付前端代码」这件事很容易被包装成一个新故事。真落地时，它首先是工程纪律问题，然后才是工具问题。团队如果没有建立所有权，没有把代码当唯一真相源，没有把契约、测试、监控、灰度这些基础设施补齐，这条路大概率会走成一场持续返工。

反过来，如果这些条件具备了，AI 确实会把组织推到一个新阶段。PRD 不再是那份总会过期的文档，代码本身就是需求表达。角色不再围着工种转，而是围着责任和系统边界重组。研发流程不再把大量时间浪费在翻译需求上，而是更早进入真实问题：契约、质量、异常、性能、发布。

这才是我理解的 AI-Native。

以上。

传统 RAG 解决的是「能不能把资料塞给模型」的问题，而知识引擎要解决的是「模型能不能沿着知识结构走到正确答案」的问题。 这两个层级差得很远。前者偏检索，后者开始接近推理。Agent 一旦进入企业场景，尤其是要处理流程、制度、系统配置、投融资关系、风控链路、故障追因这类问题，知识如果还是碎片状态，后面的规划、调用、执行基本都会失真。因为对于模型来说重要的上下文已经是经是不完整的了，自然而然的就开始瞎猜了。

就 AI Agent 知识引擎来说，研发团队常遇到两个坑：

第一，很多团队高估了向量检索的上限。
第二，很多团队又低估了图结构落地的工程代价。

今天我们聊一下AI Agent 的知识引擎如何从碎片检索走到深度推理。

咱们今天主要聊四件事：

• 为什么传统 RAG 在复杂问题上会持续失手
• GraphRAG 到底重塑了什么
• 真正可落地的架构怎么搭
• 当前有哪些新一些的进展

传统短板

很多人第一次做 RAG，体验都挺好。

文档切块，做向量化，进库。用户一问，召回几段文本，拼 Prompt，模型生成答案。对于 FAQ、制度查询、产品说明、接口文档检索，这一套能迅速出结果，性价比很高。

问题在第二阶段才出现：用户不再问单点事实，而是开始问链式问题。

比如：

• 「2019 年收购 A 公司的企业，其母公司在 2021 年的主要投资对象是谁？」
• 「某服务在去年三季度的故障，和两个月前那次容量扩容有没有关联？」
• 「这份上百篇研报里，哪些公司通过共同供应商暴露了同类风险？」

这类问题有一个共同点：答案不在某一个 chunk 里，而是在多个实体、多个时间点、多个文档之间。

传统 RAG 在这里会出现几种典型失效。

关系丢失

向量检索擅长找「语义相近」。它不擅长找「关系成立」。

文档切块以后，文本里的结构被打散了。原文中可能存在很清楚的逻辑链：

• 公司 B 在 2019 年收购 A
• 公司 B 是集团 C 的子公司
• 集团 C 在 2021 年投资了 D

切完块之后，这三个事实可能散落在不同 chunk、不同文档、不同索引分区里。向量检索能不能一次把它们都召回？经常不能。即便召回了，顺序也未必对，相关性分也未必稳定。

这时候模型只能自己「脑补拼图」。一旦有一块没找到，推理链就断。而且，模型也不会老老实实说「证据不够」，它会倾向于补一个看起来像答案的东西出来。这就是很多人嘴里的幻觉。说白了，很多幻觉并不是生成模型凭空发疯，而是检索层先把它带沟里了。

上下文碎片化

RAG 的 chunk 机制本质上是一个工程妥协。

chunk 太小，语义不完整；chunk 太大，embedding 稀释，召回变钝，窗口成本暴涨。滑窗重叠能缓解一点，但解决不了跨章节、跨文档、跨时间的连续推理。

尤其是企业内部知识库，天然不是一本结构优雅的教材，而是一堆：

• PRD
• wiki
• 飞书文档
• 邮件摘要
• 会议纪要
• Jira 评论
• 数据库导出
• 运维记录
• 外部 PDF

这些东西之间本来就没有自然连续性。你再把它们切成块，信息完整性只会进一步恶化。

实体歧义

只靠向量，相同名字的实体很容易串。

一个公司简称可能对应母公司、子公司、事业部；一个人名可能在不同组织里都出现过；产品代号可能跨年份复用。向量模型对这种歧义问题并不稳定，尤其在中文企业数据里，简称、别名、历史命名混在一起，非常常见。

实际项目里，实体歧义一旦没有解决，后面所有链路都白搭。你在检索层把「A 公司」对齐错了，后面再高级的 Agent 规划、工具调用、答案归因，都是建立在错图上。

时间失真

这个问题很多团队前期根本没建模。

企业知识不是静态的。组织关系会变，制度会改版，接口会下线，股权会变更，设备状态有有效期，药品说明有版本，风控规则按月份生效。

传统 RAG 里，一个 chunk 通常只是一段文本。它不天然携带明确的「生效时间」「失效时间」「版本边界」。所以用户一旦问时间敏感问题，系统就容易把不同年份的事实混成一团。

你会看到模型回答得头头是道，但时间轴已经错了。

多跳能力弱

这个问题其实不是模型不会推理，而是检索不给路。

Agent 场景里，很多问题天然是多跳的。要找到答案，系统需要先定位实体，再沿某种关系扩展，再结合时间、置信度、来源做过滤，最后拿到一条可靠路径。传统向量召回没有这个导航能力，它只会不断找「像不像」。

这就是为什么很多团队把模型从一个升级到另一个，效果只提升一点点。瓶颈不在模型本身，而在知识引擎没有结构。

图谱价值

把知识图谱拉进来，改变了检索目标。

传统 RAG 检索的是文本片段。
GraphRAG 检索的是实体、关系、路径、子图，以及这些结构对应的证据。

这个差别很大。

显式关系

知识图谱最核心的价值，是把原来需要模型从文本里隐式猜出来的关系，变成显式结构。

比如：

• 公司 A — 收购 — 公司 B
• 公司 C — 母公司 — 公司 A
• 公司 C — 投资 — 项目 D

一旦这些关系被建出来，系统面对复杂问题时就不需要靠 Prompt 去碰运气，而是可以沿着边去找路径。路径找到后，再把路径上的证据喂给模型组织语言。

这一步非常关键。因为它把「推理」从纯生成问题，变成了「结构检索 + 受约束生成」。

多跳导航

图结构天然支持多跳。

从一个节点出发，系统可以做一跳邻域扩展、两跳路径发现、带类型约束的遍历、带时间过滤的路径搜索。很多复杂问题，其实本质上就是图上的 constrained traversal。

做过故障分析、供应链穿透、组织权限审计的人都知道，真实问题往往不是「找到相似文本」，而是「沿着几类特定关系往外走，直到找到证据链」。

GraphRAG 在这里的优势很直接：它给系统一张路网，而不是一堆散落纸片。

可解释性

只要答案建立在路径之上，归因就容易很多。

传统 RAG 的可解释通常是「我引用了这几段文本」。这不够，因为用户看不出这些片段之间为什么能导出结论。

GraphRAG 则可以给出：

• 命中的核心实体
• 扩展的关系类型
• 经过的中间节点
• 命中路径对应的来源文档
• 时间和版本约束

对于金融、医疗、法务、审计这类场景，是准入门槛。没有路径级证据，系统很难真正进入业务闭环。

异构融合

企业知识天生异构。数据库里有结构化字段，文档里有叙事描述，日志里有事件序列，报表里有指标快照，外部网页里有补充事实。

知识图谱很适合做这一层统一承载。节点和边上可以挂：

• 来源
• 时间戳
• 置信度
• 版本号
• 原文锚点
• 权限标签

这样，后面的 Agent 就不需要分别理解十几种数据形态，它只需要围绕图这个统一语义层工作。

幻觉压制

有人说 GraphRAG 「能消灭幻觉」。做工程的人都知道，不存在这种好事。

更准确地说，GraphRAG 能明显降低两类幻觉：

• 检索证据不足导致的瞎补全
• 实体关系错配导致的错误推断

图结构把推理空间收窄了。其本质上是一个针对知识的 harness 工程。模型不是面对无边界文本海洋自由发挥，而是在一个有限子图上做组织和归纳。再加上路径归因、时间约束、来源过滤，错误空间会被进一步压缩。

架构重构

GraphRAG 要真正落地，分为三段：建图、检索、生成。

建图阶段

图谱质量决定了 GraphRAG 的上限，建图成本决定了它的下限。

如果图是脏的、歧义的、缺时间边界的，后面做再多检索优化都只是补洞。

实体抽取

最基础的是从文本中抽实体、属性、关系。

早期很多方案喜欢直接让 LLM 通读文档抽三元组。这么做效果可以有，但成本极高，而且稳定性不够。文档一长、格式一乱、术语一偏，大模型就开始漂。

建议：实体抽取和关系抽取要拆开看，不要一把梭。

实体层往往更适合用稳定的 IE 管线或者轻量模型先打底，再让 LLM 做补充和歧义修正。原因：

• 实体是高频基础设施，规模大
• 实体错一个，影响整片图
• 实体任务相对更规则，适合工程化优化

尤其在垂直领域，术语标准化比抽取本身更难。医疗、金融、制造、运维，每个领域都有自己的缩写、版本命名、内部代号。这里如果没有术语表和字典体系，后面图融合基本没法看。

关系抽取

关系抽取是建图里最贵、最脆弱的一层。

关系比实体更依赖上下文。它牵涉事件角色、动作方向、时间条件、否定表达、范围限定。比如：

• 「计划收购」
• 「已完成收购」
• 「传闻收购」
• 「终止收购」

如果你都抽成同一种边，图就废了。

所以关系抽取不能只问「有没有关系」，还要问：

• 关系类型是什么
• 方向是什么
• 是否已生效
• 时间区间是什么
• 证据来源在哪里
• 置信度多少

不建议一上来就追求极全的关系本体。项目初期，关系类型设计得太花哨，抽取和维护成本会迅速失控。更稳一些的做法是围绕业务问题反推关系集合，先保核心链路通。

实体对齐

这是最容易被低估的坑。

同一个实体可能有：

• 全称
• 简称
• 英文名
• 别名
• 历史名称
• 内部代号
• 不同系统中的主键

如果没有实体对齐，图上会出现大量看似不同、实际相同的节点。结果是路径断裂、统计失真、召回稀释。

实体对齐需要多种信号联合：

• 名称相似度
• 类型一致性
• 属性重合度
• 上下游关系重合度
• 来源可信度
• 时间重叠情况

仅靠名称相似度会出很多事故。尤其在中文企业环境里，简称重复极多。我见过一个项目把两个不同区域的同名子公司合并成一个节点，导致后面整条供应链分析全错。

时间与版本

这部分如果不做，GraphRAG 只是比 RAG 多了一层图壳。

建议节点和边都尽量具备时间语义，至少要能表达：

• 创建时间
• 生效时间
• 失效时间
• 采集时间
• 数据版本

这样系统才能回答历史状态问题。比如：

• 「2021 年时它是否还是子公司」
• 「这个接口在 3 月版本里是否存在」
• 「某规则在事故发生当日是否已生效」

如果没有时间建模，系统只会返回一个「混合当前状态和历史状态」的伪答案。

质量控制

建图不是 ETL 一次跑完就结束。它需要持续质控。

至少要有几层控制：

• 抽取置信度阈值
• 本体约束校验
• 规则冲突检测
• 抽样人工复核
• 高风险实体白名单校正

比如，公司类型节点不该挂「毕业院校」属性；人员节点不该作为「机房设备」的父实体；时间区间不能出现失效时间早于生效时间。

这些校验就是 harness 工程。

检索阶段

GraphRAG 的检索不是去图库里「搜一下」这么简单。真正有效的检索，至少是一个分层过程。

第一步：实体定位

用户问题进来，先要知道问的是谁、什么对象、哪个版本、哪个时间点。

这一步常见做法是实体链接，必要时混合向量召回。目标是在图里找到核心节点。

这里有两个坑特别常见。

一个是用户表达不规范。简称、口语、错别字、历史名称都可能出现。
另一个是问题里实体不止一个，而且主次关系不清。

所以实体定位通常需要结合：

• NER
• 别名字典
• 向量相似召回
• 类型约束
• 上下文消歧

如果这一步错了，后面全错。

第二步：子图扩展

定位到核心节点后，要决定往外扩多少。

这一步不能粗暴按 N 跳展开。图一旦大起来，邻域爆炸是很快的。尤其企业图谱里很多「高连接度节点」会把子图迅速拉成垃圾堆。

建议的做法是带约束扩展：

• 限关系类型
• 限最大跳数
• 限时间区间
• 限置信度
• 限来源可信等级
• 限节点类型

比如查询收购链路，就优先沿「收购」「母公司」「投资」这类关系走，而不是把「合作」「提及」「共现」都混进来。

第三步：路径发现

复杂问题很多时候不只是看邻居，而是找满足条件的路径。

比如：

• 从 A 出发，找到其收购方，再找到收购方母公司，再找到该母公司在某年的主要投资对象
• 找到某故障对应组件，再向上找到依赖链，再找变更记录，再对齐时间窗口内的容量调整

这类问题，本质上就是受约束路径搜索。图数据库和图算法在这里比纯向量库更像工具。

但有个问题：路径一多，候选会急剧增加。这个时候不能一股脑全喂给模型。要做路径评分和裁剪。

常见评分信号包括：

• 路径长度
• 关系类型优先级
• 时间匹配度
• 节点权威性
• 来源可信度
• 历史问答反馈

第四步：证据序列化

图拿到了，不能直接丢给模型。大多数模型并不擅长原生理解复杂图结构。

要把子图变成模型好消化的证据形式。常见有两种：

• 路径序列化
• 子图摘要

路径序列化适合事实问答。
子图摘要适合全局分析和开放问题。

实际工程里，更推荐结构化证据和原文片段联合输入。因为图给的是骨架，文本给的是细节。只有骨架，没有细节，答案会很硬；只有文本，没有骨架，答案会发散。

生成阶段

GraphRAG 不是检索完就结束。很多项目到这一步依然翻车，因为 Prompt 设计和输出约束没做好。

证据优先

Prompt 里必须明确要求模型优先依据图证据回答，不足时才引用文本补充，证据冲突时按来源等级和时间规则处理。

如果不写这些约束，模型还是会习惯性按语言流畅性组织答案，最后把未经验证的补全混进去。

路径归因

对于高事实性场景，建议回答里至少保留轻量级路径说明。未必要全部展示给用户，但系统内部必须保留。

比如答案背后至少知道：

• 起点实体
• 中间关系
• 终点实体
• 每一步证据来源
• 时间过滤条件

有了这层，后面才能做审计、回放、纠错、反馈学习。

模板化输出

在财务、医疗、法务、运维这些高风险领域，自由生成要尽量少。

更稳的方式是字段化输出，例如：

• 结论
• 证据路径
• 证据来源
• 时间范围
• 置信度
• 不确定点

这样做的缺点是可读性略硬，优点是稳定。企业系统最终是要接流程、接审批、接工单、接风控策略的，格式稳定比文采重要得多。

三类路线

GraphRAG 现在大体有三条实现路线。可以工程投入和适用边界来看：

知识驱动

这一类把图谱作为主检索引擎。问题进来后，系统尽量转成图查询、路径搜索或者约束遍历，文本只做辅助。

这条路线适合：

• 实体和关系相对清晰
• 业务规则稳定
• 可解释性要求高
• 多跳推理占比高

典型场景像金融股权穿透、资产关系分析、故障因果链、药物禁忌关系、组织权限依赖。

优点：精度高、证据链清晰、推理路径稳定。

缺点：图谱不全时脆弱，对建图质量依赖极大。

如果你手里只有一堆杂乱文档，图谱覆盖率还没起来，就直接 all in 知识驱动，项目容易陷进「图不够用，文本又没保留好」的尴尬局面。

索引驱动

这一类不强调图上直接推理，而是把图结构转成索引增强信号。

比如：

• 给 chunk 挂上关联实体、关系标签
• 把子图摘要拼进 chunk 再做向量化
• 用邻居关系信息做 rerank 特征

这条路线改造成本低，适合已有 RAG 系统做增强。很多团队第一阶段其实更适合走这条，而不是直接重做知识底座。

缺点也很实在：图只是辅助特征，没有成为真正的推理空间。所以多跳能力提升有限，可解释性也一般。

混合路线

现在真正跑得稳的，大多是混合型。

简单讲就是双路甚至多路召回：

• 一路走图
• 一路走向量
• 必要时再接关键词或结构化库查询
• 最后统一重排、裁剪、融合

这条路线最像真实世界。因为企业问题本来就不是纯图问题，也不是纯文本问题。很多时候用户一半在问事实链路，一半在问叙事背景。只用一种召回方式，效果往往不稳。

混合路线的问题在于系统复杂度高。链路变长之后，监控、调参、缓存、权限控制、延迟预算都更难。可它依然是现在最主流、也最靠谱的方案。

轻量建图

微软把 GraphRAG 带火，但慢慢大家发现了一个问题：原版重度 GraphRAG 太贵。

用 LLM 通读全量文档，逐段抽实体、关系、摘要，这种方案到真实数据规模经常直接失控。于是轻量化建图开始流行。

实体图思路

轻量路线的核心变化是：不再执着于完整关系抽取，而是先把实体和文档块稳定连起来。

也就是说，先建一个实体图，或者说 relation-light graph：

• 节点是实体、文档、chunk
• 边主要表达提及、共现、引用、归属、锚定等轻关系
• 更复杂的关系留给后续局部推理或按需补抽

高质量关系抽取太贵、太慢、太脆。那就先把高确定性的部分做出来，把知识骨架做起来。

很多场景下，这么做反而更稳。因为实体图能显著改善召回导航，成本又远低于全量三元组图谱。

成本变化

轻量建图通常能把两个指标打下来：

• Token 消耗
• 图谱更新时间

这对中小项目非常关键。一个知识引擎如果更新周期是按天甚至按周算，它对 Agent 的支撑就已经很有限了。现实里的知识是流动的，尤其在运维、客服、风控、投研这些场景，更新速度直接决定答案可信度。

局限

轻量图省成本，但也有边界。

它更适合做「导航增强」和「局部上下文组织」，不适合承担强逻辑推理的全部职责。因为如果关系层太弱，系统最终还是要回文本里做大量补推断。

所以我们一般把轻量图看成一个很好的过渡层，或者作为混合架构中的图底座。

Agent 化检索

GraphRAG 这两年另一个明显趋势，是从固定流水线走向 Agent 化。

传统流程大多是：

用户提问 → 定位实体 → 扩子图 → 生成答案

问题是，复杂问题往往一轮检索拿不全证据。系统需要边查边判断：现在的证据够不够？应该沿哪类边继续走？有没有必要换一个切入实体？要不要回文档补背景？

这时候，GraphRAG 和 Agent 很自然就结合起来了。

查询拆解

复杂问题先拆成子问题，是 Agent 化 GraphRAG 的第一步。

比如：

「2019 年收购 A 公司的企业，其母公司在 2021 年的主要投资对象是谁？」

可以拆成：

1. 谁在 2019 年收购了 A
2. 该收购方的母公司是谁
3. 该母公司在 2021 年的主要投资对象有哪些
4. 哪个对象符合「主要投资对象」定义

拆解后的每一步都更适合图查询和约束检索。

迭代探索

Agent 可以根据中间结果决定下一步动作：

• 命中实体不确定，先做消歧
• 路径证据不足，扩大时间窗口
• 图证据不全，补文本检索
• 文本冲突，回图里查来源优先级

这比一条固定链路强很多。因为真实问题不会永远按设计者预想的路径走。

风险

Agent 化一听就很高级，但工程上有几个明显的问题：

• 延迟增加
• token 消耗增加
• 调试复杂度上升
• 失败路径变多

如果没有严密的步骤预算和停止条件，Agent 会在图里越走越远，最后拖垮时延和成本。

所以 Agent 化 GraphRAG 要有明确的控制策略：

• 最大迭代轮数
• 最大扩展跳数
• 最大证据数
• 最大 token 预算
• 终止阈值

没有这些约束，系统会变成一个会自主发散的检索器。

强化学习

2025 到 2026 年，另一个值得关注的方向是把强化学习或者类似 reward-guided 策略引进图检索过程。

这个方向的核心问题是：子图应该扩到哪里停？哪条边值得继续走？

以前这类问题多靠规则和启发式。比如限制两跳、限制 topN 邻居、按关系优先级排序。够用，但不够细。

强化学习的吸引力在于，它试图让检索器学会一件事：在有限上下文预算下，优先收集对答案最有价值的证据。

为什么有价值

GraphRAG 很容易出现一个悖论：

• 扩得太少，证据不够，答不出来
• 扩得太多，噪声暴涨，模型反而更容易错

最优点其实是一个动态平衡，而且和问题类型、图谱密度、时间约束都相关。静态规则很难适配所有情况。

落地现实

这个方向我认为在部分场景是一个比较不错的解。

原因很简单。强化学习提升的是「策略细节」，前提是你的图已经比较干净，检索反馈链路也能闭合。如果底层图谱质量一般，奖励模型再聪明也学不到稳定策略。

所以在工程优先级上，我会把它排在：

1. 实体对齐
2. 时间建模
3. 混合召回
4. 路径裁剪
5. 再考虑 RL 优化

很多团队喜欢直接追最新论文方向，结果底座没打稳，投入产出很差。

动态建图

静态全量图谱还有一个问题：更新慢。

数据一旦高频变化，整库重建非常重，增量融合也复杂。于是最近很实用的一条路是查询驱动的动态局部建图。

思路

先用向量检索或关键词检索，快速圈出和问题强相关的一小批文档或 chunk。然后只针对这部分数据，在内存里临时构建一个局部图，用来做当前问题的推理。

这样做的好处很明显：

• 不需要维护一个永远完整的全局大图
• 对高频更新数据更友好
• 构建成本和时延更可控
• 对冷门知识不用提前付建图成本

适用场景

这条路线特别适合：

• 数据更新快
• 查询分布长尾
• 很多知识只会被偶尔问到
• 无法接受全量图谱重构成本

比如运维告警分析、实时舆情、工单流、交易异常调查。

局限

动态建图的问题也很明显：它的全局视角弱。

如果问题本身需要跨全库的大结构理解，比如全局主题分布、长期模式汇总、跨社区关联，局部动态图就不够用了。所以它更像实时推理层，不是全局知识层的完全替代品。

多模态图

GraphRAG 继续演进，节点已经不再局限于文本实体。

很多真实场景里，关键证据来自图像、图表、表格、时序信号。把这些都挂进图里，才可能支撑更完整的 Agent 推理。

例如医疗场景里：

• 症状描述是文本节点
• 检查指标是结构化节点
• 影像特征是图像节点
• 治疗方案是流程节点

如果这些数据还分散在不同系统里，Agent 再强也只能在局部瞎猜。多模态图的价值，在于把这些证据接成可遍历的语义网络。

不过这块别急着神化。多模态 GraphRAG 落地难度明显高于文本图谱，主要难点有三类：

• 跨模态对齐难
• 证据置信度难统一
• 存储与检索链路更复杂

所以大多数团队短期内更现实的做法，是先把表格和结构化字段接进来，再逐步引入图像等模态。

超图方向

传统的知识图谱仅支持二元关系（即一条边连接两个节点，如 实体A → 关系 → 实体B）。然而在真实复杂场景中，事实往往是多维度的。

比如：

• 三家公司共同参与某项目
• 一笔交易涉及买方、卖方、标的、通道、时间、地区
• 一个法律案件涉及原告、被告、法条、法院、时间节点

• 超图与超边（Hypergraph & Hyperedges）：超图允许单条“超边”连接任意数量的实体/节点。例如在医学场景中，描述“某症状”的发生可能涉及“患者、医生、检查手段、特定药物和治疗结果”。
• 低阶与高阶关联：通过超图，系统能同时无损存储成对的“低阶关联”与包含多个实体的“高阶关联”，从根本上减少信息压缩带来的损失。

这个方向在金融穿透、案件分析、复杂项目协作里很有吸引力。因为它能更自然地表达群体事件和多方关系。

但说实话，超图现在离大规模工程标配还有距离。核心原因不是理念不对，而是生态、工具链、调试经验都还不够成熟。一般团队现在没必要急着上，除非业务场景确实被二元关系表达卡住了。

落地取舍

那么 团队到底该怎么选？

只做传统 RAG 就够的情况

如果你的问题大多是：

• 单文档问答
• FAQ 查询
• 产品知识助手
• 代码片段召回
• 对多跳推理要求不高

那就别急着上图。把 chunk、embedding、rerank、query rewrite、metadata filter、citation 做好，收益通常更高。

应该上轻量 GraphRAG 的情况

如果已经出现这些信号：

• 同一个问题答案分散在多个文档
• 实体名称混乱、简称多
• 用户经常追问上下游关系
• 向量召回结果看起来相关，答案却老是不对
• 需要更稳定的引用与归因

那我建议先上轻量图。先做实体层和文档锚定层，不要一口气建满关系宇宙。

应该上重度 GraphRAG 的情况

如果业务本身就是关系驱动的：

• 金融穿透
• 医疗知识网络
• 风控依赖链
• 故障根因传播
• 供应链关联追踪
• 组织权限审计

那重度图谱是值得的。因为这里的问题本质上就是图问题，用纯文本方案长期只能堆补丁。

Agent 化和 RL 什么时候考虑

当且仅当你已经满足这些条件时再往上走：

• 图谱基础质量稳定
• 问题复杂度确实需要多轮探索
• 现有检索链路可观测、可回放
• 成本和延迟预算允许

否则，先把基础检索做好，比上复杂策略更值。

小结

图结构是检索的 harness 工程。

向量检索还是底座，图结构正在变成高阶能力的分水岭。

没有向量，系统对模糊语义和开放文本会很迟钝。
没有图，系统对关系、路径、时间、一致性会很脆弱。

未来成熟的 Agent 知识引擎，大概率都不是单一路线，而是分层组合：

• 向量层负责广覆盖召回
• 图层负责关系组织与多跳导航
• 结构化查询层负责精确过滤
• Agent 层负责查询拆解与迭代探索
• 生成层负责受约束表达与归因输出

说到底，知识引擎这件事，已经从「找资料」变成「构造可推理的证据空间」。

GraphRAG 不是给 RAG 多加一个数据库，也不是给模型多喂一点上下文。它把原来松散、偶然、靠模型自行拼接的知识，重组成了一张可以遍历、可以约束、可以回放的网络。

对 AI Agent 来说，对于 AI Agent 的上下文构建来说，这是关键的一步。

因为 Agent 一旦开始承担任务，它需要的就不再是几个看起来相关的文本块，而是一条能走通、能解释、能复核的知识路径。

以上。

我们在落地 Agent 时面临的核心矛盾，是大模型的概率生成机制与工程系统所需的绝对确定性存在天然冲突。要获取大规模、可维护且值得信赖的代码，必须在系统外围构建 Harness。Harness 的本质是将不确定性转化为确定性。

提高信任度和可靠性需要极度压缩 Agent 的解决方案空间。我们必须放弃让模型「生成任何内容」的灵活性，转而采用包含大量技术细节的提示、规则和框架。特定的架构模式、强制执行的边界以及标准化的结构，构成了这套护栏的物理基础。

当前越来越多的团队在持续快速的产生代码，而这些演示很好看，当真的进入整个软件生命周期中，就会产生混乱，当越来越多的人随着时间的推移在仓库中堆砌代码，组织就开始堆人进行 review、反复返工，最后 AI 的吞吐量被人类注意力卡死，表面上用了 Agent，实际产能没上去，维护成本还更高。

当然，这是一种结果，也有人在过程中不停的构建基建，做 Harness 工程，整个代码不再是无序的扩张。从这个逻辑来讲，harness 的作用是把大模型输出从概率事件压回工程确定性的系统设计。

Agent 的 Harness

harness 是什么

很多人把 harness 比作一个操作系统，模型是 CPU，但我觉得并不是。

如果模型真的是 CPU，那它接收指令后的执行结果应该是绝对严格且可预测的；但大模型本质上是一个概率引擎，它在潜空间里做的是模式匹配与概率生成。因此，harness 并不是像操作系统那样去调度底层硬件资源或分配内存，它更像是一套概率过滤器和对齐机制。它依靠纯粹的工程手段，把模型那种发散的、充满不确定性的「创造力」或「幻觉」，强行压缩进一条狭窄、严谨且符合人类预期的流水线里。

这种工程逻辑在实践中，体现为无处不在的防御性设计和反馈闭环。当模型吐出一串代码或一个决策时，harness 并不负责直接「运行」它，而是负责「质检」和「纠偏」。它通过静态检查、架构规则扫描、自动化测试和沙箱验证，把模型给出的「大概率正确」转化为工程上非黑即白的「通过或驳回」。正是这种让概率不断撞击确定性规则的过程，才使得最终沉淀到代码库里的产物是安全、可控且符合系统长期利益的。

harness 解决确定性问题的终极目的，是为了在系统中建立无需人工干预的信任，从而真正释放 AI 的吞吐量。如果没有这套逻辑，模型生成的代码越多，人类审查的负担就越重，整个组织的运转速度依然会被人类的注意力瓶颈卡死。

Martin Fowler 的博客中发表了 Thoughtworks 的技术专家的一篇文章，将 OpenAI 文章中所描述的 harness 分为三个方面：

上下文工程

上下文工程需要做到动态与静态的交织

单纯依赖超长 Prompt 无法解决复杂工程问题。上下文工程的核心在于构建代码库中持续增强的知识库，并打通 Agent 对动态上下文的访问路径。

静态知识库定义了系统的基础法则。我们将领域模型、API 契约和历史架构决策文档化，作为 Agent 初始化的基线上下文。动态上下文决定了 Agent 在运行时的决策质量。系统需要将实时的可观测性数据、测试覆盖率报告甚至浏览器导航状态，实时注入到 Agent 的工作流中。缺乏动态上下文的 Agent 就像蒙眼狂奔的打字机，产出的代码在语法上完美，在逻辑上完全脱离系统现状。

架构约束

架构约束是确定性的防线。

完全依赖 LLM 进行自我反思和代码审查，在生产环境中极度危险。架构约束必须由确定性的自定义代码检查器和结构测试来强制执行。

我们通过静态分析工具拦截不合规的依赖调用，利用 AST（抽象语法树）解析确保代码分层符合规范。当 Agent 试图在 UI 层直接发起数据库连接时，确定性的检查器会立即阻断该行为，并将具体的错误堆栈和修复路径作为反馈输入给 Agent。这种混合架构确保了系统的底线由死板的规则守卫，Agent 的创造力被严格限制在安全的沙盒内。

垃圾回收

垃圾回收主要是用于对抗代码熵增。

完全自主的智能体引入了代码库衰败的新问题。Agent 会精准且不知疲倦地复现代码仓库中已存在的模式，包含那些不均衡或不够理想的遗留设计。随着时间的推移，这种行为不可避免地导致系统架构漂移。

最初，人类开发者试图手动处理这个问题。团队过去每周五要花费 20% 的时间清理「AI 残渣」。这种依赖人力的做法毫无可扩展性。

我们将资深工程师的主观品味转化为机械规则，提炼为「黄金原则」并直接编码到代码仓库中，建立了一个循环清理流程。我们强制要求使用共享的实用程序包，禁止手工编写零散的辅助工具，确保不变式集中管理。我们严禁使用猜测性的数据探测，强制验证边界或依赖类型化的 SDK，防止 Agent 基于虚幻的结构进行构建。

系统定期运行一组后台 Agent 任务，扫描代码库中的偏差、更新质量等级，并发起有针对性的重构 Pull Request。这些 PR 大多可以在一分钟内完成审查并自动合并。这套机制的功能等同于内存管理中的垃圾回收。技术债务如同高息贷款，通过高频的微小重构不断偿还，远胜过让债务累积到系统崩溃。人类的架构品味一旦被捕获并规则化，就会无情地应用于每一行代码，每天自动发现并消灭不良模式。

AI Agent Harness 的工程化落地

从几个流行的框架来看，主要是从流程强化、规格沉淀、任务编排等逻辑上来做事情。

将这些逻辑拆开可以分为四个维度：

上下文工程

上下文工程主要是在规范层解决问题，其主要解决的「规则文件失控」的问题，实现规格沉淀与对齐，以及上下文工程的可控。

之前，我们习惯把所有规范塞进类似于单个 .cursorrules 文件，导致 AI 上下文过载且容易忽略细节。这一层落地的第一步是建立结构化、按需加载的规范体系。主要做到如下的点：

• 规范模块化：将系统架构、数据库规范、错误处理等拆分为独立的结构化文档。
• 按需检索：AI 不需要每次都通读所有规范，而是根据当前所处的任务阶段，动态检索并加载所需的上下文。
• 任务记忆隔离：为每个独立任务建立物理隔离的工作区和日志。AI 每次开启新会话时，只读取当前任务的精确记忆，既解决了“跨会话失忆”，又屏蔽了无关信息的干扰。

以 Trellis 框架为例，Trellis 摒弃了单一庞大的全局提示词文件，而是采用 spec/ 目录将规范模块化（如拆分为 database-guidelines.md）。在执行任务时，它利用 tasks/ 目录下的 JSONL 配置文件，让 Agent 动态检索并按需加载上下文。

架构约束

架构约束的核心逻辑：用代码约束代码，实现闭环自愈。 口头约定或纯文本规范在 AI 面前是脆弱的，它极易为了「跑通逻辑」而破坏架构分层。

• 规则代码化：将核心的架构依赖规则（例如“前端组件严禁直接调用数据库”）编写为静态分析脚本或自定义 Linter。
• 带解释的强阻断：在代码提交或验证阶段强制执行这些拦截器。关键在于，报错信息不能仅仅是「检查失败」，必须输出高度结构化的指导：明确告诉 AI“为什么违反了规则”以及“正确的做法是什么”。
• 自动修复：AI 读取到结构化的报错指导后，能够自动理解并修正代码，形成无需人类介入的自愈闭环。

反馈循环

核心逻辑：降噪处理，防范死循环。 LLM 的注意力会被长篇大论的日志（如几千行的覆盖率输出）稀释注意力，从而忽略真正致命的错误。 因此我们需要做到：

• 零输出原则：改造验证脚本。如果测试通过，脚本应保持完全沉默；如果失败，只输出精简的错误堆栈和失败原因。
• 强制验收清单：在 AI 试图标记任务「已完成」之前，系统应强制拦截，要求其对照需求文档逐项确认边界条件。
• 防死循环干预：设定重试阈值。如果 AI 对同一文件连续修改多次且测试依然失败，系统应主动中断并强制其回滚代码、重新审视需求，防止 AI 陷入无效的「幻觉修 Bug」循环。

熵管理

熵管理主要是阻断「坏模式」的指数级扩散

核心逻辑：快速偿还技术债。 AI 复制坏代码的速度是指数级的。一旦允许一个临时的妥协方案合入主分支，AI 会在极短时间内将其复制到整个代码库。

• 高频垃圾收集：彻底放弃“集中清技术债”的传统做法。每天必须安排固定时间，专门 Review AI 生成的代码（人工或 AI 自动），及时识别新引入的坏模式。
• 规范资产的动态演进：一旦发现坏模式，立即让 AI 深度分析根因，并自动将正确的防范规则更新到规范库中。
• 团队级免疫：由于规范库与代码同源管理（存在于 Git 仓库中），当这段新规则被提交后，团队其他成员拉取代码时，他们的 AI 助手就能立刻“学会”这个新技能。这把偿还技术债的动作，变成了每天自动化、可积累的系统进化。

以 Cursor 为例，可以更新 Team Rules

组织级 Harness

聊完 Agent 的 Harness，再聊一下组织的。

人的角色已经变了

大家都知道康威定律，简单来说就是：设计系统的组织，其产生的设计受限于这些组织的沟通结构。

而系统设计到最后，也一定会遇到一个问题：谁来定义规则，谁来解释例外，谁来承担后果。

以前的软件开发分工相对稳定。PM 写需求，设计出稿，前后端分别实现，测试验证，运维发布。大家各自占一段链路，边界虽然有摩擦，但总体清楚。

AI 进来以后，边界开始模糊。

PM 已经可以直接产出前端原型，很多时候产出的还不是静态图，而是真能跑的页面代码。设计师也不再只是给稿子，很多交互和组件约束可以直接沉淀成生成资产。前端工程师花在纯页面搭建上的时间下降，开始更多介入状态管理、交互抽象、可维护性收拢。后端和算法也更早被拉进来，因为很多 AI 生成的原型一开始就会碰到真实数据和能力边界。

这是现在很多团队正在进行的转型。

如果组织还按旧的分工运转，Agent 会把协作缝隙快速放大。

组织级 Harness 要管什么

我理解的组织级 harness，重点在三件事：

1. 定义新的协作接口
2. 重新分配注意力
3. 把责任从「谁写了代码」改成「谁定义了系统」

协作接口要前移

以前很多问题可以留到开发阶段再对齐。现在不行。

因为 PM 通过 AI 已经能直接产出前端代码，需求不再是文字说明，而可能是一个可交互原型；设计规范也不再只是 Figma 标注，而是可以半自动映射到组件约束；后端接口能力如果不提前讲清楚，前面的生成很容易一路偏到错误方向。

所以组织里的评审必须前移，重点也得改。

过去的需求评审，很多时候在讨论功能要不要做。现在要多讨论三件事：

• 验收标准到底是什么
• 哪些边界不能突破
• 哪些部分允许先用原型推进，哪些必须工程化收拢后才能上线

这几个东西不提前定，后面会出现一个很常见的问题：原型阶段看起来进展飞快，进入工程化后才发现返工巨大。

注意力要重新分配

我现在越来越少鼓励资深工程师花时间逐行抠低风险代码。

这不是说 review 不重要，而是注意力要贵着用。

在 Agent 环境里，重要的工作变成了：

• 定义验收标准
• 设计架构边界
• 提炼黄金原则
• 识别系统性失败信号
• 决定哪些异常值得阻塞主流程
• 审核高风险改动和高影响面重构

反过来，低风险、重复性、局部性的东西，应该尽量交给自动化校验和后台清理任务。

如果一个组织还在让最贵的人力去看大批格式化差异、小工具改名、重复样板代码，那 harness 基本等于没有。

责任归属要重写

在 AI-Native 组织里，谁对结果负责？

PM 产出了页面代码，前端做了工程化收拢，Agent 自动补了测试，清理 Agent 又改了一轮共享工具。最后线上出问题，算谁的？

如果这个问题没有明确答案，团队会很快进入防御状态。每个人都怕接 AI 产出的锅，于是流程开始重新变重，所有人都试图把责任往后传。

所以组织级 harness 一定要明确责任模型。

可以按三层分：

• 需求责任：谁定义了目标与验收标准，谁负责需求正确性
• 架构责任：谁定义了边界、模式和约束，谁负责系统一致性
• 发布责任：谁决定进入生产环境，谁负责风险接受

不要再执着于「谁手写了这行代码」。就像团队管理一样，最后拍板的人担责。

可落地的 AI-Native 研发流程

以下为我们当前在跑的流程：

需求生成

第一步由 PM 主导，但交付物不再只是 PRD，而是带验收标准的可运行原型。

但是，原型代码不等于可直接上线代码。它的价值是澄清需求、暴露分歧、提前感知交互复杂度。

所以 PM 可以生成，但不能默认拥有工程决策权。最终所有的代码都需要前端工程师构建的工具链条，以及 AI 和人工的审核及合入。

联合评审

第二步是全员参与的需求评审与架构设计。设计、前端、后端、算法都要尽早介入。

这个阶段重点不是抠实现细节，而是确定：

• 用户路径是否成立
• 数据流怎么走
• 状态边界怎么划
• 哪些能力用现有服务承接
• 哪些模块需要新增抽象
• 风险点在哪
• 验收怎么自动化

这这一步的产出结构化进仓库，因为后面它会直接成为 Agent 的约束输入。

工程收拢

第三步是工程化整合。这个阶段前端、后端、算法开始把前面的原型和需求收敛进正式系统。

这里 Agent 会大量参与，但人类不能退出。重点工作包括：

• 把原型重构进现有组件和模块体系
• 校正状态管理、错误处理、埋点、权限、监控
• 对接真实接口和算法能力
• 补齐类型、边界验证和回归测试
• 处理跨模块影响面

这一段最考验 harness，因为原型代码最容易带着局部最优、全局失真、风格漂移的问题冲进主仓。

自动验证与灰度

最后一步是自动化测试、灰度发布和反馈回收。

这一步先由专门的工程团队来负责，加入部分的 AI 成分，固化系统。

从 Agent 到组织，真正难的是控制系统

很多人以为 AI 落地的核心挑战在模型能力、成本或者工具接入。我现在看，最大挑战更集中在三个词：环境、反馈回路、控制系统。

环境决定 Agent 看到了什么、能做什么、不能做什么。

反馈回路决定错误会被放大，还是会被系统吸收成改进信号。

控制系统决定生成能力增长之后，组织是变得更稳，还是更乱。

这三个东西做不好，模型再强也只是更快地产生问题。

做得好，哪怕模型能力没到最顶尖，系统一样能稳定进化。因为工程上真正稀缺的，从来不是一次惊艳输出，而是长期重复地产出靠谱结果。

组织的 AI-Native 化

组织的 AI-Native 化也是慢慢进货，逐步推进的，先从小范围试起，再根据结果不断调整规则和流程。并且各家有各家的风格和气质。

第一，选一条链路打透。不要一开始就全组织铺开。先找一个协作关系清楚、反馈周期短、风险相对可控的场景，比如中后台、运营工具、内部系统，或者低风险服务改造。重点不是让 AI 多写代码，而是先验证：信息怎么给、边界怎么定、错误怎么发现、问题怎么清理。

第二，先改规则，再谈效率。很多团队一上来就问产能能提升多少，但更重要的是：规则有没有沉淀下来，错误能不能回流，坏模式能不能及时发现并清掉。如果这些没做好，所谓提效往往只是把问题推后，甚至把混乱放大。

第三，把人的位置往上移。资深工程师要逐渐从大量写代码，转向定规则、画边界、看反馈；技术管理者要从盯人和排期，转向设计流程、分层风险、明确责任；产品可以更早参与原型，但不能越过工程判断。

组织真正变成 AI-Native，不是因为每个人都在用 Agent，而是协作方式已经围绕 Agent 被重新设计过。

模型当然重要，但不是决定性因素。真正拉开差距的，是谁先意识到：Agent 不是一个更快的开发者，而是一个高吞吐的生产单元。它会放大环境本身。规则清楚，它就放大规则；流程混乱，它就放大混乱。

所以到最后，harness 这件事谈的根本不只是 AI。

谈的是工程纪律怎么重新编码。

谈的是组织协作怎么重新布线。

谈的是我们怎么把概率生成系统，放进一个仍然要求长期维护、长期演进、长期负责的软件世界。

这是我理解的「从 Agent 到组织」。

以上。

如果 AI 能像人一样，随着时间，经验，反馈不断学习，会发生什么？

我们现在常用的 Agent，不管是豆包，还是编程用的 Cursor，本质是还是一次性对话工程，你问一句，它答一句，或者执行完一堆任务，任务结束后不会成长。

如果能成长呢？这将会是不一样的世界。

这也是今年硅谷比较热门的方向。

为什么是这个方向：

1. 人性，人天生懒惰，公司逐利
2. 成本，自动化的 Agent 比 Chat AI 消耗的成本高出数个数量级，而自己进化的 Agent 所消耗的 token 又比一般的自动化的 agent 要高出多个数量级
3. 上下文更长、模型更大、工具更多，这些路线都还有效，但边际收益已经没有前几年那么夸张。当其它维度进入瓶颈的时候，时间永远是可以考虑的重要维度，

自我进化不是「长期记忆」，而是 Agent 依据自身交互情况、任务反馈或环境信号，对上下文、记忆、技能、工作流甚至模型参数进行持续更新。这些更新会直接干预未来的任务执行。

通过不断调整大模型和 harness 的边界，在静态世界里不断进化，模型能够能够越来越熟悉环境工具记忆等

任何演进路径都必须压在评估、版本、回滚、权限与供应链治理的基础之上。

自我进化用一句来讲，大概是这样：

真实任务里的经验，怎么变成下一次任务可复用、可验证、可治理的能力。

拆解一下，可以分为四层或者说四种可实现路径：

1. 上下文进化：将执行经验、用户偏好或环境约束写回本地记忆文件、会话索引或技能目录，在下一次任务触发时通过检索提取并拼接入上下文。
2. 技能进化：把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号，自动修改技能代码，在测试集中跑通后覆盖老版本，失败则触发版本回滚。
3. 群体智能进化：多个 Agent、多台机器、多个用户的本地经验接入云端共享层。系统在服务端完成轨迹去重、冲突合并、安全脱敏与质量验证，最后将提纯后的技能或记忆分发回所有终端。
4. 策略进化：将真实的交互轨迹与成败反馈收集起来，直接修改 Agent 的核心调度代码、工作流拓扑，甚至转化为强化学习（RL）的标量奖励来更新大模型的底层参数。

从工程落地的角度来说，上下文闭环和技能闭环是不错的起始点，也是能快速落地，快速带来结果的点。

这两层改动的基本都是文本资产，容易审计，且故障可控，回滚成本低。如果实现群体闭环或策略闭环，就会多出很多数据脱敏，权限控制等等问题。

上下文进化

上下文进化是指让 Agent 在自己的主循环里，将执行经验、用户偏好或环境约束写进以后还能用到的上下文资产。

典型的上下文资产包括：

• 跨会话记忆
• 会话检索
• 用户画像
• 项目级上下文
• 技能目录的动态装载
• 失败后的反思记录

优点：轻、快、容易落地。

缺点：如果底层模型本身不够强，光靠上下文很难突破上限；如果没有治理，错误经验会稳定污染后续行为。

以 Hermes Agent 为例，它将持久记忆（MEMORY.md / USER.md）、跨会话检索（SQLite + FTS5）和技能创建塞进同一个对话主循环。

工程实现上，Hermes 走的是一条贴紧主循环的轻量闭环。用户下发任务，Agent 经由消息网关调用终端工具。执行反馈与用户纠正产生分叉，一部分写入策展记忆，一部分沉淀为 Skills。当新任务到来，系统通过 session_search 将历史记忆与技能一并汇入下一轮上下文。

上下文进化解决的问题是Agent 的「金鱼记忆」与重复试错成本。在早期开发中，大模型每次新建会话都会丢失之前的上下文。昨天刚通过多轮对话教会它如何绕过内网的 SSL 证书校验，今天遇到同样的报错，它依然会从零开始盲目重试。上下文进化通过持久化存储（如 SQLite 配合 FTS5 全文检索），让 Agent 在行动前先查阅历史成功路径，直接跳过无效的探索阶段。

适用于单兵作战的个人助手、轻量级代码副驾、日常办公辅助。只要底层大模型的推理能力在线，且任务经验不需要跨团队、跨设备共享，这是投入产出比最高的一层。它不需要复杂的评测沙箱，几百行代码就能让单体 Agent 的可用性产生质变。

技能进化

上下文闭环再往前一步，就是把经验沉淀成可复用技能。

当经验开始重复出现，必须将其从松散的记忆层提升到结构化的技能层。把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号，自动修改技能代码，在测试集中跑通后覆盖老版本，失败则触发版本回滚。

在 Agent Skills 生态里，SKILL.md 充当了 Agent 的程序性记忆，定义了触发时机、执行脚本、环境约束和异常处理逻辑。

SKILL.md 这一类开放技能格式，是这波 Agent 工程里比较实用的中间层，它有如下的特点：

• 比记忆更结构化
• 比代码改动更轻
• 比参数训练更便宜
• 可迁移、可 diff、可版本化、可回滚

所以当我们发现某类经验开始重复出现，就不应该继续把它留在记忆层，而应该上升成技能资产。

Darwin Skill 把 SKILL.md 当作可评测、可回滚的资产。

Hermes Agent 的技能系统不是静态文档库，它允许 agent 自己创建、编辑、补丁、删文件、写附属文件。核心工具是 skill_manage。[skill_manager_tool.py]

Hermes Agent 的技能进化，并不完全依赖用户主动说「把这个存成技能」。

它有两层自动复盘机制。

第一层是 nudge。memory 按用户回合数触发，skills 按工具迭代次数触发。达到阈值以后，系统会在主任务完成后，后台 fork 一个 review agent，让它复查当前会话，看有没有东西值得落 memory 或 patch/create skill。[run_agent.py] run_agent.py#L2448-L2547 [run_agent.py] run_agent.py#L11586-L11612

第二层是 guidance。系统提示里直接写明：

• 复杂任务、踩坑任务、发现可复用流程，要考虑存技能
• 技能用着发现过时或不完整，要立刻 patch

它已经把「技能进化」从人工运营动作，拉进了 agent 自己的工作流。系统不再等人整理文档，而是把复盘变成运行时行为。

但这种触发还是偏软。nudge 只是提醒，review agent 还是模型自己判断。只靠提示词和后台复盘，技能库后面大概率会出现三类问题：

• 有价值流程没被沉淀
• 沉淀下来的技能版本缺少来源和上下文
• 技能被 patch 多次以后，质量开始飘

技能进化解决的问题是纯文本记忆的非结构化缺陷。当任务复杂度上升，大模型在处理几万字的自然语言排错记录时极易丢失细节，甚至产生幻觉。复杂的业务需要确定的执行路径。人工维护这些包含几十个步骤的 SOP（标准作业程序）脚本成本极高，且极易因外部 API 的微小变动而全盘失效。技能进化将脆弱的静态脚本转化为能够依据报错信息自我修复的动态资产。

其适用于垂直领域的自动化流水线、运维巡检、复杂数据清洗。当业务要求 Agent 严格遵循既定流程操作，且操作环境（如第三方接口、依赖库版本）会频繁发生变化时，技能进化是维持系统长期稳定运行的唯一解。

群体智能进化

当你有多个 Agent、多台机器、多个用户时，单机技能闭环就不够了。

因为最大浪费会变成另一件事：
同一个坑被不同实例反复踩。

这时候我们就需要一个共享层，把个人经验抽出来，变成全体可复用资产。

这就是群体闭环要解决的问题。

它的收益大，但治理也复杂。因为共享意味着：

• 权限问题
• 隐私问题
• 脱敏问题
• 质量门控问题

等等

Ultron 将散落在各次会话里的经验蒸馏成群体知识，提供 Memory Hub、Skill Hub 和 Harness Hub。

Memory Hub 实现了 HOT / WARM / COLD 分层存储。系统根据命中次数进行再平衡，引入时间指数热度衰减公式 hotness = exp(-α × days)。未经衰减处理的记忆库是一场灾难，Agent 会频繁召回半年前已经废弃的内部 API 规范。

数据入库前，系统通过 Presidio 进行中英 PII（个人身份信息）检测与脱敏。这是企业级落地的底线。一旦某个 Agent 将包含真实客户手机号的排错日志写入群体记忆，整个系统的合规风险将彻底失控。

Skill Hub 负责将进入 HOT 层的记忆结晶为多步工作流技能。Harness Hub 则将人设、记忆、技能打包为蓝图，支持一键导入。这种设计抹平了多实例部署的知识水位差。

其主要解决的问题是规模化部署下的经验孤岛。如果团队里有 50 个开发人员，每个人的 Agent 都在本地独立摸索公司内部 CI/CD 系统的某一个奇葩报错，相当于团队为同一个坑支付了 50 遍大模型的 API 账单。群体智能进化打破了实例之间的物理隔离，让一个 Agent 踩过的坑成为全团队的免疫抗体，抹平多实例部署的知识水位差。

其适用场景于企业级 Agent 矩阵、跨部门研发协同、大型内部工具链。团队规模越大，这层进化的网络效应越明显。前提是必须在共享层前置严苛的 PII（个人身份信息）脱敏与恶意 Prompt 注入拦截机制，防止单一终端的脏数据污染全局技能库。

策略进化

再往下走，就是最重的一层：让系统直接改策略本身。

这里的策略可能是：

• 代码
• 工作流拓扑
• 模型参数
• 策略网络
• 推理路径分配

这层能力上限很高，也很危险。因为一旦我们把真实用户反馈接进训练或策略更新链路，很多以前可以拖着不管的问题会立刻变成硬约束：

• 数据许可
• 脱敏
• 训练延迟
• 奖励劫持
• 评测作弊
• 安全回滚
• 服务与训练解耦

将真实的交互轨迹与成败反馈收集起来，直接修改 Agent 的核心调度代码、工作流拓扑，甚至转化为强化学习（RL）的标量奖励来更新大模型的底层参数。

其主要解决的问题是基座模型能力天花板的绝对限制。无论是追加记忆还是改写技能，本质上都在做外挂。当遇到模型根本无法理解的深层逻辑或极度复杂的推理链条时，外挂方案会全线崩溃。策略进化直接向底层动刀，利用在线交互产生的真实反馈信号（如代码是否编译通过、测试用例是否全绿）来微调模型权重或重构 Agent 的执行逻辑。

主要适用场景是拥有充足算力预算的 AI 基础设施团队、需要将开源模型逼出闭源模型效果的核心业务。这一层工程风险极大。任务必须具备极度清晰、可自动化判别的反馈信号（如数学定理证明、代码生成）。如果反馈信号存在噪声，模型会迅速在错误的梯度中崩溃，产生严重的奖励作弊（Reward Hacking）现象。

核心工程挑战

上面讲了四层进化，但是要落地自进化系统，必须跨越四道工程天堑。

评估器比生成器更重要。没有评估器的自动修改，只是在自动制造生产事故。Darwin Skill 的棘轮、Ultron 的升级门控、OpenClaw-RL 的 PRM，都在解决同一个问题：证明改动没有让系统变坏。评估器的算力消耗通常是生成器的三倍以上。

可回滚是自进化的基础设施。技能层的优势在于天然支持版本化。参数层的更新回滚成本极高。工程实践的逻辑是：能在记忆层解决的异常，绝不改写技能；能在技能层修补的逻辑，绝不修改代码；能在代码层绕过的缺陷，绝不在线更新权重。

共享经验需要严苛治理。群体智能闭环的引入，意味着污染风险的全局放大。一个包含 rm -rf / 的错误技能一旦进入共享库，会摧毁整个团队的开发环境。权限分层、PII 脱敏、候选验证和版本审计，是系统上线的强制前置条件。

技能供应链安全无法事后补救。Agent Skills 已经演变为跨生态的能力封装格式。它包含脚本、远程依赖和执行指令。技能市场必须审查其是否读取敏感路径、是否执行危险命令、是否下载未知来源的 Shell 脚本。沙箱隔离和系统调用拦截必须做在宿主的最底层。

当前可落地执行的路线，不要一步到位堆砌在线 RL。可分阶段实施：

第一阶段，夯实上下文治理。让 Agent 具备最基本的成长能力：记录偏好、总结失败、检索历史。重点是让项目上下文和工具状态形成稳定机制，控制上下文窗口的 Token 消耗。

第二阶段，跑通技能资产沉淀。当排错经验重复出现，将其提取为 SKILL.md。引入类似 Darwin Skill 的测试集与评估机制。这是当前投入产出比最高的一步，能够立竿见影地降低 API 调用成本。

第三阶段，建设跨端群体智能。部署共享存储与演化服务，实现多终端经验的去重、验证与分发。在这个阶段，投入 50% 的研发精力解决隐私脱敏与权限审计问题。

第四阶段，谨慎切入参数与工作流修改。只有当你的 PRM 准确率达到生产可用级别，沙箱隔离足够坚固，版本回滚延迟降到秒级时，才去触碰在线强化学习。

自进化 Agent 的核心壁垒，从来不是模型本身有多聪明，而是底层的评估、沙箱、治理和安全机制有多扎实。

以上。

但又不能真这么干，这是一个简单的财务逻辑，也是一种本能的反应。

但研发又不是完全标准化的流水线。AI 在各环节都有提速，但对于需求理解的一致性，线上兜底，发布治理这些环节没法完全同步提速。

人是可以砍，但最终系统脆弱性、技术债务和交付风险一起放大。

以 AWS 为例，公众知道的类似线上故障发生不止两次了。

并且在一些大的公司，也出现了开发人员不知道自己写的是什么的情况，对于大公司一套巨大的工程体系，如果是一个完全的黑盒，没有人知道里面发生了什么，出现大的问题只是迟早的事情。

聊远了点，回到今天的主题，如何有效的度量研发效能。

当我们用上 AI Coding 之后，在上面所说的整体提效的逻辑中，我们需要细化这个效能的度量逻辑。

同样规模的团队，能不能交付更多有效价值，能不能把交付周期压短，能不能在不明显增加事故和历史债务的前提下，把过去做不到的事情做起来。

从指标的逻辑来看，DevOps 里那套大家已经很熟的「四个指标」——部署频率、交付周期、变更失败率、平均恢复时间依然是很能打的一组指标。尤其是 TTM，也就是从需求进入系统到真正产生用户价值的时间，还是王牌指标。

AI 时代，研发效能的核心指标体系要刷新，但不能推倒重来。

整个度量的逻辑不仅仅在于指标，同时也在于到底把指标绑在什么对象上，怎么解释，怎么防止它们被 AI 放大之后失真。

度量谁

一个问题，AI 产出要不要单独度量？

建议是：可以记录，不要单独考核。

因为 AI 没有责任主体。它不会背 SLA，不会参加事故复盘，也不会在需求失败时承担后果。

如果我们把「AI 生成代码占比」或者「AI 采纳率」当核心 KPI，很快就会把团队带进一个很熟悉的坑：为了优化指标而优化行为，最后牺牲真实交付质量。

研发效能度量一定要有清晰主体。这个主体通常有三层：

• 工程师个体
• 团队
• 价值流或产品线

在 AI 时代，我更建议把主分析单位放在团队和价值流，但个体数据也需要通晒，人与人还是需要比较，并且人的实际使用情况也需要观测和度量。

说到个体度量，可能会有人觉得开始卷了，回到了粗暴管理

我觉得个体数据要看，并且要公开到一定程度。否则团队里谁在真正把 AI 用进生产，谁还停留在传统写法，谁能稳定地产出高质量变更，谁在用 AI 快速制造垃圾代码，管理层根本看不见，辅导也无从下手。问题从来不在于能不能比较，问题在于拿什么比较，以及比较之后准备用它干什么。

可以把「个体可观测」和「个体直接考核」分开。前者要做细，后者要克制。个体层的数据主要解决三类问题：第一，识别使用差异。第二，识别能力短板。第三，识别风险人群。比如有的人 AI 使用频率很高，但交付周期没有改善，返工率还在上升，这通常不是工具问题，是任务拆解、约束描述、结果校验出了问题。还有一种人，表面上 AI 使用不多，但需求稳定、事故极少、关键模块掌控力强，这类人往往承担了大量隐性复杂度，单纯看「人均产出量」会被严重低估。

所以个体层该看的，不是「生成了多少」，而是「借助 AI 之后，个人交付行为发生了什么变化」。可以重点盯几组数据：需求从领取到合并的中位时长、PR 平均大小、评审往返次数、回退率、线上问题关联率、测试补充情况、跨模块变更占比、AI 建议采纳后的修改幅度。这里面真正有价值的，不是某个数字本身，而是前后变化和人与人之间的分布差异。一个人 AI 采纳率高，不说明他强；采纳率高、评审一次过、上线后稳定，这才说明工具真的转化成了产能。反过来，另一个人采纳率也高，但 PR 越来越大、review 来回打架、上线后热修频繁，这种数据就已经在报警了。

个体数据为什么要通晒？

团队协作里，很多能力本来就是相对的。谁的需求吞吐稳定，谁总能把复杂变更压在可控范围里，谁的变更老是把测试链路打爆，谁对 AI 的依赖已经超过了校验能力，这些不能永远藏在「一团和气」后面。通晒的价值是建立真实参照系。工程团队里最怕的一种状态，是大家都觉得自己做得差不多，实际上产出质量、稳定性、问题密度差了一倍以上。数据如果不拉平，组织就只剩印象管理。

当然，个体通晒有前提。第一，口径必须统一。第二，不能只晒单一指标。第三，必须配上下文。比如一个人长期负责遗留系统改造，变更失败率高一点、交付周期长一点，很正常；另一个人长期做边缘功能，吞吐高也不稀奇。脱离任务难度做横向比较，最后一定会逼着大家抢简单活。我的经验是，个体层至少要把任务类型、系统风险等级、需求大小这几个维度一起带上。不然表面上是在做精细化管理，实际上是在奖励投机。

团队层和价值流层还是主轴，因为真正的交付结果最终只能在这两层闭环。一个工程师再强，也没法单独决定发布窗口、联调效率、测试环境、跨团队依赖和灰度策略。AI 时代尤其如此。代码写快以后，瓶颈更容易从个体编码能力转移到团队协作和系统机制上。所以如果一个团队整体 TTM 没降、变更失败率在升、MTTR 也没有改善，那就算团队里有几个人个体数据很亮眼，也不能说明这个组织真的变快了。很多管理者容易被「明星工程师 + AI」的局部高产迷惑，这是很危险的。效能度量最终看的是系统，不是看谁在局部冲得猛。

价值流这一层更关键，因为它决定了管理层看到的是局部繁荣，还是真实效率。一个需求从业务提出到用户可用，中间穿过产品、研发、测试、运维、合规、数据、客服，任何一个环节卡住，前面所有 AI 提速都白搭。很多团队以为自己效能不差，问题出在开发不够快；把价值流拉直一看，开发可能只占整个周期的 20%。剩下 80% 都耗在等待、确认、返工和协调上。这个时候你还在研究个人 AI 采纳率有没有上去，说实话，方向已经偏了。

所以，三层都要度量，但角色不同。

• 个体层，解决的是识别差异、暴露问题、推动辅导。
• 团队层，解决的是交付责任和工程能力。
• 价值流层，解决的是端到端效率和组织瓶颈。

如果非要再说得更落地一点，可以这样处理：

• 个体层数据全量采集，有限通晒，谨慎用于绩效
• 团队层数据作为正式经营指标，进入月度复盘
• 价值流层数据进入管理层决策，用来推动跨部门改造

这里还有一个问题：AI 使用情况本身，确实会逐渐演化成个体能力差异的一部分。今天还可以说是工具习惯差异，再过一段时间，它会越来越接近工程生产方式差异。有人能用 AI 快速完成问题拆解、方案比选、代码生成、测试补全、文档整理，再自己完成严格校验；有人只是把 AI 当高级补全，甚至生成什么就提交什么。两者的产出质量和成长速度，一定会拉开。这个差异如果不观测，组织是在主动放弃识别新能力结构的机会。

还是那句话，观测不等于迷信，比较不等于唯排名论。个体层数据要服务于两件事：培养更强的人，提前发现风险。它不能把团队带回那种老派的、只会按数字压人的管理习惯。因为 AI 时代最不缺的，就是表面上很漂亮的数字。真正缺的，是能把这些数字放回具体工程语境里解释清楚的人。

量结果

我一直不太赞成把研发效能拆成「过程指标 vs 结果指标」两个完全对立的东西。工程里没这么清楚。很多大家嘴里的结果指标，实际上掺了很多过程含义。代码行数就是典型例子。

很多人说 LOC 已经过时，这话只说了一半。更准确一点：LOC 从来就不是好的一线效能指标，在 AI 时代更差。

原因有三个。

• 生成成本塌了：过去一个人写 500 行和写 50 行，投入成本通常不同。现在 AI 补全、生成、重构、搬迁代码，几分钟就能吐出成百上千行。代码行数和人类投入的相关性被打穿了。
• 噪音变大：AI 很容易生成「看起来很完整」的实现：参数校验、日志、适配层、重复样板、冗余抽象全都给你带上。LOC 涨得飞快，但业务价值未必增加。
• 债务被掩盖：最麻烦的是第三点。AI 会让代码库存增长速度明显快于架构治理速度。表面上看，产出变高了；往后看，维护成本、理解成本、回归成本都在涨。LOC 会把这个问题盖住。

所以代码行数其实没有啥意义，只当成代码影响范围的辅助信号，别当产出指标。

那真正该量什么结果？

可以分三类。

交付结果

这是最基础的一层：

• 需求交付数量
• 需求交付周期
• 按期上线率
• 有效发布次数
• 版本回退率

这里要提醒一下：上线需求数也很容易失真。
因为需求切得越碎，上线数越好看；但碎到一定程度，用户感知价值可能没有提升，反而多了协调成本。

所以需求数量一定要配合需求粒度标准化。最少要把需求分成几类：小修复、小功能、中型功能、跨系统项目、技术治理项。不同类型分开统计，不然一张表里什么都看不出来。

业务结果

如果团队做的是业务研发，最终还是得往用户影响上落。常见的：

• 某类功能从提出到用户可用的时间
• 用户覆盖范围
• 功能使用率
• 转化率变化
• 关键漏斗改善
• 客诉下降
• 线上稳定性对收入的影响

很多技术管理者不敢碰业务指标，怕研发背锅。我反而觉得该看，但不要简单归因。业务结果可以做关联分析，不要粗暴做责任归因。比如某个推荐功能两周上线了，但实验效果一般，这不等于研发效能差。研发效能差，应该体现在 TTM 过长、试验成本过高、回滚困难、迭代慢，而不是实验结论本身不好。

工程结果

如果团队做的是平台、基建、中间件、工具链，不能硬套 GMV、转化率这种业务指标。这个场景下我更看这些：

• 接入团队数
• 接入周期
• 平台能力调用成功率
• 构建时长变化
• 测试时长变化
• 故障发现提前量
• 资源成本变化
• 事故数和事故影响面
• 研发人均可支撑服务数

基建团队最吃亏的一点，是价值释放往往滞后，而且分散在别人的效率提升里。如果你只盯上线需求数，这类团队会被系统性低估。

TTM 还是核心指标

如果只能保留一个指标，我还是会选 TTM。

这里说的 TTM，不是立项到上线的日历时间，而是价值从进入研发系统到到达用户手里的有效时间。很多公司嘴上讲敏捷，实际上量的是开发开始到提测结束，这根本不是 TTM。

为什么 TTM 在 AI 时代更重要？

因为 AI 最直接改变的，就是局部生产速度。代码写快了，单测补得快了，文档初稿也快了。问题是，这些加速会不会真的传导到业务价值交付，完全不确定。

我见过最典型的一种情况：

• 开发编码时间下降 40%
• PR 数量上涨 2 倍
• 评审负担上涨 60%
• 测试回归时长上涨 35%
• 发布前冻结窗口变长
• 最终需求上线周期几乎没变

如果你只看编码侧的数据，会得出一个完全错误的结论：AI 大幅提升了效能。
如果你看 TTM，问题一下就暴露了：加速发生在局部，瓶颈转移到了下游。

所以 TTM 的价值就在这里。它不关心你用了什么先进工具，它只看最终有没有把价值更快交出去。

TTM 怎么拆

TTM 不能只看一个总时长，否则只能看热闹。要拆段看：

• 需求澄清耗时
• 方案设计耗时
• 开发耗时
• 评审耗时
• 测试耗时
• 等待发布耗时
• 灰度验证耗时

拆完之后，你才知道 AI 真正帮到了哪一段，堵在了哪一段。

另外，在 AI 时代，这种拆段是否合理，是否可以合并不同阶段或角色，让一些信息的流转内化为个人的思考逻辑，实现端到端的 AI 化。

比如，产品经理直接从需求到前端代码的实现。

看分布，不看均值

TTM 最忌讳只看平均值。平均值非常会骗人。正确看法至少要有：

• P50
• P75
• P90
• 超过阈值的长尾需求占比

因为 AI 往往会优先优化简单需求。这样 P50 可能很好看，P90 反而更差。原因也简单，简单需求被快速吞掉之后，系统里剩下的都是复杂需求、遗留系统改造、跨域联动项目，长尾会更长。

如果你只看均值，会误判整个系统在变快。

四个指标

DevOps 四指标在今天依然能打，但口径需要有一些升级。

部署频率

部署频率比 LOC 强太多。因为它至少是靠近真实交付动作的。代码写了多少行没人关心，真正有意义的是你有没有把变更安全地推到生产环境。

但部署频率也不能裸看。

高频不等于高效

AI 上来之后，一个常见变化就是团队更愿意切小 PR，发小版本。这个方向本身没问题，小批量交付通常更安全。问题在于，有些团队把一个正常需求拆成大量低价值、低独立性的碎发布，频率上去了，用户价值没上去，测试和发布成本反而更高。

所以我一般会同时看三个维度：

• 单位时间部署次数
• 每次部署的有效变更量
• 每次部署的独立可验证价值

没有后两项约束，部署频率很容易变成表演数据。

适用场景不同

业务团队和基建团队的部署频率口径也不能完全一样。

业务团队可以看：

• 每周或每日生产发布次数
• 灰度发布次数
• 从功能完成到触达用户的次数

基建团队更适合看：

• 核心服务变更发布频率
• 非工作时段紧急发布占比
• 配置变更自动化发布比例
• 平台工具链版本迭代频率

基建团队很多时候更强调稳定和兼容，追求极端高频未必合理。比如数据库、中间件、网关这类系统，频率太高反而可能说明变更管理有问题。

交付周期

交付周期本质上是 TTM 在工程流水线里的展开版。通常从代码提交到生产运行，也有人从需求进入开发开始统计。具体口径可以按团队定，但必须固定。

AI 时代交付周期最容易出现两个假象。

• 提交变快了，交付没变快： 这是前面说的局部提速问题。AI 让提交更快，但后续验证没跟上，周期不会实质下降。
• PR 变多了，周期看起来更短：如果团队把一个需求拆成多个极小 PR，每个 PR 周期都很短，报表会很好看。但从需求视角看，整体仍然很慢。所以我建议同时维护两套口径：一个是 PR 级交付周期，另一个是需求级交付周期。PR 级用于观察工程流水线摩擦，需求级用于看真实业务交付。只看其中一个，都会失真。

变更失败率

这个指标在 AI 时代的重要性实际上上升了。

因为生成式编码提高了变更速度，也提高了「错误以正确形式出现」的概率。以前很多错误是写不出来，现在是能很快写出一个逻辑闭环、风格统一、还能过部分测试的错误实现。它更隐蔽，也更容易通过表面检查。

可以把变更失败率定义得更工程化一点，至少包含这些事件：

• 发布后触发回滚
• 发布后引发 Sev 事故
• 发布后触发热点修复
• 发布后造成核心指标异常
• 发布后引起客户可感知故障

如果定义太窄，只算重大事故，这个指标会钝化。定义太宽，又会把正常试错算进去。团队需要自己定边界，但边界一旦定了就别频繁改。

AI 对失败率的影响机制

这里有几个常见来源：

• 生成代码对边界条件覆盖不足
• 引入不必要抽象，增加理解偏差
• 与历史代码风格和隐式约束不一致
• 测试代码同样由 AI 生成，出现「同源缺陷」
• 变更面比工程师主观预期更大

我自己比较警惕第四点。很多团队现在喜欢让 AI 顺手补测试，看起来很完整。但如果实现和测试都建立在同一段错误理解上，测试通过并不能证明正确。

所以在高风险变更里，测试不能只依赖生成。关键路径一定要有人做反例设计。

平均恢复时间

很多团队对 MTTR 的重视程度不够，尤其是业务团队。实际上，AI 时代恢复能力的重要性在上升。

当代码生成速度变快，进入生产环境的变更更多、更碎、更频繁，系统面对故障的概率和复杂度都在变化。你不一定能把每次变更都做得完美，但你必须能快速止血。

MTTR 的价值在于衡量团队是否真正具备工程韧性。这个指标背后对应的是一整套能力：

• 监控和告警是否有效
• 变更是否可追踪
• 是否支持快速回滚
• 灰度和开关能力是否完善
• 值班机制是否靠谱
• 故障定位信息是否充分

很多团队前面三个指标都好看，MTTR 很差。这样的系统经不起规模化 AI 变更。因为一旦出事，恢复慢会把前面所有频率和周期优势全吃掉。

历史债务

AI Coding 真正会在一年后把团队拉开差距，这里的差距在于谁更早处理历史债务。

这个问题现在还没有被足够重视。但是实际中已经越来越严重了。

因为短期内 AI 会制造一种繁荣感：交付更快，PR 更多，需求吞吐上升。可如果代码库质量、模块边界、测试资产、文档一致性没有同步改善，债务会以更快速度积累。

AI 会怎样放大债务

几个很典型的模式。

• 重复实现增多：工程师直接让 AI 在局部上下文里生成功能，很容易绕过现有抽象和公共能力。短期最省事，长期就是重复轮子到处长。
• 中间层膨胀：AI 很擅长生成 adapter、wrapper、facade 这类看起来规整的中间层。问题是很多层根本没有必要，只是为了让局部代码更顺。半年后系统会变得非常厚，排障和重构都很痛苦。
• 测试资产劣化：生成测试很快，真正有效的测试不快。团队如果只追求覆盖率，很快就会积累大量低价值测试：断言脆弱、依赖实现细节、执行慢、维护成本高。最后 CI 时间越来越长，大家开始跳过测试。
• 文档与实现漂移更快：AI 可以快速生成设计说明、变更记录、接口文档初稿。但只要流程里没有强约束，这些文档过几周就过时。文档数量增加，不代表知识管理更好。
• 债务怎么量：技术债务很难精确，但不代表不能量。至少看四组信号：
  • 重复代码比例或重复能力点数量
  • 关键模块复杂度变化
  • 测试执行时长与稳定性
  • 历史模块变更失败率和恢复时长

指标落地

说一堆指标，如果最后只是做一张月报，那基本没用。研发效能度量要落地，大概可以看三点：统一口径、自动采集、和决策绑定。

统一口径

很多团队最大的问题不是没数据，是每个人嘴里同一个词代表不同意思。

比如「交付周期」，有人从排期开始算，有人从开始开发算，有人从代码提交算。你拿这三种数据做横向比较，结论一定错。

所以第一件事就是给每个指标下工程定义：

• 起点是什么
• 终点是什么
• 谁负责标记状态
• 异常情况怎么处理
• 统计周期是什么
• 看均值还是分位数

这一步很枯燥，但躲不过去。没有口径统一，报表越华丽越危险。

自动采集

凡是靠人手填的效能数据，最后都会漂。

我建议优先从这些系统自动取数：

• 需求系统
• Git 仓库
• CI/CD 平台
• 测试平台
• 线上监控与事故系统
• 发布平台
• 值班和告警系统

AI 时代还可以补一些辅助数据，比如：

• AI 建议采纳率
• AI 生成代码在最终提交中的占比
• AI 相关变更的回退率
• AI 生成测试的失败分布

但这些只建议做诊断维度，不建议直接进核心看板。

和决策绑定

指标如果不进入真实决策流程，就只会变成汇报材料。

可以把不同指标绑定到不同节奏：

周维度

团队看流水线摩擦：

• PR 周期
• 构建失败率
• 测试时长
• 发布次数
• 热修次数

月维度

管理者看交付和稳定性：

• TTM 分布
• 部署频率
• 变更失败率
• MTTR
• 技术债务信号

季度维度

看结构性问题：

• 跨团队依赖导致的等待占比
• 核心系统复杂度变化
• 自动化覆盖关键路径的比例
• 平台能力复用率
• 人均支撑规模变化

只有当指标驱动了人力投入、架构治理、流程调整，度量才算产生价值。

常见误区

• 误区一： 拿 AI 使用量替代研发效能。 比如：人均每天调用 AI 多少次，AI 生成了多少代码，采纳率多少，这些数据可以看工具渗透率，不能代表团队变快了，更不能代表交付变好了。高采纳率有时候只是因为团队在写更多样板代码。
• 误区二：把效能问题当管理问题。 一看到周期长，就加日报、加审批、加同步会。这个思路在 AI 时代更危险，因为编码加速之后，组织摩擦会成为主要瓶颈。继续加管理动作，只会让非编码时间更长。效能最后还是要回到工程根上：架构边界、测试自动化、环境一致性、发布能力、可观测性、模块治理。
• 误区三：把所有团队放在一套指标下排序。业务、基建、平台、安全、数据团队的工作性质差异很大。统一看板可以有，统一排名很容易把组织带偏。
• 误区四：只看短期提速，不看长期维护成本。 AI 最容易制造的错觉就是这个月吞吐上涨了，于是大家默认效能提升。可如果未来三个月回归变慢、故障变多、重构困难，这个月的漂亮报表只是透支。
• 误区五：只看平均值。平均值会把长尾、异常、结构性阻塞全部抹平。工程管理里，很多真正该解决的问题都藏在 P90 之后。

最后

研发效能从来不是一个分数问题，它是一个约束系统问题。得回答下面的问题：

• 价值有没有更快交出去
• 变更是不是足够安全
• 出问题能不能快速恢复
• 现在的速度有没有透支未来

这四件事里，TTM 仍然是排第一的。因为业务不会为你写了多少代码买单，也不会为你调了多少次 AI 买单。业务只关心一件事：价值多久能到用户手里。

AI Coding 改变了工程生产函数。

但它没有改变研发效能的基本物理规律。局部速度不等于系统速度，生成能力不等于交付能力，短期吞吐不等于长期效率。

不要急着发明一套全新的效能宗教。先把工程里的主干指标守住，把主体放对，把业务团队和基建团队分开看，把技术债务纳入视野，再去观察 AI 到底在哪些环节真的创造了增益。

这样量出来的数据，才能指导决策。否则报表再热闹，也只是另一种噪音。

以上。