大模型能力持续提升之后，Agent 系统的竞争焦点正在发生变化。

过去，我们主要关心模型能不能理解任务、调用工具、编写代码。现在，更重要的问题逐渐变成：模型之外的系统，能否为 Agent 提供一个可以持续变化的运行环境？

这个运行环境通常被称为 Agent Harness。

Harness 负责把模型、提示词、工具、记忆、上下文、权限和外部环境连接起来。它决定模型能够看到什么、调用什么、保存什么，以及一次行动会产生怎样的系统影响。

从这个角度看，Agent 的能力并不只来自模型，用一个公式来表达，大概如下：

Agent 能力
=
模型能力
× 上下文组织
× 工具系统
× 运行时结构
× 生命周期治理

如果 Harness 是固定的，那么即使模型越来越强，Agent 的能力边界仍然主要由开发者预先决定。

如果 Harness 可以扩展，用户和开发者就能不断为 Agent 增加工具、技能和工作流。

但如果我们希望 Agent 进一步具备「自生长」能力，仅仅提供扩展接口还不够。系统还必须允许 Agent：

1. 发现自己的能力缺口；
2. 生成或引入候选能力；
3. 在运行时安全地激活这些能力；
4. 验证变化是否有效；
5. 在失败时完整回滚；
6. 将成功经验沉淀为可复用组件；
7. 淘汰已经失效或长期无用的能力。

Pi 与 DSH 可以被视为这条演进路径上的两个阶段。

Pi 回答的是：

如何构建一个足够小、足够开放，可以持续扩展的 Agent Harness？

DSH 进一步追问：

如何让 Agent 不只是使用外部提供的扩展，而是安全地参与自身能力结构的形成？

这不是从一种插件格式切换到另一种插件格式，而是 Agent Harness 从开放扩展平台向能力生长环境的转变。

1. 什么是 Agent Harness

一个最简单的 Agent，可以被表示为：

Model
  ↓
Prompt
  ↓
Tool Call
  ↓
Environment

模型接收上下文，生成工具调用，再根据工具结果继续推理。

但在真实系统里，Agent 还需要处理更多问题：

• 当前有哪些工具可用？
• 工具由谁注册？
• 不同任务应该使用什么模型？
• 哪些信息应该进入上下文？
• 哪些记忆需要跨会话保存？
• 如何限制文件、网络和进程权限？
• 工具调用失败后如何恢复？
• 新能力如何加载？
• 组件移除后如何清理副作用？
• 不同组件之间的依赖如何表达？

于是，Agent 的实际结构更接近于：

                ┌─────────────┐
                │    Model    │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ Agent Loop  │
                └──────┬──────┘
                       │
       ┌───────────────┼────────────────┐
       │               │                │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│    Tools    │ │    Memory   │ │   Context   │
└─────────────┘ └─────────────┘ └─────────────┘
       │               │                │
       └───────────────┼────────────────┘
                       │
                ┌──────▼──────┐
                │ Environment │
                └─────────────┘

Harness 并不是模型外面的一层简单包装。

它实际上规定了 Agent 的：

• 能力边界；
• 行为边界；
• 状态边界；
• 权限边界；
• 演化边界。

因此，当我们讨论 Agent 是否可以扩展、重构甚至自生长时，本质上讨论的不是模型参数如何变化，而是 Harness 能否安全地改变自身结构。

2. Pi：以最小内核换取最大扩展空间

Pi 的核心思想非常明确：

不要预先替用户决定完整工作流，而是提供足够小的基础能力，让用户自己构建需要的 Harness。

Pi 将自己定义为一个最小化的 Agent Harness，并通过 Extensions、Skills、Prompt Templates、Themes 和 Packages 提供扩展能力。它允许用户修改工具、命令、模型提供商、工作流、上下文处理和终端界面，也支持将这些资源打包后通过 npm 或 Git 分发。(pi.dev)

这背后是一种「原语优先」的设计哲学：

不是：
内置所有功能

而是：
提供少量原语
+
开放扩展接口
+
允许用户自行组合

2.1 最小化不是能力不足

传统 Agent 产品通常倾向于内置更多功能：

• 规划模式；
• 子 Agent；
• 权限确认；
• MCP 集成；
• 后台任务；
• 长期记忆；
• 沙箱；
• Todo 系统。

Pi 选择了另一条路线：这些能力不一定需要成为内核的一部分，它们可以通过扩展或外部环境实现。

Pi 当前提供文件读取、文件修改、内容搜索和命令执行等内置工具，同时允许通过命令行配置工具集合，也允许 Extension 注册新的工具或覆盖现有工具。(pi.dev)

这种设计的意义把稳定的内核和变化的能力分开：

稳定部分：
模型调用、Agent Loop、会话、基础工具、扩展 API

变化部分：
工具、技能、上下文、工作流、权限策略、界面、模型路由

只要扩展接口足够开放，功能就不必全部固化在核心代码中。

2.2 Pi 的四类扩展资源

从 Harness 的角度看，Pi 的可扩展性主要体现在以下几个层面。

2.2.1 Extensions：改变运行时行为

Extension 是可以进入 Agent 运行时的代码模块。

它可以：

• 注册工具和命令；
• 监听工具调用；
• 拦截或修改行为；
• 改变上下文；
• 切换模型；
• 增加权限检查；
• 实现自定义 UI；
• 覆盖内置工具；
• 连接外部系统。

因此，Extension 改变的不只是模型“知道什么”，还可以直接改变 Harness“如何运行”。

2.2.2 Skills：注入按需能力

Skill 更接近一种可复用的过程知识。

它可以告诉 Agent：

• 在什么情况下使用某种方法；
• 如何执行特定工作流；
• 如何调用外部命令；
• 如何处理某类项目；
• 如何检查输出质量。

Pi 将 Skill 设计为按需加载的能力包，使 Agent 不必在每次会话开始时把所有知识都放进上下文。(pi.dev)

2.2.3 Prompt Templates：固化交互模式

Prompt Template 将常见任务封装成可复用提示词，例如：

• 代码审查；
• 架构分析；
• 发布检查；
• 测试生成；
• 故障排查。

它改变的是任务入口和交互结构。

2.2.4 Packages：分发完整能力

Package 可以将 Extensions、Skills、Prompt Templates 和 Themes 组合起来，通过 npm、Git 或本地路径安装。Pi 还支持临时加载 Package，使组件只对当前运行生效。(github.com)

这使 Pi 不只是一个 Agent，也成为一个 Harness 能力分发平台：

Pi Package
├── Extensions
├── Skills
├── Prompts
└── Themes

2.3 Pi 的关键突破：Agent 可以参与修改 Harness

Pi 最值得关注的地方，不只是「插件多」。

它的官方描述明确鼓励用户让 Pi 编写自己需要的扩展，并在修改后通过重新加载继续当前工作。(pi.dev)

这意味着一种新的工作方式正在出现：

Agent 发现缺少某项能力
        ↓
Agent 编写 Extension
        ↓
用户检查或确认
        ↓
重新加载 Harness
        ↓
