Session First 和 Agent First，本身并没有高低之分

最近在思考一个问题：系统究竟把谁当成第一类公民。

现在我们看到很多的 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 里，能力组织方式通常是这样的：

先有一个大而全的聊天入口；
再有一组工具函数；
再在 system prompt 或 tool spec 里告诉模型什么时候调用它们；
复杂任务靠更长的上下文、更复杂的提示词、更精细的 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 理解和执行设计的。

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

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

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

这样写出来的文档，对人读可能不友好，但对 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 发展太快了，回望去年的这个时候，我们写代码的方式还不一样，问问题的方式还不一样。

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

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

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

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

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

那应该在哪里慢呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 变成持续生产力。

以上。