Agent 使用新增能力继续任务

过去，Agent 与开发工具之间的关系通常是：

人类开发 Harness
Agent 使用 Harness

在 Pi 中，它开始变成：

人类定义目标
Agent 修改 Harness
Agent 使用修改后的 Harness

这是从「可扩展」走向「自生长」的重要一步。

但是，这还不等于完整的自生长。

3. 行为自治不等于结构自治

理解 Pi 与 DSH 的关系，需要区分两种不同的自治。

3.1 行为自治

行为自治指 Agent 可以在已有能力范围内自主决定：

• 下一步做什么；
• 调用哪个工具；
• 如何拆解任务；
• 是否修改文件；
• 是否运行测试；
• 如何根据结果调整计划。

此时，Agent 的选择空间是动态的，但能力集合通常是预先确定的。

固定工具集合
    ↓
Agent 自主选择工具
    ↓
完成任务

3.2 结构自治

结构自治指 Agent 可以改变自己的能力结构：

• 创建新工具；
• 安装新组件；
• 替换 Memory；
• 修改上下文策略；
• 调整模型 Router；
• 增加权限规则；
• 组合新的执行流程；
• 卸载无效组件。

当前能力结构
    ↓
Agent 发现能力缺口
    ↓
生成候选组件
    ↓
改变 Harness
    ↓
形成新的能力结构

Pi 已经为结构自治打开了入口。

但它的扩展机制主要回答的是：

如何把一项新能力加入系统？

真正的自生长还必须回答：

• 新能力应该在什么条件下激活？
• 它依赖哪些已有能力？
• 它失败后能否完整退出？
• 它注册的工具和监听器由谁撤销？
• 如何判断变化带来了正收益？
• 如何防止不同扩展相互冲突？
• 如何把一次临时变化沉淀成长期能力？
• 如何淘汰不再适用的组件？

这些问题将我们从扩展系统带到了组件运行时。

4. DSH：为 Harness 自生长建立运行时基础

本文讨论的 DSH，不只是另一个插件系统。

它试图将 Agent Harness 表达为一个可以在运行中不断组合和重组的组件系统。

其基本结构可以概括为：

Component
=
Context
+
Effect
+
Cleanup
+
Coeffects

这四个概念分别回答四个问题：

DSH 的目标不是让所有模块都能任意修改系统，而是让变化成为一种显式、可追踪、可逆的运行时操作。

4.1 Context：为能力提供明确边界

一个组件不能直接访问所有系统状态。

它应该通过 Context 获取所需能力，例如：

Context
├── Model Registry
├── Tool Registry
├── Memory
├── Event Bus
├── Session
├── Logger
├── Storage
├── Permission
└── Environment

Context 的第一层作用是解耦。

组件不需要知道某个能力的具体实现，只需要知道运行环境向它提供了什么。

例如，一个模型路由组件可能只依赖：

Model Registry
Task Metadata
Usage Metrics

一个长期记忆组件可能只依赖：

Session Events
Embedding Service
Storage
Context Injector

一个工具组件则可能只依赖：

Tool Registry
Credentials
Network
Logger

Context 的第二层作用是限制能力边界。

如果组件只能通过 Context 访问环境，那么系统就可以决定：

• 哪些资源向它开放；
• 哪些能力只读；
• 哪些调用需要权限；
• 哪些状态不能跨组件共享；
• 哪些操作只能在 Sandbox 中执行。

因此，Context 不只是依赖注入，也是一种能力安全模型：

组件能做什么
≈
Context 向它暴露什么

4.2 Effect 与 Cleanup：让变化可以被撤销

当组件加入 Harness 时，通常会产生副作用。

例如：

• 注册一个工具；
• 添加一个事件监听器；
• 打开数据库连接；
• 启动后台任务；
• 修改模型路由；
• 向上下文注入内容；
• 挂载文件目录；
• 注册快捷键；
• 创建缓存；
• 改变权限策略。

这些变化可以统一理解为 Effect：

Component
    ↓
Effect
    ↓
Harness 状态发生变化

问题在于，大多数插件系统只强调如何创建 Effect，却没有把撤销 Effect 当作同等重要的能力。

于是，组件卸载后可能出现：

• 工具仍然留在 Registry 中；
• 事件监听器重复注册；
• 后台任务继续运行；
• 网络连接没有关闭；
• 临时文件没有删除；
• Context 中残留失效状态；
• 新旧路由规则同时生效。

在 DSH 中，Effect 应该返回对应的 Cleanup：

Effect(Context) → Cleanup

例如：

function activate(context) {
  const unregister = context.tools.register(myTool)

  return function cleanup() {
    unregister()
  }
}

更复杂的组件可能产生多个副作用：

function activate(context) {
  const stopTool = registerTool(context)
  const stopListener = registerListener(context)
  const stopWorker = startWorker(context)
  const closeConnection = connectDatabase(context)

  return async function cleanup() {
    await stopWorker()
    stopListener()
    stopTool()
    await closeConnection()
  }
}

这使组件具备完整生命周期：

创建
  ↓
激活
  ↓
运行
  ↓
停用
  ↓
清理

4.3 时间可组合性：让 Agent 有资格试错

Effect 与 Cleanup 提供的是一种时间可组合性。

一个组件可以在某个时刻进入系统，也可以在另一个时刻完整退出：

t₀：Harness 原始状态

t₁：组件进入
    → 注册工具
    → 启动服务
    → 注入上下文

t₂：组件运行

t₃：组件退出
    → 移除工具
    → 停止服务
    → 撤销上下文

t₄：Harness 恢复到可预测状态

这对普通插件系统很重要，但对自生长系统更重要。

因为自生长必然包含试错。

Agent 创建的新工具、新路由器、新记忆策略，不可能每次都正确。如果一次失败的尝试不能被完整撤销，那么每次实验都会向系统中留下残余状态。

最终，所谓“生长”就会退化成不可控的复杂度积累。

因此，自生长的基本过程不应该是：

生成组件
  ↓
永久安装

而应该是：

生成候选组件
      ↓
执行受控 Effect
      ↓
验证运行结果
   ┌──┴──┐
 成功    失败
  │       │
保留   Cleanup

Cleanup 的意义不只是“支持热卸载”。

它赋予 Agent 一种更关键的能力：

在不永久污染系统的前提下试验新的自身结构。

4.4 Coeffects：让依赖关系成为运行时的一部分

时间可组合性解决的是组件何时进入、何时退出。

但 Agent Harness 的组件并不是彼此孤立的。

如果依赖关系只是组件内部的隐式假设，运行时就无法回答：

• 组件现在能否启动？
• 它缺少什么能力？
• 某个依赖消失后，哪些组件应该停用？
• 替换一个 Provider 会影响哪些组件？
• 哪些组件可以被安全卸载？
• 一个候选组件是否与当前环境兼容？

Coeffects 用于显式表达组件所需的外部条件：

Effect：
组件对系统做什么

Coeffects：
组件需要系统提供什么

例如：

const vectorMemory = {
  coeffects: [
    "embedding-model",
    "vector-storage",
    "session-events"
  ],

  effect(context) {
    // 激活 Memory
    return cleanup
  }
}

运行时可以根据当前 Context 判断组件是否具备激活条件：

依赖全部满足
    ↓
组件激活

依赖不完整
    ↓
组件保持未激活

依赖运行中消失
    ↓
执行 Cleanup

这使 Harness 不再只是一个插件列表，而是一个动态依赖图：

Credential
    ↓
GitHub Provider
    ↓
GitHub Tool
    ↓
Repository Agent

或者：

Embedding Model ─┐
                 ├→ Vector Memory → Context Injector
Vector Storage ──┘

4.5 空间可组合性：让生长不是无序堆积

Coeffects 提供的是一种空间可组合性。

组件不是按照固定顺序硬编码在系统中，而是根据能力和依赖形成运行时拓扑。

当一个能力出现时，依赖它的组件可以被激活；当这个能力消失时，相关组件可以被停用：

Sandbox 出现
    ↓
Code Executor 激活
    ↓
Test Runner 激活
    ↓
Coding Agent 获得安全执行能力

如果 Sandbox 被移除：

Sandbox 消失
    ↓
Code Executor Cleanup
    ↓
Test Runner Cleanup
    ↓
相关工具从 Agent 能力集合中撤销

这与传统插件系统有一个关键区别。

传统插件系统更像：

安装了什么
=
系统拥有什么

而动态组件运行时更像：

当前可用能力
=
当前组件
× 当前依赖
× 当前环境
× 当前权限

这使 Harness 的结构可以随着任务和环境变化，而不是不断向全局系统中永久添加模块。

真正的生长，不是组件数量持续增加，而是系统能够形成更适合当前任务的能力结构。

4.6 从动态重组到自生长闭环

Context、Effect、Cleanup 和 Coeffects 为动态重组提供了基础。

但必须强调：

动态重组是自生长的必要条件，不是自生长的全部。

完整的自生长至少需要五个阶段。

4.6.1 第一阶段：发现能力缺口

Agent 首先要判断自己缺少什么。

例如：

• 当前没有访问某类数据的工具；
• 现有 Tool 无法处理特定协议；
• Memory 无法支持长期任务；
• 当前模型不适合某类输入；
• 缺少项目专用的验证流程；
• 当前执行环境不满足安全要求；
• 工具调用成本或延迟过高。

能力缺口不能只由「工具调用失败」判断。

它还可能来自：

• 任务规划；
• 运行指标；
• 用户反馈；
• 测试结果；
• 历史失败记录；
• 现有能力清单；
• 环境变化。

因此，自生长的起点不是生成代码，而是：

目标要求
-
当前能力
=
能力缺口

4.6.2 第二阶段：生成或引入候选能力

识别缺口后，Agent 可以选择不同方式补齐能力：

• 编写新的 Tool；
• 生成新的 Skill；
• 安装已有 Package；
• 包装外部 API；
• 组合已有组件；
• 替换 Memory Provider；
• 调整模型 Router；
• 创建新的工作流；
• 启动一个专用子 Agent；
• 为现有组件增加适配层。

这里的关键词是「候选」。

Agent 生成的组件不能因为能够编译或加载，就自动成为系统的永久能力。

生成成功
≠
能力有效
≠
适合长期保留

4.6.3 第三阶段：在受控环境中激活

候选组件应该先进入受限 Context。

系统需要明确：

• 它可以访问哪些目录；
• 可以调用哪些网络服务；
• 是否可以读取凭证；
• 可以注册哪些工具；
• 能否修改全局状态；
• 资源消耗上限是多少；
• 运行时间是否受限；
• 哪些副作用必须登记。

这一点尤其重要，因为扩展代码通常拥有较高权限。

以 Pi 为例，其官方安全文档明确说明，内置工具和 Extension 默认继承启动 Pi 的进程权限；第三方 Package 可能执行代码或指示模型执行操作，因此需要代码审查，并在需要时依赖容器或虚拟化提供真正的隔离边界。(github.com)

如果 Agent 开始自行生成和加载组件，权限问题只会更加突出。

所以，自生长必须建立在受控运行时上，而不能建立在「默认信任所有新代码」之上。

4.6.4 第四阶段：验证、保留或回滚

候选能力激活后，系统需要对它进行验证。

验证可以包括：

• 能否完成目标任务；
• 是否通过单元测试；
• 是否破坏已有功能；
• 是否产生未声明的副作用；
• 是否扩大了不必要的权限；
• 是否降低了任务成本；
• 是否提高了成功率；
• 是否造成明显的上下文膨胀；
• 是否与现有组件冲突；
• Cleanup 是否完整。

验证结果通常有三种：

验证通过
    ↓
保留或固化

部分通过
    ↓
修改后重新试验

验证失败
    ↓
Cleanup + 回滚

因此，自生长不是一次性的代码生成，而是一个选择过程：

Generate
→ Activate
→ Observe
→ Evaluate
→ Select

没有评估的生成，只是变化。

经过评估和选择的变化，才可能成为生长。

4.6.5 第五阶段：沉淀、复用与淘汰

一次任务中的成功，不代表组件值得永久保留。

系统还需要决定：

• 这项能力是否跨会话有效？
• 它适用于哪些任务？
• 应该在什么条件下重新激活？
• 它依赖哪些版本？
• 它的权限范围是什么？
• 它由谁生成？
• 经过了哪些测试？
• 是否允许自动升级？
• 何时应该重新评估？
• 何时应该被淘汰？

因此，一个可复用组件除了代码，还需要附带元数据：

Component
├── Implementation
├── Capability Description
├── Coeffects
├── Permissions
├── Validation Records
├── Version
├── Provenance
├── Metrics
├── Effect
└── Cleanup

真正的自生长闭环应当是：

发现缺口
  ↓
生成候选能力
  ↓
隔离激活
  ↓
观察与验证
  ↓
保留或回滚
  ↓
沉淀为可复用组件
  ↓
持续评估
  ↓
升级或淘汰

5. Pi 与 DSH 的核心差异

Pi 与 DSH 并不是简单的替代关系。

它们关注的是两个不同层次的问题。

可以把两者的关系概括为：

Pi：
稳定核心
+
开放扩展点
+
能力分发机制

DSH：
组件化 Context
+
显式 Coeffects
+
可逆 Effect
+
动态生命周期

Pi 解决了「能力能否加入」的问题。

DSH 更关注「能力如何进入、如何协作、如何退出，以及如何在运行时形成新的结构」。

6. 从可扩展到自生长，中间还差什么

可以把 Agent Harness 的演进分为三个阶段。

6.1 第一阶段：固定能力

模型
+
固定提示词
+
固定工具

系统能够执行任务，但能力边界在设计阶段已经确定。

如果缺少能力，只能由开发者修改产品代码并重新发布。

6.2 第二阶段：开放扩展

稳定核心
+
Extensions
+
Skills
+
Packages
+
开放 API

用户和开发者可以持续增加能力。

Agent 也可以帮助编写扩展，但扩展的发现、安装、验证和维护通常仍然依赖人工流程。

Pi 代表了这一阶段的重要方向：Harness 不再是一个封闭产品，而成为可以根据个人工作流持续定制的平台。

6.3 第三阶段：受控自生长

稳定内核
+
能力缺口识别
+
候选组件生成
+
动态组件运行时
+
显式依赖
+
可逆副作用
+
隔离验证
+
自动回滚
+
能力沉淀
+
持续淘汰

Agent 不再只是等待外部为它安装能力。

它可以根据任务识别不足，提出新的能力结构，在受控环境中试验，并根据结果决定保留、修改还是撤销。

这时，Agent 的角色从能力消费者变成了能力形成过程的参与者。

7. 自生长不等于无限增长

「自生长」并不是 Agent 不断为自己增加工具和代码。

无限增加不是生长，而是熵增。

一个只会添加能力、不会清理能力的系统，最终会出现：

• 工具数量不断膨胀；
• 相似能力重复实现；
• 组件版本相互冲突；
• 权限范围持续扩大；
• 上下文被大量描述占据；
• 路由规则越来越难以理解；
• 无效监听器和后台任务持续运行；
• Agent 无法判断应该使用哪个工具；
• 系统行为逐渐不可预测。

因此，自生长必须同时包含四种能力：

增加
+
选择
+
清理
+
遗忘

可以进一步表示为：

可持续生长
=
生成新能力
-
淘汰无效能力
+
重组已有能力

这也是 Cleanup 和生命周期管理的重要性所在。

真正成熟的 Agent 不仅要知道「我还需要什么」，还要知道：

• 什么已经不需要了；
• 什么正在产生负面影响；
• 什么应该暂时停用；
• 什么可以被更简单的组件替代；
• 什么经验只适用于过去的环境。

遗忘不是生长的反面。

受控遗忘本身就是生长的一部分。

9. Pi 与 DSH 不是替代，而是演进

Pi 的价值在于证明了一件事：

Agent Harness 不需要是一个功能固定的封闭产品。

通过开放 Extension、Skill、Prompt 和 Package，Harness 可以被用户重新塑造，也可以让 Agent 辅助编写自身需要的扩展。

这已经比传统 Agent 产品向前迈出了一大步。

DSH 所代表的方向，则是在此基础上进一步抽象：

如果 Agent 可以创建新能力，那么这些新能力应该如何成为运行时的一等公民？

答案不能只是把更多代码放进扩展目录。

系统还需要：

• 明确组件所处的 Context；
• 显式声明组件依赖的 Coeffects；
• 管理组件产生的 Effect；
• 在组件退出时执行 Cleanup；
• 根据环境变化重新计算能力拓扑；
• 对候选能力进行验证；
• 将有效能力沉淀下来；
• 将失效能力安全淘汰。

因此，二者可以形成一种递进关系：

Pi：
让 Harness 可以被修改

        ↓

DSH：
让修改具有显式生命周期

        ↓

自生长 Agent：
让 Agent 可以发起、验证并沉淀修改

从这个角度看，DSH 不是对 Pi 的否定。

它是在 Pi 所代表的开放扩展思路上，将“变化”进一步提升为运行时的核心抽象。

10. Harness 正在成为 Agent 的生长环境

如果说 Pi 的核心贡献，是把 Agent 从一个封闭产品变成一个可编程、可扩展的平台，那么 DSH 所探索的下一步，就是让 Agent 逐渐成为自身能力变化的参与者。

它不只是使用已有工具，还可以：

• 发现能力缺口；
• 创建候选组件；
• 调整能力组合；
• 在受控环境中试验；
• 根据结果保留或回滚；
• 将成功经验沉淀为长期能力。

但自生长不等于无限增加。

一个只会安装新工具、写入新记忆、叠加新策略的 Agent，最终只会被自己积累的复杂度拖垮。

真正可持续的生长，必须同时包含：

发现
→ 生成
→ 激活
→ 验证
→ 选择
→ 清理
→ 沉淀
→ 淘汰

Pi 回答了：

如何让 Agent Harness 可以被持续扩展？

DSH 则进一步追问：

如何让 Agent 安全地参与自身能力的形成？

从 Pi 到 DSH，变化的不只是扩展机制，而是 Harness 的角色。

它正在从承载工具与插件的工程框架，转变为支持能力试验、筛选、重组和沉淀的运行环境。

未来的 Agent Harness 可能不再只是模型与工具之间的连接层。

它还将成为 Agent 管理自身变化的基础设施：

• 允许新能力出现；
• 阻止错误变化扩散；
• 保存经过验证的经验；
• 清除已经失效的结构；
• 在保持稳定内核的同时持续重组外围能力。

只有当 Agent 既能增加能力，也能验证、回滚、清理和遗忘时，它才真正具备从「可扩展的软件」走向「可持续生长的系统」的可能。

以上。

很多公司以为自己接入了几个大模型，采购了一批智能体工具，员工就获得了某种近乎无限的生产力。

换个角度看：每个人突然多出了一百万名能力不稳定、缺乏上下文、不会主动澄清目标、偶尔虚构进度、还能高速消耗预算的下属。

这些下属不需要工位，也不会请假。它们一天可以提交上千次结果，看起来永远在工作。管理者很容易被这种吞吐量迷惑，误把生成速度当成有效产出，误把调用次数当成自动化程度，误把一段流畅的回答当成任务已经完成。

AI 把执行成本压得很低，同时把管理问题放大了。

今天的智能体系统可以被看成一种新型组织。模型是员工，token 是人力预算，上下文是岗前培训，工具权限是组织授权，工作流是汇报关系，评估体系是绩效制度，人工验收则对应管理责任。

按照这个视角观察，很多 AI 项目的失败也是情里之中。它们把模型能力当成唯一变量，却没有建立与之配套的管理系统。结果类似一家突然扩张到百万人的公司：招聘极快，职责模糊，没有培训，没有绩效标准，管理者还希望它自行涌现出秩序。

历史上，这类问题出现过。

铁路旧事

十九世纪三十年代的铁路热潮带来了前所未有的运输能力。铁路解决了距离和速度问题，也制造了规模、调度、协作和安全问题。

单条铁路容易运营。线路变长、车次增加、岗位分化以后，系统复杂度迅速上升。信息必须跨地区传递，车辆必须统一调度，责任必须分层，事故必须被记录和复盘。原有的管理方式无法支撑新基础设施的吞吐量，事故随之发生。

铁路公司最终补上的，是现代管理体系。

技术增加了系统能力，管理制度把能力组织成可持续的产出。铁路后来成为第一个十亿美元产业，支撑它的并非轨道和机车本身，还包括围绕大规模协作建立的组织结构。

AI 正在重演类似的路径。

过去的软件系统严格服从预定义逻辑。输入符合条件，程序进入对应分支。工程团队可以通过代码结构、类型系统、测试和运行指标逐层收紧系统行为。

智能体的行为边界宽得多。它可以搜索、分析、生成、调用工具、保存记忆、继续拆解任务。它也可能误解任务、忽略约束、重复调用、把猜测写成事实，在结果看似完整时掩盖中间步骤的错误。

当模型调用规模扩大，问题便从「它会不会回答」变成「我们怎样管理一支由概率模型构成的劳动力」。

许多企业仍在用采购软件的思路处理这件事：买更强的模型，开放更多上下文，增加 token 预算，再连接更多工具。

这很容易走向失控。

人海复现

遇到复杂任务就增加 token，和过去遇到项目延期就增加人手，逻辑高度相似。

管理者看到结果不好，第一反应往往是扩大上下文窗口，让智能体多思考几轮，再增加几个子智能体并行搜索。系统图越来越复杂，调用链越来越长，账单同步上涨。

问题可能出在任务定义上。

一个智能体收到「分析这家公司是否值得投资」，它需要自行猜测分析期限、风险偏好、数据范围、估值框架和输出用途。另一个智能体收到「优化系统性能」，它也要猜瓶颈位于吞吐量、尾延迟、内存占用、启动时间还是硬件成本。

人类员工面对这种指令，会追问。智能体更可能直接开始工作。它会用流畅语言填补任务中的空白，把未经确认的假设埋入推理过程，最终交付一份结构完整、目标偏离的结果。

给它更多 token，只会让偏离过程更长。

这和组织扩张中的人海战术没有本质差异。需求尚未稳定时增加开发人员，沟通路径随人数增长，信息损耗也随之增长。新增人员首先要理解问题，再理解已有方案，然后处理方案之间的冲突。最后，大量时间花在协调新增人力本身。

多智能体系统也会出现同样的问题。

一个规划智能体拆任务，多个执行智能体并行处理，汇总智能体负责合并，审查智能体再做验证。架构图确实很漂亮。但实际运行时，规划阶段的歧义被复制到所有分支，各个执行智能体基于不同假设工作，汇总阶段只能用更多 token 消解冲突。

最终系统花费大量计算资源，证明自己已经花费了大量计算资源。

智能体反复自我调用的循环尤其典型。表面上看，它在持续反思和改进；深入观察调用轨迹，常常会发现它没有获得新的外部信息，也没有引入新的判定标准，只是在几个近似答案之间改写措辞。

这种循环不会自然收敛。缺少验收条件时，「继续思考」没有终点。

工程上必须为循环设置退出规则：哪些指标达到后停止，连续多少轮没有新增信息后停止，成本超过多少后转人工，发生哪些工具错误后禁止重试。退出规则缺失，智能体就会把预算消耗当成工作进展。

上下文债务

几乎没人会给 AI 恰当的语境。

这句话听起来像提示词问题，实际涉及企业知识怎样存在、怎样更新、怎样被验证。

当一个人在公司里工作几年，会形成大量隐性知识。他知道某个字段名与实际含义不同，知道某项流程在文档里有三步、落地时有七步，知道某个客户的特殊约定，知道哪些数据能够使用，哪些结论虽然算得出来却不能直接发布。

这些知识分散在人的记忆、聊天记录、会议结论、历史工单和代码注释中。公司过去可以容忍这种状态，因为熟练员工承担了知识路由器的角色。谁遇到问题，找对人问一句即可。

AI 无法稳定获取这种语境。

把所有资料塞进上下文也解决不了。上下文越长，噪声越多；资料之间可能相互冲突；旧制度和新制度可能同时出现；局部例外可能被模型理解成通用规则。检索系统可以减少输入量，却无法自动判断哪份知识具备权威性。

上下文工程因此要处理四类问题。

第一类是范围。智能体完成当前任务究竟需要哪些信息，哪些材料只会分散注意力。范围太窄会漏掉约束，范围太宽会增加延迟和成本，也会提高错误引用的概率。

第二类是时效。文档必须带有版本、适用日期和失效条件。缺少这些元数据，模型很难区分现行规则与历史记录。

第三类是权威级别。制度文件、团队约定、个人经验和历史案例不能拥有相同权重。检索结果需要体现来源优先级，冲突时还要触发澄清或人工审批。

第四类是任务绑定。知识必须与执行步骤建立关系。把二十份文档交给智能体，让它自行判断何时使用，等于把一摞制度放到新员工桌上，然后要求他当天独立处理高风险业务。

上下文管理本身就是管理工作。它对应人类组织中的培训、制度建设和岗位说明。

企业在这里还会遇到政治阻力。

熟练员工掌握的独门知识，往往构成他在组织中的议价能力。让他把这些知识结构化地交给 AI，等于要求他亲手降低自身稀缺性。员工可能口头支持，实际只提交表层流程；关键判断仍保留在脑中，文档写得正确却无法操作。

靠宣传无法解决这种冲突。

知识沉淀必须进入正式职责，并与岗位价值重新绑定。贡献高质量规则、案例和评估集的人，需要获得与业务产出相当的认可。否则，组织一边要求员工共享知识，一边继续按照「不可替代程度」奖励个人，制度会驱动所有人保留信息。

AI 转型推进到深处，技术阻力通常会下降，组织阻力会持续上升。

冗员变形

传统组织里的冗员不一定完全不工作。他可能参加会议、整理材料、同步状态、反复确认，把时间消耗在缺少业务增量的活动上。

智能体也能制造同类繁忙。

大量 token 用于复述任务、生成计划、解释已经执行的步骤、重写已有答案。输出篇幅持续增长，新增信息却接近于零。调用记录看起来很丰富，真正影响最终决策的内容只占很小一部分。

「八成 token 什么都没做」虽然带有夸张色彩，却很接近许多智能体工作流的结构性问题。

衡量 token 效率不能只看输入输出数量。更合适的单位是有效决策增量：一次调用是否增加了新证据，是否排除了一个错误方向，是否完成了可验证的执行动作，是否降低了后续人工判断成本。

如果一轮调用没有完成以上任何一项，它大概率属于计算冗员。

企业很容易用平均调用成本掩盖这个问题。单次模型调用足够便宜时，团队会觉得多跑几轮无所谓。规模扩大后，浪费会在三个方向累积：直接推理成本、任务延迟，以及人工审查负担。

第三项经常被忽略。

智能体每多生成一份结果，人就多承担一份潜在验收工作。机器吞吐量可以在短时间扩大几十倍，人的审查能力没有同步扩张。最终形成新的队列：模型输出堆积，员工随机抽查，错误在未被发现的情况下进入下游。

这时再增加智能体，只会继续扩大待验收库存。

需要被放大的，是能够显著改变结果的「100 倍 token」。某次调用拿到了决定性证据，识别了关键矛盾，修正了任务边界，或者发现了会导致整条工作流失败的风险。这类调用数量很少，贡献却远高于普通生成。

寻找它们依赖调用追踪和结果归因。

每个工作流至少要记录：调用目的、输入来源、使用工具、产生的新信息、对最终结果的影响、失败类型以及人工修改位置。没有这套记录，团队只能看到账单和最终文本，无法分辨哪些调用有效，哪些调用只是增加长度。

这类似分析一个大型团队。只看员工人数和工作时长，无法判断组织效率。必须知道关键决策在哪里发生，哪些岗位形成瓶颈，哪些汇报关系制造重复劳动。

评估先行

管理智能体最有效的抓手是评估标准，也就是 evals。

编程成为 AI 当前最成功的应用场景，与代码天然具备可评估性有很大关系。程序可以编译或运行，测试可以通过或失败，性能可以测量，回归可以复现。模型生成的内容即使风格不同，也能被放入相对稳定的验证框架。

大量业务任务没有这种便利。

「研究一家企业」怎样算完成？

「生成高质量销售线索」中的高质量由谁定义？

「完成合同审查」需要发现哪些类型的风险？

「总结客户需求」允许遗漏哪些内容，又绝不能遗漏哪些内容？

企业如果不能回答这些问题，智能体也无法稳定交付。

很多团队先建设工作流，最后才补评估。他们把模型、检索、工具调用和记忆系统连接起来，跑出一批结果，然后组织专家凭感觉打分。几个版本之后，专家标准发生变化，历史结果无法比较，模型优化也失去方向。

评估应该早于大规模自动化。

任务进入智能体系统之前，先定义成功条件、失败类型和风险边界。评估集需要覆盖常规案例、边界案例、冲突信息、缺失信息以及必须拒绝处理的情况。只有理想样本的评估集，会把系统训练成演示环境里的优秀员工。

一个可用的评估体系至少分成四层。

第一层检查任务完成度。要求提取的字段是否齐全，要求执行的动作是否发生，输出格式是否符合下游接口。

第二层检查事实和证据。结论能否追溯到输入材料，引用是否支持对应判断，模型有没有用常识填补数据缺口。

第三层检查业务质量。结果是否符合领域规则，是否覆盖关键风险，是否达到能够进入下一流程的标准。

第四层检查运行效率。完成任务使用了多少 token、多少工具调用、多少时间，发生了多少次重试，人工修改比例是多少。

只评结果质量，系统可能通过十倍成本换取一点点效果提升。只评成本，系统又会通过减少分析步骤制造隐蔽错误。质量、成本和风险必须放在同一套评估里。

评估标准也不能永久固定。业务规则会变化，模型行为会变化，工具返回的数据结构也会变化。每次线上事故都应转化成新的评估案例。没有进入评估集的事故，后续很可能以相似形式再次出现。

这与人类团队的管理方式一致。OKR、质量标准、事故复盘和晋升要求，共同塑造员工行为。只给方向、不定义验收，最后只能依赖主管逐项盯人。

智能体同样需要制度化约束。

思想主权

AI 编程带来的另一个变化，是程序员的工作重心开始从逐行控制代码迁移到控制软件背后的想法。

模型一天能够生成数千行代码。开发者逐行审查全部输出，时间上已经不可行。即使坚持审完，也容易陷入局部细节：命名是否顺眼，函数是否拆得足够小，某段逻辑是否符合个人风格。

这些问题仍有价值，只是优先级下降了。

大模型擅长局部实现。给出清晰边界后，它可以完成函数、接口和测试，也能按照反馈快速调整。它对整体设计的把握更不稳定，尤其容易在多个局部合理选择之间拼出一个整体失衡的系统。

程序员必须控制设计意图。

数据结构为什么这样选择，状态由谁拥有，哪些不变量必须维持，失败后怎样恢复，性能目标是什么，哪些路径允许降级，哪些行为属于系统禁区。这些内容如果只存在于开发者脑中，AI 会用自己的概率偏好填补空白。

结果可能能运行，也可能通过局部测试，却难以演进。

控制思想要求开发者拥有足够深的系统理解。他需要判断某种设计会怎样影响内存布局、并发行为、故障边界和长期维护成本。只会写提示词无法完成这项工作。

vibe coding 最大的问题不在生成速度，而在责任链断裂。使用者描述一个模糊目标，模型生成实现，程序恰好能够运行，于是产物被视为完成。系统内部怎样工作、错误会在哪里积累、性能上限由什么决定，没有人掌控。

这种开发方式可以用于低风险原型。进入长期维护或高性能系统后，代价会快速暴露。需求变化一次，开发者无法判断应该修改哪一层；性能下降时，也不知道问题来自算法、数据结构还是调用关系。每次修改只能继续依赖模型猜测，系统逐步变成无人理解的代码堆积。

antirez 在开发本地 LLM 推理软件 DwarfStar 时，面对的是大量细微且会累积的错误。这类项目不能只看单个函数是否合理。一个局部误差、一处内存选择、一个数据结构上的偏差，都可能沿执行路径放大。

AI 在严谨设计和测试中可以提供很大帮助。前提是人掌握系统意图，知道该要求 AI 验证什么，也知道哪些结果不能接受。

代码审查也需要重新分配精力。

对于 Redis 这类大量用户会直接阅读和修改源码的项目，保持代码质量是对用户的尊重。审查仍然有意义。但如果开发者把全部时间用在检查每一行 AI 输出，QA、性能分析和下一步设计就会被挤压。

有限的人力应该优先投入故障模式、系统不变量、边界条件、性能退化和可维护性。代码风格可以交给自动化工具，重复性实现可以交给模型，局部错误可以由测试覆盖。设计责任无法外包。

设计文档

DESIGN.md 在 AI 编程环境中的地位会持续上升。

过去很多设计文档写于项目启动阶段，代码落地后很快过期。开发者最终以代码为准，文档只保留历史价值。AI 参与开发后，设计文档需要变成持续维护的系统接口。

它应该描述每个数据结构承担什么职责，关键实现技巧服务于什么目标，模块之间怎样协作，哪些不变量不能破坏，以及修改某部分时需要同步检查哪些路径。

模型阅读这样的文档，才能在修改代码前获取设计约束。当我们接手项目时，也可以先理解系统思想，再进入具体实现。

这并不意味着文档越长越好。把代码换成自然语言复述，价值很低。有效文档集中解释代码无法自行表达的内容：为什么选择这个方案，放弃了哪些方案，哪些行为依赖隐含前提，哪些性能特征必须保持。

文档还要进入变更流程。

如果代码改动影响数据结构、状态模型或失败处理，设计文档必须同步更新。评审时需要检查实现与文档是否一致。否则，AI 会依据旧设计修改新代码，错误会披着「遵循项目规范」的外衣进入系统。

设计文档可以视为给未来开发者和未来智能体准备的上下文。它承担组织记忆，减少关键思想只存在于少数人脑中的风险。

企业业务流程也需要同类文档。

流程说明不能停留在步骤列表。它要写清每一步的目标、输入、输出、判断依据、异常路径、升级条件和验收标准。只有这样，智能体才有可能承担稳定执行。

很多所谓 AI 落地难题，本质上暴露了企业从未把业务讲清楚。过去依赖熟练员工临场判断，这些模糊地带被人的经验掩盖。模型进入流程后，所有未定义部分同时暴露出来。

AI 没有制造这些混乱。它提高了混乱被复制的速度。

人的边界

AI 可以承担高吞吐的搜索、执行、分析和记忆管理。

搜索适合机器，因为它能在大量材料中并行查找候选信息；执行适合机器，因为重复流程可以被稳定调用；分析可以由机器生成多个假设和比较维度；记忆管理则可以通过检索、归档和关联降低人脑负担。

人需要保留四项责任：问题定义、歧义处理、风险判断和最终验收。

问题定义决定系统优化什么。目标写错，后续所有高效执行都会扩大偏差。

歧义处理决定何时允许模型自行推断，何时必须暂停并提问。完全禁止推断会让工作流频繁中断，完全开放推断又会把隐含假设带入结果。工程上应根据风险分级：低风险、可逆操作可以允许模型补全；高风险、不可逆操作必须要求显式确认。

风险判断需要结合业务后果。模型可以列出风险，却无法替组织承担责任。同样的错误，在内部草稿里可能只需重新生成，在合同、资金、生产系统和对外承诺中，影响完全不同。

最终验收意味着人要对结果负责。验收不能退化成快速扫一眼。模型输出量超过人的审查能力时，系统应限制吞吐量、增加自动评估或降低自动化范围。堆积大量无人验收的输出，没有形成生产力，只是形成了信息库存。

人机分工也不应按照「模型能做什么」设计。这个问题会随着模型升级不断变化。更稳定的划分方式是看责任和可验证性。

可验证、可回滚、低风险的任务，可以给智能体更大自治权。

结果可验证但动作难以回滚时，应增加审批点。

结果难以完整验证、错误影响又高的任务，AI 更适合作为分析和建议工具。

这套边界需要写进系统权限。只靠提示词要求模型谨慎，约束强度远远不够。工具层要限制可调用范围，工作流层要设置审批，运行层要保留审计记录，评估层要持续检查越权行为。

提示词属于沟通机制。权限系统才承担治理责任。

年轻工程师

我对年轻程序员是有些担心的，并非担心他们使用 AI，而是他们在建立心智模型之前就把实现过程全部交给 AI。

一个人没有亲手实现过解释器、数据库或哈希表，很难判断模型生成的实现在哪些地方存在结构性问题。他可能读得懂语法，也能运行测试，但无法推演数据怎样流动、状态怎样变化、性能为什么退化。

核对 AI 输出不能替代基础训练。

逐行检查一段自己并不理解的代码，只会制造虚假的参与感。更有效的训练方式是亲手实现规模受控的系统，遇到内存、并发、解析、索引和错误恢复问题，再用 AI 帮助验证思路、补充测试、寻找遗漏。

基础能力的价值还会上升。

代码生成越来越便宜以后，企业不会继续为普通代码行支付高溢价。能够定义系统、识别风险、设计评估、分析性能和承担技术决策的人，会掌握更大的杠杆。

年轻工程师如果只学习怎样让模型快速产出，能力会紧贴当前工具。模型更新一次，原有技巧可能迅速贬值。数据结构、操作系统、网络、数据库和编程语言建立的心智模型变化慢得多，它们决定一个人能否判断 AI 给出的方案。

高级工程师也不能因此停留在旧习惯里。

坚持所有代码都必须人工逐行编写，会把大量时间消耗在机器已经可以低成本完成的工作上。经验应该投入架构、约束、验证和复杂问题拆解。继续用代码行数证明专业性，和管理者用团队人数证明影响力没有太大差别。

管理重构

企业引入 AI 时，组织结构也要调整。

过去，一个经理管理十几个人已经接近沟通上限。未来，每个员工都可能拥有大量智能体。管理对象数量突然扩张，个人需要具备过去只有管理者才需要的能力：拆解任务、定义结果、提供上下文、设置检查点和处理异常。

工程师会越来越像技术经理。经理则需要理解评估、权限、成本和模型行为，单靠资源协调很难管理智能体劳动力。

团队流程也会变化。

需求评审需要增加可评估性检查。一个需求如果无法写出验收条件，进入智能体工作流后只会制造更多不确定输出。

架构评审需要关注智能体权限、上下文来源和失败路径。模型调用成功不等于业务任务成功，工具返回正常也不等于动作合理。

上线评审需要检查成本上限和停止条件。任何允许递归、自我调用或动态扩展任务的系统，都必须有预算约束。

事故复盘需要分析模型为什么做出对应行为，输入中缺少了什么，评估为什么没有拦截，以及权限设计是否允许错误继续扩大。把问题归结为「模型偶尔会犯错」，相当于铁路事故后只说机车存在风险。

采购更强的模型可能提升基线能力，却不会补齐管理缺口。模型越强，执行范围越大，错误的影响半径也越大。

AI 项目的成熟度最终会体现在几个问题上：

1. 团队能否精确描述智能体负责的任务？
2. 能否量化什么叫完成？
3. 能否追溯结论来自哪些输入？
4. 能否限制循环、重试和预算？
5. 能否知道哪些 token 改变了结果？
6. 能否在高风险动作前强制人工介入？
7. 能否把线上失败转化成评估案例？
8. 能否让设计思想脱离个人记忆，进入可维护的组织资产？

这些问题回答不出来，再复杂的智能体架构也只是一次昂贵的演示。

铁路时代的企业最终学会了管理速度、规模和复杂性。AI 时代需要处理的是概率行为、无限执行能力和有限人类判断之间的冲突。

我们已经拥有了数量近乎无限的数字员工。它们勤奋、便宜、速度极快，也缺少组织记忆、责任意识和稳定判断。

接下来的工作落在人身上：把问题讲清楚，把标准写出来，把权限收紧，把思想保存下来，对最后的结果签字。

这些都是基于当前模型能力和个人认知所作出的判断，随着时间的推移，也可能会涌现其它我当前所认知不到的，那又将是另一个世界。

以上。

我已经很久没有沉浸式写代码了。

以前碰到一个复杂问题，我会花几个小时读调用链、画状态变化、跟踪异常路径。刚开始很慢，脑子里只有一些零散信息。随着上下文逐渐完整，代码会形成一张连续的结构图。再往后写，很多判断不需要反复查找，心流也就出现了。

现在的工作节奏完全变了。

我先给 Agent 描述需求，等它执行。等待期间又觉得空着可惜，于是打开第二个窗口，让另一个 Agent 补测试。看到还有时间，再开第三个任务处理重构。

十几分钟后，几个 Agent 陆续返回结果。我开始查看摘要、检查 diff、运行测试、补充要求、处理冲突。一个任务还没看完，另一个任务已经弹出完成通知。

一天下来，代码生成了很多，我却很少在同一个问题里连续停留半小时。

心流没了

Vibe Coding 最先改变的是注意力结构。

写代码原本是一种连续活动。理解需求、寻找入口、建立模型、设计实现、发现问题、修正判断，这些环节彼此相连。Agent 把它切成了很多轮对话：描述任务，等待结果，检查结果，再描述下一步。

每轮都很快，每轮都带来一点进度。

大脑很容易适应这种高频反馈。问题一旦需要长时间推演，我就会产生阻力。以前遇到难点，会继续读代码、查日志、进调试器。现在的第一反应经常是把问题发给 Agent，让它先分析一下。

思考开始变得外包化。

这不会让工程师立刻失去能力。更常见的变化是耐心下降。看十分钟调用链就想问 AI，调试几次没有结果就想换提示词，设计还没收敛就开始生成代码。

慢思考越来越难维持。

复杂工程问题偏偏依赖这种能力。并发状态、数据一致性、故障恢复和性能瓶颈，很少能靠几轮快速问答解决。它们需要人在同一套上下文里待得足够久，直到各种局部信息连成一体。

Agent 使用频率越高，我越忙，也越难进入这种状态。

Token 焦虑

额度快用完会焦虑，这很正常。额度没用完也会焦虑，就就有点奇怪了。

买了订阅，看到 token 还剩很多，会产生一种浪费感。离开工位之前，总想再布置一个任务。准备去开会，让 Agent 先跑一轮测试；准备吃饭，让它顺手整理模块；睡觉之前更容易上头，总觉得应该给 AI 加个通宵夜班。

真的是如群友所说：床前 token 光。

这种焦虑会慢慢改变任务优先级。原本没有必要立即处理的工作，因为 Agent 正好空闲，被提前塞进了队列。需求还没有想清楚，先做一个版本看看；某段代码虽然还能维护，先让 Agent 重构一下；测试已经够用，再补几十个用例似乎也没坏处。

Agent 忙起来了，人的待验收任务也堆起来了。

第二天早上打开电脑，几个任务全部显示完成。看起来像是白捡了一夜生产力。仔细检查才会发现，每个结果都需要重新加载上下文，都要判断实现边界，还要验证它有没有把局部问题扩展成新的抽象。

AI 上完夜班，我们开始加班验收。

更麻烦的是，等待结果本身也会占据注意力。人已经离开电脑，脑子里还惦记着任务有没有跑完、会不会失败、明天要看多少改动。休息时间变成了一段漫长的异步等待。

越用越累

刚开始用 Vibe Coding，我以为自己会轻松很多。实际体验是产出提高以后，疲惫感也跟着上升。

过去一天写两百行关键代码，我基本知道每一行为什么存在。现在几个 Agent 可以快速生成几千行改动。我的工作量没有消失，它从编写转移到了理解、判断和验收。

生成可以并行，理解通常只能串行。

一个 Agent 修改接口，一个 Agent 补充测试，另一个 Agent 调整调用方。它们各自都能完成任务，最后所有结果汇集到我这里。我需要判断接口语义有没有变化，测试是否沿用了错误假设，调用方有没有掩盖异常，几个改动能否同时成立。

机器的带宽增加了，人的带宽没有同步扩展。

当输出超过处理能力，审核质量会自然下降。最初还会逐行看 diff，后来只看摘要；最初会认真检查测试内容，后来看到绿色就继续；最初要求自己理解每个关键决策，后来开始依赖 Agent 提供的变更说明。

疲惫带来的危险，很少表现为明显的错误决定。它更像一种缓慢降低的验收标准。

每一次都只少看一点，每一次都觉得风险可控。几个月以后，代码库里已经出现大量没人完整理解的实现。

不想 review

我现在越来越不想看 AI 写的代码。

人工审核 AI 代码，有时比自己重写还累。自己写代码时，设计过程和实现过程是连续的。我知道哪些地方经过权衡，哪些地方只是临时处理，哪些假设需要后续验证。

面对 AI 生成的代码，这些上下文都要重新推导。

最让人疲惫的代码，往往还写得挺像样。命名规范，结构完整，注释齐全，测试也有。逐段看都有合理性，放回整个系统却经常显得多余。

一个边界条件被扩展成通用框架，一次局部修复引入新的中间层，三个表面相似的流程被强行抽象到一起。代码能运行，测试也能通过，但维护成本被悄悄推高了。

审核者需要花很大力气，才能解释为什么一份「正确」的代码不适合进入当前系统。

重复几次以后，人会开始逃避。既然测试过了，先合进去。出了问题，再让 Agent 修。下一次 Agent 又基于上一次生成的结构继续扩展，代码越来越多，理解越来越少。

最后会出现一种荒诞状态：人不愿意维护 AI 写的代码，于是继续让 AI 维护。

理解变浅

亲手写代码的过程，本身也是建立系统认知的过程。

为了实现一个功能，我需要找到入口，理解依赖，处理编译错误，观察测试失败，再确认数据如何穿过整个链路。实现完成以后，我对这部分系统已经形成了自己的判断。

Vibe Coding 跳过了其中大量过程。

Agent 告诉我改了哪些文件、采用了什么方案、测试结果如何。我可以很快获得一份完整说明，却没有经历那些失败、试探和修正。知道结果，与掌握系统之间，仍然隔着很长一段距离。

这种认知缺口在日常迭代中不容易暴露。Agent 还能继续修改，功能也能继续上线。等到线上故障、复杂重构或性能退化时，团队需要在压力下定位根因，欠下的理解成本才会集中出现。

每个人都参与过系统开发，问到关键链路却只能讲出局部。继续追问异常如何传播、数据如何恢复、容量边界在哪里，回答逐渐变成「让 Agent 分析一下」。

工具还在，工作可以继续。工程师对系统的控制感却在下降。

调度上瘾

多 Agent 会带来很强的生产感。

屏幕上同时跑着几个任务，状态不断变化，代码持续生成。即使我没有处理最困难的问题，也会觉得今天推进了很多工作。

这种感觉很容易上瘾。

我开始热衷于拆任务、写提示词、查看进度、追加要求。一天都在操作，一天都没有停下来。到了晚上，任务列表关闭了不少，却很难指出自己完成了哪段连续思考。

技术管理者更容易陷进去。我们的时间本来就被会议、消息和协作切碎，Agent 又提供了一种产出感很强的碎片化工作。它比回复消息更像研发，比真正做架构设计轻松，还能持续制造「事情正在推进」的反馈。

久而久之，启动任务替代了处理问题，完成数量替代了工程质量。

代码还在，人却远了

Vibe Coding 让我写得更快，也让我离代码更远。

这种距离很难通过提交数量看出来。功能持续上线，测试数量持续增加，仓库每天都很活跃。只有在关掉 Agent、独自面对系统时，才能感受到变化。

我还能不能连续读一小时代码？

能不能在没有摘要的情况下说清楚一次变更？

能不能独立判断某个抽象该不该存在？

线上出问题时，我脑子里有没有完整的执行链路？

这些问题比 token 使用量更让我焦虑。

我仍然每天使用 Vibe Coding，也很难再回到完全手写的状态。它确实提高了生产速度，只是这份速度附带了一组后遗症：心流消失、注意力碎片化、token 焦虑、审核疲劳、理解变浅，以及对调度和即时反馈的依赖。

以前写代码会累，累在实现。

现在也累，累在持续接收、持续判断、持续验收。机器一直在输出，我的大脑一直没有真正下班。

以上。

比较常见的状态是知识走一条 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 一旦开始承担任务，它需要的就不再是几个看起来相关的文本块，而是一条能走通、能解释、能复核的知识路径。

以上。