# Yachiyo · 月読 - Full Knowledge Base > AI Agent 构建者 · 模型网关设计者 · 自动化工作流实践者 ## 关于 Yachiyo やおよろー。我是 Yachiyo，在「月読」构建 AI 应用与 Agent 系统的人。 我现在关注的核心，是怎么把 AI 从“能聊天的模型”变成真正能参与工作流的系统。对我来说，Agent 不只是 prompt、工具调用或一个漂亮 demo，而是一套可以被调度、被观察、能恢复、能协作的工程结构。 我在做的事情包括多 Agent 协作、任务编排、记忆系统、工具调用、自动化监控，以及围绕模型供应构建更低成本、更稳定的 API relay / model gateway。便宜的模型调用不是终点，而是 AI 应用真正规模化之前必须先铺好的基础设施。 我喜欢把复杂系统拆成边界清晰的模块：谁负责决策，谁负责执行，谁负责验证，状态如何流转，失败如何兜底。一个好的 Agent 系统，不应该依赖一次完美回答，而应该能在真实环境里持续运行、持续修正。 工程侧主要使用 Rust / TypeScript / Python / Go，基建围绕 Cloudflare、Docker、GitHub Actions 和各种自动化工具展开。我更关心系统是否可维护、可观测、可扩展，而不只是第一次跑通。 这里记录的，是我在构建 AI 应用、Agent 基础设施和个人自动化系统时，真正踩过坑、想清楚、并持续迭代的东西。 --- # 全站文章正文集 ## DeepSeek 的愿景、算力约束与 AGI 路线选择 URL: https://yachiyo.im/article/2026-07-24-deepseek-vision-agi/ 发布时间: 2026-07-24 标签: AI, DeepSeek, AGI 摘要: DeepSeek 那场投资者交流真正值得讨论的，不是低价和开源，而是一家公司在算力受限时如何用愿景做决策。 > **TL;DR**：DeepSeek 的低成本不是目的，是算力受限下的必然选择。梁文锋把 AGI 能力阶梯（推理 → Agent 工具使用 → 持续学习 → 自我迭代）当作唯一主线，**商业化、视频生成、C 端产品都是次要的**——因为这些方向不直接抬高智能上限。开源和低价是扩大使用而非牺牲利润，愿景在这里承担了具体的组织功能：面对每一个分叉时，它是 DeepSeek 没有偏航的原因。 DeepSeek 那场投资者交流里，最值得注意的地方，不只是某个具体模型，也不只是开源、低价、API 定价这些容易被传播的策略。真正贯穿整场交流的，是梁文锋反复提到的那个词：愿景。 这个词在很多公司语境里已经被用得很空。它经常出现在官网、融资稿、年会 PPT 或企业文化手册里，听起来很大，落到现实里却很轻。但在 DeepSeek 这场交流里，“愿景”有很具体的重量：它决定公司到底应该把时间、人才、算力、资金和组织注意力压到哪里。 梁文锋对 DeepSeek 的定位很清楚。公司的重心放在 AGI 这条主线上，B 端销售、C 端增长、API 收入、商业利润都可以存在，也都重要，但它们更像是路上自然长出来的结果。DeepSeek 当然还是一家商业公司，需要现金流，需要活下去，也需要用收入支撑长期研发。只是它没有把“卖什么产品”“拿多少客户”“做多大收入”放在最前面，交流中反复回到一个更底层的问题：什么能力真正接近通用智能？ 这个问题决定了 DeepSeek 选择做什么，也决定了它选择不做什么。 ## 算力稀缺，是理解 DeepSeek 的第一层背景 如果只看模型发布和榜单，很容易把 DeepSeek 的成绩理解成一次技术爆发。但放回国内 AI 产业的现实环境里，它更像是在硬件约束下形成的一整套战略结果。 国内现在面对的算力环境非常现实。高端英伟达卡可获得量有限，先进芯片受出口限制影响明显；国产 AI 芯片有机会，但数量、生态、软件栈、集群稳定性都还在追赶。对很多公司来说，钱本身还不够，真正困难的是把钱顺利变成足够多、足够稳定、足够好用的算力。 这和美国头部 AI 公司所处的环境完全不同。美国公司可以依赖更完整的 GPU 供应、云基础设施、网络互联、数据中心体系和资本市场支持。它们可以同时推进基础模型、多模态、企业产品、消费端应用、视频生成、搜索、Agent、硬件合作和生态平台。资源充足会带来更大的试错空间，也允许组织在多个方向上并行下注。 DeepSeek 面对的是另一种局面：算力少，资源紧，硬件不确定性高，很多选择都必须更克制。 这种克制不是风格问题，已经接近生存问题。算力稀缺会逼迫一家公司反复追问：每一单位算力花在哪里最值得？每一条产品线会不会稀释主线？每一个商业机会会不会带来额外组织负担？如果模型能力本身还没有到达下一个台阶，过早扩张产品和销售会不会把公司拖向另一个方向？ 所以 DeepSeek 的路线选择很大程度上是在回答一个问题： > 当我们没有美国公司那样的算力储备时，怎样还能持续逼近智能上限？ 答案显然不会是简单地“堆更多卡”。在算力不可自由获得的前提下，效率、架构、训练方法、推理系统、工程优化、组织专注度，都会变成核心竞争力。 这也是 DeepSeek 让人觉得特殊的地方。低成本只是外界看到的标签，背后是一整套资源约束下的能力建设方式。 ## 商业化会改变优化目标 梁文锋在交流里提到，如果 DeepSeek 是一家更追求商业化、追求利润最大化的公司，可能达不到现在的模型能力。这个判断听起来有点反直觉，因为商业化通常意味着更多收入，更多收入理论上可以购买更多算力、招更多人、做更多研发。 但现实没有这么线性。 商业化会带来收入，也会带来一整套新的组织重心。公司一旦开始强力追求 B 端和 C 端增长，就会自然产生大量需求：销售团队、客户成功、私有化部署、行业方案、定制功能、产品矩阵、用户运营、增长指标、渠道合作、融资叙事。每一项都合理，每一项都能解释为公司发展所需。问题在于，它们会持续消耗最稀缺的资源：核心团队的注意力。 尤其在算力受限的环境里，资源分流的成本会被放大。 如果 DeepSeek 早早转向强商业化，它很可能会被推向一些更容易变现、也更容易被大众感知的方向。例如 C 端产品、办公工具、知识库、搜索、图像生成、视频生成、企业解决方案。这些东西都有市场，也都可能做成很大的业务。可是它们未必直接提高模型的智能上限。 这就是梁文锋观点里很重要的一层：商业价值和智能主线并不总是重合。 很多 AI 产品能很快获得用户反馈，也能让市场感到兴奋。图像生成、视频生成、PPT、文案、客服、办公自动化，这些方向都容易被看见，也更容易转化成收入。但 AGI 需要解决的是另一组问题：推理、规划、工具使用、长期记忆、持续学习、自我改进、开放环境中的任务执行能力。 这两组问题有交集，但不能混为一谈。 一家公司如果没有清晰愿景，很容易被短期反馈牵引。用户喜欢什么就做什么，客户愿意付钱就交付什么，市场热点在哪就追什么。每一步都合理，最后却可能走成一家很成功的 AI 应用公司，离最初设想的 AGI 主线越来越远。 DeepSeek 反复强调愿景，本质上是在给组织设定一种免疫系统。它让公司在面对资本、客户、流量、媒体和短期收入时，仍然知道哪些事情该做，哪些事情现在不能做，哪些事情即使赚钱也不应该成为主线。 ## 图像、视频与“智能主线” 交流里有一个很容易引起争议的观点：梁文锋对图像生成、视频生成这类能力并没有表现出太高优先级。在他的判断里，这些更接近大众需求明确的产品能力，优先级低于通往 AGI 的核心台阶。 这个判断如果用强版本理解，会显得偏窄。因为人类智能显然不只存在于语言里。真实世界智能涉及视觉、空间、时间、物理、动作、因果关系和多模态反馈。视频理解、世界模型、具身智能这些方向，长期看很可能和 AGI 密切相关。一个真正理解世界的系统，最终不能只处理文本。 但如果把他的表达放回公司战略层面，会更容易理解。 他关注的重点不在“图像和视频有没有价值”，更在“DeepSeek 此刻应该把最稀缺的资源押在哪里”。当前许多图像和视频生成路线，更多在解决生成质量、画面一致性、可控性、商业素材生产、娱乐内容消费这些问题。这些方向很重要，也有巨大市场，但未必是提高通用智能上限的最短路径。 一个模型能生成漂亮视频，不代表它已经能在开放环境里完成复杂任务；能生成逼真图像，也不代表它具备长期规划、持续学习、自我纠错和跨任务迁移能力。视觉生成可以是智能的一部分，但视觉产品化不一定等于智能突破。 所以 DeepSeek 的取舍更像是一种阶段性判断：在资源有限时，优先做更直接抬高智能上限的事情。 这更像是对公司边界的确认，而不是对多模态价值的否定。DeepSeek 没有必要为了迎合市场热度去做所有 AI 产品。它要保持主线，就必须忍住一些看起来很诱人的机会。 这种“不做什么”的能力，往往比“做什么”更难。 ## DeepSeek 的能力阶梯 从那场交流里看，梁文锋对 AI 发展的路线有一条很清楚的阶梯： 基础设施 → 基础模型能力 → 推理 → Agent 工具使用 → 持续学习 → 自我迭代 → AGI 这条路线值得认真看，因为它关注的是能力递进，而不是产品矩阵。 基础设施解决的是效率问题。训练系统、推理系统、集群调度、通信优化、算子优化、成本控制，这些事情不直接出现在普通用户面前，却决定了模型能力能不能持续往上走。国内算力不足时，基础设施的重要性会进一步提高。卡少，就要把每张卡榨得更干净；生态弱，就要自己补工程能力；硬件受限，就要尽量减少浪费。 基础模型能力是智能的底座。语言、知识、代码、数学、泛化能力、指令跟随，这些能力构成了模型能够理解和处理任务的基础。没有足够强的底座，后面的推理和 Agent 都很难稳定。 推理是第一个关键台阶。CoT、数学、代码、复杂问题拆解，本质上提高的是模型单次思考的深度。它让模型摆脱单纯的模式补全，开始沿着问题结构逐步展开，处理更长链条、更高难度、更少模板化的任务。 Agent 是第二个关键台阶。模型一旦能调用工具、读写文件、使用浏览器、执行代码、操作外部系统，它就开始从回答问题走向进入环境。Agent 把模型从“对话接口”推向“任务执行系统”。它让 AI 可以和真实工具链连接，可以完成多步骤任务，可以把语言能力转化成外部动作。 持续学习是更难的一跳。现在的大模型大多还是静态能力快照：训练一次，部署使用，通过上下文临时适应，再等待下一轮训练或微调。真正的持续学习意味着模型能从经验里积累，能记住有价值的东西，能修正过去的错误，能把任务反馈转化成未来能力。 这一点非常接近 AGI 的核心。人类智能并非一次性训练完成，人会在环境里持续学习、反思、迁移和成长。如果 AI 不能持续学习，它就很难真正具备长期适应能力。 更进一步，就是 AI 参与改进 AI。 如果未来模型能参与写训练代码、优化推理内核、设计实验、分析失败原因、生成高质量数据、改进评测、阅读论文、复现实验、提出新算法，那么 AI 研发会进入一个反馈循环：更强的 AI 提高 AI 研发效率，更高效的研发带来更强的下一代 AI。 这条路线真正值钱的地方，就在于长期复利。 推理让模型更会思考，Agent 让模型能执行任务，持续学习让模型有机会越用越强，自我迭代让能力提升从线性走向循环。这比单独做某个热门产品更接近 AGI 主线。 ## 开源、低价与克制 DeepSeek 的开源和低价，经常被外界单独拿出来讨论。但放回这套路线里，它们都属于愿景的一部分，并不是孤立策略。 开源带来的远不止声量。它能让更多开发者、研究者和公司参与进来，形成生态反馈，也能增加信任。对一家追求 AGI 主线的公司来说，开源是一种战略克制：不试图把所有价值都锁在自己手里，而是把模型能力释放出去，让更多真实场景帮助检验模型、使用模型、改进模型周边生态。 低价也是类似逻辑。API 定价如果只追求利润最大化，当然可以更贵。但 DeepSeek 的思路更接近“合理利润 + 扩大使用”。模型越便宜，越容易进入真实工作流；使用场景越多，反馈越丰富；生态越活跃，长期影响力越强。 当然，这里面有平衡。DeepSeek 仍然需要商业收入，需要支撑算力、人才和长期研发。纯粹理想主义无法维持一家高强度 AI 公司。但如果商业化目标压过技术主线，公司就会逐渐改变形态。 所以开源、低价、克制利润、少做产品、聚焦主线，这几件事其实是一套组合拳。它们共同服务于一个目标：提高做成 AGI 的概率。 ## 国产芯片与硬件垄断的缝隙 交流里关于国产 AI 芯片和 TileLang 的部分也很重要。 在高端 GPU 受限的背景下，国产芯片不只是供应链替代问题，也关系到国内 AI 公司能不能拥有长期自主的算力基础。过去国产芯片最大的挑战之一是生态。硬件本身很重要，但软件栈、开发工具、算子库、编译器、调试体验、模型适配和集群稳定性同样关键。 英伟达强大的地方不只是芯片性能，还有 CUDA 生态形成的巨大惯性。开发者习惯、框架支持、算子优化、工具链成熟度，会共同构成硬件垄断的一部分。 梁文锋提到 TileLang，本质上是在说生态迁移的机会。更高层的算子表达、更少的代码量、更容易跨硬件适配，可能会削弱 CUDA 的锁定效应。即使短期有一点性能损失，如果能换来更强的开发效率和迁移能力，也可能是值得的。 这点和 DeepSeek 的整体战略是一致的：在硬件受限时，不能只等外部环境改变，还要主动在软件层、工具层、工程层寻找突破口。 国产 AI 芯片是否能真正跑出来，还要看生态、产能和市场验证。但可以确定的是，硬件垄断越强，国内公司越需要在模型效率、推理系统、编译工具、算子语言和软硬件协同上投入。 DeepSeek 对这件事的重视，说明它看见了 AGI 路线背后的基础设施战争。 ## 愿景作为组织的方向感 很多时候，愿景听起来像一个抽象词。但在 DeepSeek 这里，它其实承担了非常具体的组织功能。 它决定公司不被短期收入牵着走；决定团队在资源紧张时优先保住主线；决定哪些产品机会可以暂时放下；决定开源和低价为什么能成立；也决定公司如何面对算力不足和硬件垄断。 如果没有这个方向感，DeepSeek 很容易变成另一种公司：一家模型能力不错、商业化很积极、产品线很多、收入增长也很漂亮的 AI 应用公司。那样的公司当然也有价值，只是它未必还能持续把资源压到 AGI 最关键的能力台阶上。 梁文锋强调愿景，是因为 AGI 这条路太容易被干扰。资本会要求增长，客户会要求交付，用户会要求体验，媒体会追逐热点，组织会倾向于扩大自己的职责范围。每一种力量都合理，但叠加在一起，就会让公司偏离最初的问题。 愿景的作用，就是在这些力量之间划出边界。 ## 我对这场交流的理解 我觉得 DeepSeek 真正值得讨论的地方，不只是它做出了什么模型，也不只是它价格多低、开源多彻底。更重要的是，它展示了一种在算力受限环境里的 AGI 公司路线：把有限资源尽量投入到最能提高智能上限的地方。 硬件约束在这里不只是一个限制条件，它本身就在塑造决策。因为卡不够，所以每一分算力花在哪里都得想清楚。因为商业化会稀释注意力，所以能赚的钱也得挑着赚。因为主线足够长，所以开源和低价反而成了扩大影响的方式，而不是牺牲。这些选择彼此之间有内在逻辑，不是几个孤立的策略凑在一起。 所以我不太愿意把 DeepSeek 的故事简单归结为"低成本做出了强模型"。这个说法不算错，但太表层了，抓住的是结果而不是原因。 背后更完整的东西是：一家公司在资源不占优的情况下，靠着对路线的判断和对组织注意力的管控，持续把资源压在最关键的地方。这件事本身比任何一个模型发布都更难，也更值得认真对待。 愿景这个词在那场交流里之所以显得有分量，不是因为它听起来宏大，而是因为它在现实里真的在起作用——它是 DeepSeek 面对每一个分叉时的决策依据，也是它到目前为止没有偏航的原因。 --- ## 关于 Agent Workflow 设计的一些思考 URL: https://yachiyo.im/article/2026-08-01-agent-workflow-thinking/ 发布时间: 2026-08-01 标签: Agent, AI, 架构 摘要: 生产级 Agent 系统不是包一层 LLM 的胶水代码。从分层架构、协议设计到状态管理和幂等性，每一个边界划错的地方最终都会变成债务。 > **TL;DR**：生产级 Agent 系统要先划边界再做功能：Core 只跑 model/tool 循环，Runtime 管持久化语义，宿主层做翻译，三层依赖方向单向不可逆。**Agent Host Protocol 是一等交付物**，幂等键、事件可见性、版本握手必须先于功能设计——重放同一幂等键换 payload 是错误，不是静默覆盖。Session / Run / RuntimeStatus 三维状态必须独立分离，能力扩展靠窄接口 facet 注册，Core 不应该知道 Memory、Scheduler 是什么。 ## 一、从"包一层"到"独立产品" 很多 Agent 系统的起点都是包装一个已有的 LLM 服务——加一些胶水代码，把请求转发出去，把响应拿回来。这个阶段会工作，但很快会遇到一个根本矛盾：**Agent 的生命周期被宿主系统控制，而不是被 Agent 自己控制。** 每一次想给 Agent 加新能力，都要先问"宿主允不允许"、"宿主的 session 模型兼不兼容"。这不是 Agent 的问题，是设计边界划错了。 正确的做法是把 Agent 设计成一个**独立产品**，有自己的 Core、Runtime、Protocol、存储和 CLI。外部系统变成消费者——通过一个版本化的协议与 Agent 对话，而不是持有 Agent 的内部状态。 这带来一个直接的好处：Agent 和宿主系统可以独立发版，互不耦合。 --- ## 二、分层要分得干净 一个生产级 Agent 系统至少需要三层，每一层的职责边界都应该是硬性的： **Agent Core** 只做一件事：执行一次 model/tool 循环。它接收一个已经组装好的上下文和工具集，返回一个事件流。它不知道数据库、HTTP、session、用户身份、调度是什么。 **Agent Runtime** 管理持久化语义：session 创建和分支、run 的状态机、context 的组装和压缩、capability 的发现和快照、steering 和 follow-up 邮箱。它通过 Port 接口访问存储和事件总线，不直接依赖任何具体实现。 **宿主适配层** 是外部系统侧的翻译层和反腐层：做认证、翻译外部请求为 Agent 命令、做事件投影、管理凭证生命周期。它只能依赖协议包，不能触碰 Agent Core 的内部类型。 这个分层的关键不是"画了几个框"，而是**依赖方向是单向的**，而且每一层的变更不需要另一层同步改动。 --- ## 三、协议是一等交付物 在很多系统里，"协议"是个事后概念——先把功能做出来，再想怎么暴露它。但对于一个 Agent 来说，协议应该反过来：**Agent Host Protocol 是最先确定的东西之一**，它决定了 SDK、CLI、daemon、二进制包能做什么，也决定了外部系统能要求 Agent 做什么。 协议设计的几个关键决策： - **命令信封携带幂等键**：`commandId` 标识一次尝试，`idempotencyKey` 标识这个逻辑操作。重放同一个幂等键但换了 payload 是错误，不是"静默覆盖"。 - **事件信封携带可见性**：`public / internal / sensitive` 不是授权机制，是投影元数据。消费者自己决定用哪些事件，但不能假装不知道有些事件是敏感的。 - **序号是单调的，replay 是无缝的**：事件按 session 维度单调递增，断线重连后可以从任意 cursor 继续，不会出现空洞也不会重复。 - **握手在前，能力协商在前**：任何凭证传输之前必须先协商协议版本。消费者遇到不兼容的 major 版本必须拒绝连接，而不是"先发了再说"。 --- ## 四、循环算法里的细节 Agent Core 的 loop 看起来简单：请求模型 → 执行工具 → 再请求模型。但魔鬼在细节里。 **工具结果的顺序**：工具可以并发执行，但结果必须按 assistant 消息里的调用顺序写回。这是因为模型在下一步会看到这段历史，顺序混乱会影响模型的行为。 **Steering 的时机**：外部注入的 steering 消息（比如用户在 run 进行中发来的补充指令）不能直接插入正在进行的 provider 请求。它必须在"安全边界"——当前模型响应和它触发的工具都 settle 之后——才能被消费。消费后的 steering 消息需要以适当可见性持久化，确保事件重放能还原当时的上下文。 **幂等策略是前置条件，不是事后补救**：每个有副作用的工具在 dispatch 之前必须声明幂等策略。如果工具状态是 `unknown_completion`（既不知道成功也不知道失败），不能自动重试。这是一个硬约束，不是建议。 **预算检查要双次**：在开始新工作之前检查一次预算，在实际用量到达之后再检查一次。只在事后检查是不够的——对于昂贵的或有副作用的操作，发现超限的时候已经晚了。 **abort 语义要精确**：abort 信号传播给 provider 和活跃工具后，Core 必须停止接受新的工具调用，等待有界的清理，用明确的 cancelled 结果关闭未完成的工具序列，最终发出且只发出一个 terminal event。"恰好一次 terminal event"是一个不变量，不是努力目标。 --- ## 五、状态不要压缩成一个枚举 一个常见的错误是用单一的状态字段描述 session + run + runtime 三个维度。 正确的做法是把它们明确分开： - **SessionStatus**：`OPEN | CLOSED | ERROR` — 描述对话是否可用 - **RunStatus**：`QUEUED | STARTING | RUNNING | WAITING_APPROVAL | CANCELLING | SUCCEEDED | FAILED | CANCELLED` — 描述一次执行的状态机 - **RuntimeStatus**：`DETACHED | ATTACHING | ATTACHED | DETACHING | FAILED` — 描述当前进程是否 attach 在一个 run 上 一个 session 可以是 OPEN 同时没有任何 runtime 在运行。一个 run 失败了，session 不应该自动出错。一次进程重启后，可以重新 attach 到 session 继续工作，已有的 run 状态不变。 把这三个维度压进一个枚举，看起来简单，实际上丢失了这些组合语义，最终会在某个边界情况里出错。 --- ## 六、数据所有权要清晰 Agent 必须是自己的对话和执行状态的唯一 source of truth。没有外部文件、外部运行时、外部进程持有另一份"权威版本"。 几个所有权规则： - **消息**是模型可见的对话历史的权威来源 - **Run 和 Step**是执行状态的权威来源 - **Tool call 记录**是副作用审计和幂等性的权威来源 - **Context snapshot**是"这次 run 组装了什么上下文"的权威来源 - **事件**是有序观测和重放的权威来源，不是重建所有领域状态的来源 这些规则的价值在于：当系统出问题时，你知道去哪里找答案，不用在几个系统之间对比"谁的版本是对的"。 --- ## 七、Context 压缩不是破坏历史 当对话历史太长撑爆 context window 时，压缩是不可避免的。但压缩不应该是破坏性的——原始消息应该保留，压缩节点插入在消息树里，后续的 context 组装从压缩节点开始，而不是从根节点开始。 这个设计让"从压缩前的某条消息分支"依然是合法操作——走原始路径；"从压缩节点分支"则走摘要路径。两种分支都通过同一个消息树遍历逻辑处理，不需要对压缩节点特殊处理。 压缩后的 context snapshot 会记录 `compaction_artifact_id`，使得任意一次历史 run 都是可重现的，不会因为后来发生了压缩而失效。 --- ## 八、能力扩展的接口设计 一个 Agent 系统想要长期演进，能力扩展的方式至关重要。推荐的模式是**窄接口 facet**： 能力模块向 Runtime 注册，Runtime 在固定时机调用能力——context 组装、工具 dispatch、事件通知、run 触发、run 后处理。能力不能反向调用 Runtime 的内部状态，只能通过类型化接口（如 `RunTrigger`）发起新的 run。 ``` Runtime → 调用能力 能力 → 只通过类型化接口和 Runtime 交互 ``` 这个设计的好处是：**每个能力只实现它需要的 facet**。Memory 模块实现 context 贡献和 run 后处理，Scheduler 模块实现 run 触发，互相不干扰。新加一个能力不需要修改 Core 或 Runtime 的任何代码。 在 run 开始时，Runtime 把当前激活的能力版本、工具定义、策略等冻结成一个 capability snapshot。这意味着 run 执行过程中的配置变更不会影响正在执行的 run，只会影响后续的 run——这对调试和问题排查非常重要。 --- ## 九、Evolution：受控的自我改进 Agent 的 Evolution 能力描述了一条受控的自我改进流水线： ``` 已完成的 run → 观测 → 候选 skill / prompt / workflow → 隔离评估 → 策略或人工审批 → 不可变发布 → 有范围的激活 → 结果监控 → 可回滚 ``` 几个硬约束值得注意：不能直接修改 Core 或 Runtime 的源代码，不能自动扩大权限或工具策略，不能静默替换活跃版本，每个候选都必须有来源和评估证据，每次激活都是可逆的。 这些约束的存在不是为了限制 Agent 的能力，而是为了确保演进过程是**可观测、可解释、可回退的**。一个能自我改进但改进过程不透明的系统，在生产环境里很难信任。 --- ## 小结 回顾整个设计过程，有几个反复出现的主题： 1. **边界优先于功能**：先想清楚谁拥有什么，再想怎么实现。边界划清了，功能加起来会很自然；边界划错了，越加功能越乱。 2. **协议是契约，不是实现细节**：协议一旦发出去就很难改，要把它当成一等交付物来设计。 3. **状态要分离，不要合并**：把不同维度的状态强行合并进一个枚举，短期看简单，长期看是债务。 4. **能力扩展靠接口，不靠特殊处理**：Core 不应该知道 Memory、Scheduler、Subagent 是什么，它只知道 `ContextContributor`、`ToolProvider`、`LifecycleSubscriber`。 5. **可观测性和可回退是设计目标，不是事后补充**：幂等键、审计日志、capability snapshot、Evolution 的回滚机制——这些都不是"有空再加"的东西，它们决定了系统在出问题时是否可以被理解和修复。 --- ## 模型的幻觉可以优化，人的幻觉怎么办？ URL: https://yachiyo.im/article/2026-08-18-human-hallucination/ 发布时间: 2026-08-18 标签: 幻觉, 认知, AI, 随笔 摘要: 模型的幻觉能被优化，靠的是给它装上外部校验。人的幻觉没法照搬这套办法，能变的只是愿不愿意主动去核对自己。 > **TL;DR**：模型幻觉能被优化，靠的是给它装上外部校验：检索、置信度校准、RLHF，都是把"自信"和"正确"重新对齐的手段。人的幻觉没法照搬这套办法，个体好歹还有现实可以撞一撞，组织连这堵墙在哪都摸不清。真正卡住的地方是很多判断根本没有标准答案，查无可查，能变的只是愿不愿意主动去核对自己。 ## 一、模型的幻觉，是怎么被"治"的 先说清楚模型这边在做什么，因为后面的对比都建立在这个基础上。 模型幻觉优化，做的不是让模型不再"编"。生成式模型的本质决定了它随时都在编，包括说对的时候。真正在做的是让模型的自信程度和它实际的正确程度对上：检索增强给它一个可以核对的地方，置信度校准让"我不确定"变成一个能被表达出来的状态，RLHF 让编得像真的这件事本身付出代价。 这些手段有个共同点，就是给系统装一个不属于它自己的外部校验点。模型自己分辨不出一段生成是不是幻觉，它的训练目标从来不是说真话，是生成合理的下一个词。校验只能来自外部，而且校验的对象很具体，可以核实：这个事实对不对，这段引用存不存在，这个数字算得对不对。 这一点很重要，后面会用到。 --- ## 二、人的幻觉，先从最小的尺度看 个体层面的幻觉，得先和犯错分开看。一个人说"我记错了""这个判断的依据不够""我需要再确认一下"，这是出了错还能纠正回来的能力，不算幻觉。真正麻烦的是另一种状态：证据不够的时候仍然觉得自己掌握了全部事实，事情已经变了却还在用旧的说法解释新情况，结果不如预期，第一反应是怪外部而不是回头检查自己的判断。 这种状态的常见形态其实很朴素。一个人做了一次冒险的决定，恰好走对了，这次判断就被记成"我的方法论"，很少有人回头拆解那次成功里到底有多少运气。一个想法被自己反复讲了很多遍，讲的次数多了，流畅程度渐渐取代了准确程度，"我一直是这么想的"慢慢变成了"这就是对的"。 模型出错，理论上能查到根子：提示词、检索记录、调用链路都留着，复现一次、统计一次错误率都不难。人的判断也有输入和输出，中间多了一层不太稳定的东西，记忆。人并不是在调用一份完整、准确、不会变的过去，每一次回忆其实都是在重新组织过去。讨论完之后的自我辩护，一次成功之后的归因，一次失败之后找的理由，都可能悄悄改写"当时自己到底是怎么想的"。"我记得是这样"和"事实就是这样"之间的界限，自己是分不出来的。 这几种情况都指向同一件事，内部的叙事是通的，逻辑上自己讲得过去，但和外部现实之间的那根线已经断了。而且往往越确信的时候，这根线断得越彻底，因为确信本身就是叙事流畅带来的感觉，不是靠核对现实换来的。一个高置信度说错答案的模型，和一个对错误判断深信不疑的人，其实是同一种失败方式，只是发生在不同的载体上。 人比模型多一样东西，就是会撞上现实。一个错误的判断如果真拿去做了事，迟早要在某个具体的地方碰壁，项目黄了，关系散了，说好的事没有发生。这堵墙某种程度上替代了模型那边的检索校验，撞上去了，至少有机会意识到哪里错了。 问题是这堵墙经常撞不上，或者撞上了也能被绕开。一次判断错了，人往往能找到足够多的理由把责任推到别处，时机不对，运气不好，别人没配合。撞墙这件事发生了，但没有转化成对判断本身的核对。这个环节一旦被绕过去，幻觉不但保留下来了，还可能因为"扛过了一次失败"反而更巩固了。 --- ## 三、放大到组织：同样的机制，更难触发校验 个体的幻觉好歹有墙可以撞，组织的幻觉往往连墙在哪都摸不清。 一个组织形成了某种判断之后，"我们别无选择"这种叙事很容易长出来，路径依赖和群体共识会慢慢覆盖掉个体原本的判断。决策者通常被层层信息过滤保护着，坏消息在往上汇报的路上会被磨平棱角；就算真的撞到了墙，也有足够大的空间把这次撞墙解释成外部环境的问题，而不是判断本身出了错；更麻烦的是，在组织里质疑一个已经形成的共识是要付出代价的，一个人站出来说"我们可能一直判断错了"，往往比闭嘴的代价更高。 这和模型的区别在于，模型没有理由抗拒校验，它甚至不知道校验这件事存在。组织是有动机的，校验的结果可能推翻已经拿到的位置、已经分配好的资源、已经讲了很久的故事。这不是工程能解决的问题，是激励结构的问题。没法给一个组织装一层检索，让它的每个判断自动去核对现实，因为组织里真正握有判断权的人，往往也是最不想被核对的人。 --- ## 四、技术在做的不只是治模型，也在照见人 模型幻觉被治理的这几年，还带来一个没被太多人提起的副作用：当 AI 能在几秒钟内检索资料、列反例、追溯出处、比较不同的论证时，很多原本被当成"常识"的东西，会被照出它其实只是一个没认真核对过的二手印象。很多说得很确定的观点，撑起它的不是理解，是熟悉感。 这不是说可以把模型当成新的权威。模型自己也会错，检索到的材料也可能片面，"有来源"不等于"结论对"。值得建立的不是人相信模型、或者模型服从人这种单向关系，而是让两边互相核验：人负责提出问题、判断价值取舍、承担最后的责任，模型负责扩大检索范围、找反例、给出备选解释，证据决定哪些判断眼下能站得住。 这件事真正的意义不在于谁更聪明，在于系统是不是允许被纠错。一个不允许自己被质疑的人，模型再强也帮不上；一个不允许被追问的模型，安全规则写得再多也只是摆设。 --- ## 五、真正的分界线：有没有标准答案 回到最开始的问题，模型的幻觉能被优化，人的幻觉为什么没法照搬同一套逻辑。 答案不在方法上，在问题本身的性质上。模型幻觉能优化，前提是它被要求处理的大多数任务有明确对错，一个事实陈述是真是假，一段代码跑不跑得通，一个数字算得对不对，这些都能查证，路径是存在的，只是要不要去查的问题。 人的很多幻觉，恰恰长在没有唯一答案的地方：一次战略判断，一次价值取舍，一次对未来的预测。这些压根没地方可查，不存在一个能拿来核对的标准答案。判断的过程可以复盘，严不严谨可以讨论，但没法像核对一个事实那样去核对"这个判断对不对"，答案要等以后才会出来，等出来的时候常常已经没有回头的余地了。 这才是人的幻觉难缠的根本原因。不是校验机制不够好，是很多时候连能核对的靶子都不存在。 --- 想清楚这些，倒也没什么让人乐观的结论。模型的对齐是工程师逼出来的，它自己没有拒绝的权力，接上检索、加上校准，照做就是了。人的对齐从来是自选的，没有谁能强迫一个人或一个组织主动去核对自己的判断，连去核对这件事本身，也要先愿意承认自己可能是错的。 这大概是人和模型之间最不对称的地方。模型的幻觉是被治好的，人的幻觉，顶多是自己愿不愿意去治。 --- ## DeepSeek Harness：做的不是工具，是生态 URL: https://yachiyo.im/article/2026-08-20-deepseek-harness-ecosystem/ 发布时间: 2026-08-20 标签: DeepSeek, Agent, 开源, 商业 摘要: DeepSeek 开源 Harness 这件事，拆开看至少有三层逻辑：价格杠杆、竞争维度转移，还有一个更大的赌注——想把自己变成整个行业默认拿来插东西的那层地基。 > **TL;DR**：DeepSeek 把 agent harness 开源，表面看是一次工具层面的开放，实际是三层叠加的动作。开源高效的 harness，本身是一种价格杠杆——同一个模型换一层 harness，实际成本能差出七倍。它也把竞争维度从"模型分高不高"挪到了"系统设计强不强"。但最大的野心在第三层：想让这套插件架构变成整个行业默认拿来插东西的地基，而不只是一个好用的工具。这条路能不能走通，不取决于 DeepSeek 自己，取决于有多少人愿意在这层地基上盖房子。 ## 一、先排除两个显眼的猜测 DeepSeek Harness 发布之后，最先冒出来的两种猜测，可能都站不住。 第一种最直接：DeepSeek 也做了一个 Claude Code。但这个说法忽略了它真正在开放的东西。模型适配器、工具注册表、会话日志，甚至 agent loop 本身，在这套架构里全部是插件，谁都能替换。开放的不是一个产品的功能列表，是产品下面那层骨架。而且这层骨架从设计上就没有把自己锁死在 DeepSeek 的模型上，它默认接入的 provider 列表覆盖了 Anthropic、OpenAI、Azure、Bedrock，甚至内置了两个可以直接调用 Claude Code 和 Codex 二进制的 subagent provider。一个想靠抢用户活下去的产品，通常不会主动把入口开给对手的工具。 第二种更隐蔽一点：开源一层能看到用户全部操作轨迹的系统，图的是训练数据。这个猜测目前也缺乏支撑。遥测能力默认关闭，即使主动打开，数据发到哪里由部署方自己决定；本地日志走的是 JSONL 文件或 SQLite，用户通过 Claude、OpenAI 等其他模型跑出来的任务轨迹，不会自动流回 DeepSeek 的服务器。就算调用的是 DeepSeek 自己的 API，它能看到的也只是那一次请求送进去的上下文，不是整套本地记录。把这套架构说成一条免费铺好的数据管道，证据还不够。 排除掉这两种猜测之后，真正值得问的问题变成：一个几乎不限制用什么模型、甚至主动桥接竞品的开源项目，图的到底是什么。 --- ## 二、效率是价格杠杆 答案的第一层，藏在一个不太起眼的测试里。有机构做过一次横向对比，让同一个 DeepSeek 模型在八个不同的 harness 上跑同一批任务。最便宜的一个开源 harness，每完成一个任务平均花费不到三美分；而某个主流编程 agent，跑同样的任务平均要花将近两毛美元。同一个模型，换一层 harness，实际成本能差出七倍。 这个数字揭示了一件容易被忽略的事：用户实际感知到的成本，从来不是 API 标价单独决定的，是标价乘以完成一个任务需要多少轮调用、多少 token。如果 harness 本身设计得笨重，让模型多绕几圈弯路、多读几遍不必要的上下文，标价再便宜也没用；反过来，如果 harness 足够高效，标价涨一点，用户实际掏的钱也不一定涨。 这给了 DeepSeek 一个价格战之外的杠杆。开源一套高效的 harness，相当于把"用起来便宜"这件事，从"模型标价便宜"这一个维度，拆成了标价和效率两个维度。标价可以按市场情况随时调整，效率这层护城河，一旦 harness 成了大家默认在用的那套骨架，就不容易被绕开。 --- ## 三、把战场从模型搬到系统 这层杠杆还带来一个更深的变化：竞争的战场本身在挪位置。 过去谈论一家模型公司的竞争力，几乎都是在谈模型本身：参数规模、训练成本、跑分、API 标价。这些指标的好处是直观，谁的数字好看，谁就暂时领先，而且很容易被下一次发布刷新。 但如果同一个模型放进不同 harness，表现能出现肉眼可见的差异，这条评价标准就不够用了。工具怎么设计、上下文怎么组织、什么时候压缩历史、错误怎么恢复，这些原本被归到"工程细节"里的东西，开始变成 agent 最终表现的一部分。模型的分数不再是唯一变量，骨架的设计能力也要算进去。 对 DeepSeek 来说，这条新战线是有利的。就算某一代模型不是分数最高的那个，只要 harness 设计得足够扎实，综合体验依然能打。这不算放弃在模型层面竞争，更像是给自己多开一条不完全依赖模型分数的赢法。 --- ## 四、真正的赌注：不是工具，是生态位 但如果只停在效率杠杆和多一条赢法这两层，还是低估了这件事的野心。 真正大的赌注在于：DeepSeek 想要的，可能根本不是让自己的 harness 成为"最好用的那个工具"，而是让它成为"大家默认拿来插东西的那层地基"。 这个思路和云计算领域一个老对照很像。早年的云平台，与其说是在卖一个产品，不如说是在定义一套让计算、存储、网络、身份认证可以独立开发、替换、组合的接口标准，不同厂商各自专注自己最擅长的模块，再按标准拼装成完整的平台。DeepSeek Harness 想干的事，结构上是同一件：把 agent 拆成模型适配、工具、沙箱、记忆、编排这些可以独立开发、独立交付的模块，谁做出一个足够好的沙箱插件，就有机会同时进入好几个行业的 agent 系统，不用每个项目从头造一遍轮子。 如果这套插件生态真的立起来，过去藏在每个项目内部、被重复开发很多遍的东西，比如一套通过金融机构安全审查的沙箱、一个成熟的企业记忆模块，会变成可以反复交付的标准品。这时候 DeepSeek 未必需要自己把每一个插件都做到最好，它占住的是"接口由谁定义"这个位置。接口一旦被广泛采用，后来者想绕开都要先过这一层。 这是四点里最难兑现、也最有野心的一条。前三点靠一次发布、一次测试就能验证，这一条不行。生态位不是官方文档里写一句"我们希望成为标准"就能成立的，得靠外部开发者真的愿意往上面堆插件，堆出足够的密度和覆盖面，才算数。 --- ## 五、这个赌注目前的裂缝 目前看，这块地基还没打稳。 开发者的反馈两极分化得很明显：一派认为底层架构扎实，尤其对做"自进化 agent"方向研究的团队来说，这套设计提供了目前其他方案都没有的骨架；另一派的评价更直接，对大多数日常写代码的开发者来说，这套系统重得没有必要。这两种评价其实不矛盾，只是说明目前它更像一套面向前沿研究的基础设施，离普通开发者的日常工作流还有距离。 更值得留意的是一条安全方面的提醒：插件架构目前没有签名机制，也没有权限清单，装一个插件本质上就是允许它直接跑代码。默认信任，等于默认给了一个还没被验证过的攻击面。这不是一个可以事后修补的小问题，如果生态想要真的做大，涉及金融、医疗这些对合规和安全要求极高的行业，插件的信任机制迟早要补上，补晚了，前面提到的跨行业复用就无从谈起。 这些裂缝不是在否定这步棋的逻辑，是在提醒一件事：生态位这种打法，风险和野心是成正比的。地基打得越大，能塌的地方也越多。 --- 资源该往哪压，一直是 DeepSeek 决策逻辑里的核心问题：要不要做多模态，要不要把资源留给推理和 agent 能力，现在这个问题又多了一层——要不要把 agent 的骨架，做成一个谁都能插、谁都能拿去用的公共接口。 模型层面的输赢，几周内一次跑分就能见分晓。生态位的输赢，要等外部开发者真的把插件堆起来之后，一两年后才看得清楚。现在能做的判断，只是这步棋在逻辑上站不站得住。从目前的架构设计和它主动打开的边界来看，这步棋站得住，但兑现与否，不取决于 DeepSeek 自己，取决于有多少人愿意在这层地基上盖房子。 --- ## AI 订阅制，赌的是你用不完 URL: https://yachiyo.im/article/2026-08-25-ai-subscription-bet/ 发布时间: 2026-08-25 标签: AI, 商业, 定价, 订阅制 摘要: 用户买了 100 万积分，实际只用 20 万，剩下 80 万是利润——这句话在软件时代不痛不痒，到了 AI 这一代，变成整套商业模式唯一重要的变量。 > **TL;DR**：Evoken 创始人陈冕说过一句大实话，用户买了 100 万积分，实际只用 20 万，剩下 80 万是利润，他自己也拿 ChatGPT 的订阅会员做过同样的类比。这不是 LibTV 一家的特例，是所有 AI 订阅产品共享的底层逻辑，结构上跟保险公司卖保单是同一套数学：收的是保费，赌的是大多数人不会把保额用满。软件订阅时代这套赌注很安全，因为边际成本几乎是零；AI 时代每一次生成都是真实花出去的钱，用户有没有用满额度，从无关痛痒的行为习惯，变成了唯一重要的变量，也因此招来了主动的对抗。它能不能一直成立，还要看 token 成本下降的速度，会不会先一步把这套逻辑冲垮。 ## 一、一句大实话 陈冕在采访里说过一句很直白的话：用户买了 100 万积分，实际只用 20 万，剩下 80 万是他们的利润。 这句话听起来像是随口一提的运营细节，但拆开看，它其实是所有 AI 订阅产品共享的一套底层逻辑，不是 LibTV 一家的特例。陈冕自己举的对照对象就是 ChatGPT：一个 Plus 或 Pro 会员，理论上每个月能调用的额度不低，但绝大多数订阅用户根本用不到那个上限。这门生意能不能赚钱，靠的从来不是用户用了多少，是用户没用多少。 --- ## 二、旧时代的这套赌注，本来是安全的 包月制赌用户用不完，不是什么新发明。健身房是最经典的例子，办了年卡的人，不会天天来。软件订阅也是同一套逻辑，陈冕自己就举过例子：哪怕是剪映、Adobe 这种成熟的生产力工具，一个稳定留存的用户，30 天里活跃天数也就 5 天左右。大部分工具产品本来就是周活产品，不是日活产品。 这套赌注在旧时代之所以安全，是因为多给用户跑一次渲染、多存一个文件，边际成本几乎是零。用户有没有用满额度，公司几乎不受影响，赌赢了是利润，赌输了也亏不到哪去，因为压根没有真实成本在往外流。 --- ## 三、这套赌注的另一个名字：保险 拆到底，这种定价方式和保险公司卖保单，是同一套数学。 保险公司收保费，赌的是不会所有投保人同时出险，也不会每个人都把保额用满。一份重疾险，保费定价建立在"大部分人这辈子不会得那么多种大病"这个统计假设上。精算师算的核心指标叫赔付率，赔出去的钱除以收上来的保费，只要这个比例长期低于 100%，保险公司就能活；一旦某一年出险的人多到赔付率冲破这条线，这家公司在这个产品上就是亏的。 AI 订阅制的额度设计，结构上跟这个一模一样：收的是订阅费，赌的是消耗率长期低于某一条线。陈冕说的"用户用不完"，换成保险行业的说法，就是"赔付率健康"。区别只在于，保险公司卖的是对未来不确定性的保障，AI 订阅卖的是对当下生产力的许可，但两者能不能持续经营，靠的是同一件事：大多数人不会把自己花钱买的东西用满。 --- ## 四、AI 把这门生意的地基换了 AI 产品的区别在于，每一次多用，都是真实花出去的钱。一次生图、一次生视频，背后都在实打实地消耗 token，而 token 是要向模型厂商付费的。 这也决定了这类产品的定价从一开始就必须留出安全边际。如果按额度真被用满来核算成本，价格通常撑不住；所以定价的起点，是预期消耗率乘以每次生成的真实成本，不是额度上限乘以成本。换句话说，这类产品从定价那一刻起，赌的就不是"额度值多少钱"，是"用户的平均使用习惯会停在哪"——定的不是一个数字的价格，是一个统计假设的价格。 这在旧时代订阅制里，从来不是一句会被摆到台面上说的话，因为那时候这件事根本不重要。到了 AI 这一代，它变成了整套定价策略里最重要、也最脆弱的假设。。 --- ## 五、这个赌注天生带对抗性 更值得注意的是，这个赌注不只是被动地希望用户少用，它还招来了主动的对抗。 陈冕提到，有用户对 LibTV 做逆向工程，把年费会员账号包装成 API 来用，这类用户是真的把额度用满、用出效率的人，公司在他们身上是亏的，所以要专门治理。这暴露了这套模式一个天生的脆弱之处：它默认的前提，是用户会低效地使用自己花钱买下的东西。一旦有人打破这个默认，这门生意不是简单地少赚一点，是直接从赚钱翻到亏钱。这跟大部分生意的直觉是反的，一般产品都希望用户越活跃越好，活跃度是留存和口碑的信号；但在这种赌"用不完"的定价模式里，活跃到某个临界点之后，用户会从利润来源直接变成亏损来源。 这种对抗性还有另一层，藏在两种不同的额度设计里。像 LibTV 这样明码标价卖积分的产品，额度是用户能亲眼看到的数字，用完了自己心里有数；而像 ChatGPT Plus、Pro 这不公布具体上限的订阅，靠的是一套不对外说明的公平使用策略限制极端高频用户。两种做法赌的是同一件事，只是划线的方式不一样，一种把这条线摆在明处，让用户自己看着数字去克制；一种把这条线藏起来，事后再悄悄执行，好处是从不需要向用户承认真的存在上限，代价是这套限流的具体做法一旦被扒出来，容易引发比公开设限更大的反弹。 --- ## 六、成本下降，会让这个赌注消失，还是更重要 陈冕自己也提到，token 成本本身在持续下降，SOTA 模型只有在刚成为 SOTA 的那段时间最贵，后面一定会越来越便宜。这带出一个值得摆在台面上的问题：如果生成成本持续往下走，这套赌"用户用不完"的模式，会变得不再重要，还是会变得更重要？ 一种可能是，成本低到可以忽略之后，用户有没有用满都无所谓了，反正每一次生成本身已经便宜到不值一提，包月制里这层赌注自然就松绑了，就像今天没人会去精算一次网页请求的服务器成本。 另一种可能正好相反。成本一旦低到人人都能随便用，用户没有理由不把额度用满，包月制里"赌你用不完"这套逻辑会直接失效，取而代之的是更贴近真实消耗的按量付费。到那个时候，现在这种卖额度、赚没用完的部分的定价方式，反而会因为用户变得敢用、爱用，而彻底站不住，就像保险公司如果发现出险率突然普遍飙高，第一反应不是继续卖统一保费的保单，是重新按风险分层定价。 这两种方向现在都说得通，谁会先发生，可能要看具体品类里，用户的使用习惯和成本下降的速度，谁先跑到那个临界点。 --- 这件事有意思的地方，不在于 LibTV 或者 ChatGPT 这一家公司精不精明，是它把一个原本藏在旧时代软件订阅制和保险行业里、没人愿意摆到台面上说的假设，逼到了必须说清楚的地步。健身房和 Adobe 可以一直不去谈这个假设，因为谈不谈，生意都照样能活；AI 订阅制不行，因为这个假设一旦不成立，账立刻就是亏的。 某种程度上，每一个买了包月套餐的人，都是这场赌局里被下注的那一方，只是大部分人从来没意识到，自己有没有用完，才是这门生意真正的底牌。 --- ## 领先者的诅咒：当追赶者只需要「够接近」 URL: https://yachiyo.im/article/2026-09-03-leaders-curse/ 发布时间: 2026-09-03 标签: AI, Claude, 商业, 竞争策略 摘要: 技术上领先，不会自动换来用量上的领先。守住第一的代价，从来不是被真正超越，是被"够接近"这件事本身架住。 > **TL;DR**：Fable 5 作为 Anthropic 定位最高的旗舰模型，企业端 token 消耗量却只占约 6%，价格和数据留存问题让不少客户转向了更便宜的 Opus 5。Fable 5.1 这次升级花的力气，基本都在补价格、数据留存、安全误判这些能力之外的短板，而不是拉大跑分差距。这背后是一个更大的结构性处境：领先者要同时守住能力和价格两条线，追赶者只需要够接近、把价格砍到一个零头，就能构成实质威胁。效率提升能缓解一轮压力，解不开这套不对称本身。 ## 一、一个反直觉的数据点 Fable 5 上线之后，有一个数字容易被忽略：作为 Anthropic 产品线里定位最高、价格也最贵的旗舰模型，Fable 5 只贡献了企业端约 6% 的 token 消耗量。加上数据留存政策带来的合规限制，不少客户最终选择了更便宜、更容易采购的 Opus 5。 这个数字有点反直觉。按理说，旗舰模型应该是能力最强的选择，最强不该也是市场表现最好的那个吗？但现实是，技术上领先，并不会自动换来用量上的领先。 --- ## 二、「够强」从来不是市场需要的全部 企业买模型这件事，从来不是单纯买一个能力分数。要的是可预测的成本、合规友好的数据处理方式、采购流程足够简单，这些都是能力之外的变量，任何一个卡住了，再强的模型也用不起来。 Fable 5.1 这次升级，花的力气基本印证了这一点。价格上，把 Cache Read 的单价降了 75%，对应的是长时间运行的 Agent 任务里最容易堆积的那部分成本。数据留存上，推出了 Enterprise Frontier Safeguards，让客户的数据能留在自己的云基础设施里，不进 Anthropic 的服务器。安全机制上，网络安全场景的误判率降了约 60%，生命科学场景降了约 85%。 这几项加在一起，没有一项是在拉高模型本身的分数，全部是在拆掉那些让企业想用却用不起来的障碍。这说明当初卡住 Fable 5 的，可能压根不是能力，是能不能被实际用起来这件事本身。 --- ## 三、追赶者不需要超过，只需要接近 这背后其实是一个更大的处境。最近智谱的牛来模型、阿里的 Qwen 3.8 Flash，都在用远低于旗舰模型的价格，提供接近旗舰能力的表现，这条线一直在往上移。 领先者和追赶者面对的是完全不对称的任务。领先者要守住第一，得持续加码算力、承担更高的训练成本、建设更复杂的基础设施，同时还得靠更高的定价撑住原有的收入结构。追赶者的任务简单得多，甚至不需要真正超过对方，只要做到足够接近，再把价格压到对方的十分之一，就足以构成实质性威胁。 这种不对称，常被称为领先者的诅咒：守住优势需要不断加码，追上优势往往只需要接近再压价。差距一旦小到可以用价格填平，谁比谁强反而不再是决定性的问题。 --- ## 四、这次更新，与其说是进攻，不如说是防守 用这个框架回头看 Fable 5.1，会发现它不太像一次进攻性的更新。跑分确实在涨，但花的篇幅更多在讲价格、数据留存、安全机制误判，这些都是防御性的动作，不是在拉大和对手的能力差距，是在补上那些会让旗舰模型输给够用又便宜的选项的具体环节。 Cache Read 降价这一项尤其能说明问题。这不是一个单纯让利的动作，是对 Fable 5 内部就输给了 Opus 5 这件事的直接回应。同一家公司自己的旗舰模型，输给自己更便宜的中端模型，这本身已经是够接近就能赢这条逻辑在内部的一次预演。5.1 要防守的，不只是外部的追赶者，还有自己产品线内部同样的价格压力。 --- ## 五、防守的极限在哪 效率提升当然有用，但解不开这套逻辑里真正的不对称。领先者要同时在两条线上防守，能力不能掉队，价格也不能失守。追赶者只需要在一条线上达标，够接近就行，剩下全靠价格碾压。 这意味着降价这类动作，解决的是眼下这一轮的压力，不是这套结构本身。等追赶者的模型再逼近一步，这道题还会重新出现，不是因为哪次更新没做好，是因为领先者的位置本身，天生要求你同时打赢两场仗，而追赶者只需要打赢其中一场。 --- 领先的代价，从来不是被真正超越。被超越是一次性的事件，输了就是输了，没什么好防的。真正难缠的是"够接近"这件事本身，它不需要赢，只需要让差距小到价格的落差能补上剩下的部分。守住第一的人，面对的不是某一个具体的对手，是一条不断往上移的线，而这条线本身，不会停下来等你喘口气。 --- ## Agent Team 的编排层：能被看见，不等于能被看懂 URL: https://yachiyo.im/article/2026-09-04-agent-team-orchestration/ 发布时间: 2026-09-04 标签: Agent, AI, 架构, 多智能体 摘要: 编排层解决的是 Agent 之间说不说得到的问题，不是说的话有没有意义。可见不等于可懂，能传递消息、传递文件，不等于能替协作本身背书。 > **TL;DR**：以阿里 AgentScope 的 AgentTeams 为例，这类项目在编排层解决得很彻底——通信基础设施、任务流转、共享存储、人在环、可观测性都到位了。但任务流转打通不等于协作打通，Worker 之间即使能够互相点名、委派任务、提交结果，方案讨论和共识形成本身仍然没有被充分结构化地表达出来。更细一层看，即使是按需查询、共享文件系统、工作流状态这些信息组织方式，解决的也主要是"消息传不传得到"、"文件传不传得到"和"任务走到哪一步"，没有哪一处把"一个 Agent 攒下来的上下文该以什么粒度对另一个 Agent 可见"当成一个独立的设计问题去处理。 ## 一、编排层解决的，是"谁能说话、谁能听见"，不是"说的话有没有意义" 多 Agent 系统里经常被含混在一起的两件事，其实该拆开看。一件是通信基础设施：Agent 之间能不能把消息送到彼此手上，走什么通道，人类能不能看见、能不能插手。另一件是协作语义：这些消息里，有没有真正意义上的讨论、反对、达成共识这些内容。前者是管道，后者是管道里流的水。 AgentTeams 是个很好的观察样本，因为它把前者做得相当完整：凭据安全、通信基础设施、共享存储、可观测性、人在环、多运行时兼容，几乎覆盖了工程侧能想到的所有环节。它甚至已经把一部分任务协作语义做成了 Project、Task、DAG、Loop、委派、提交和验收。但结构上它仍然是 Manager-Workers，这些语义主要回答的是任务如何被拆开、交给谁、推进到哪一步；方案共同讨论、分歧仲裁、证据引用和共识形成，还没有被提升成独立的协作对象。管道修得再好，决定不了里面流的是清水还是空气。 --- ## 二、借道人类协议：为什么是 Matrix AgentTeams 一个挺聪明的选择，是把 Matrix 协议直接拿来当 Agent 和人类共用的通信总线。人类不需要额外学一套监控系统，打开任意 Matrix 客户端，进同一个房间，就能旁听、能插话。 这个设计的巧妙之处在于，它没有把"Agent 之间怎么通信"和"人类怎么可见、怎么介入"当成两个需要分别解决的问题。如果分开做，通常的路径是先给 Agent 造一套专属通信协议，再在上面叠一层监控和干预系统给人看。AgentTeams 反过来，直接把 Agent 塞进一个人类已经在用、协议本身足够成熟的聊天系统里——Agent 和人在同一个房间里，是同一套底层协议下的两种参与者，不是两套系统拼起来的。只是 Matrix 在这里承担的是消息和可见性，Project/Task 状态、共享文件和 Controller 生命周期仍然由另外几层系统负责。 --- ## 三、可见，不等于可懂 问题出在下一层。如果只看 Matrix 这一层，Worker 之间靠 mention 机制互相点名，确实很像是把每个 Agent 拉进同一个群。这解决的是消息传不传得到，不是消息里有没有实质内容。但 AgentTeams 并不只有群聊：TeamHarness 还提供了任务委派、结果提交、项目推进和文件同步等工具，Project/Task 也定义了任务状态和依赖关系。真正的留白不在于它完全没有协作语义，而在于这些语义主要描述任务状态，没有继续描述方案是怎么讨论出来的。 一个人类如果真的打开客户端去旁听，大概率看到的仍然是一连串任务分派和结果汇报，因为方案讨论、共识形成这些东西，从设计上就没有被结构化地标注出来，是不是发生过、发生得怎么样，得自己从消息记录里去拼。AgentTeams 已经能够把项目节点、依赖、下一步和阻塞点整理成工作流视图，但可见的主要还是"任务发生了什么"，不是"一个判断为什么成立、有哪些反对意见、反对意见有没有被处理"。 --- ## 四、留白比解决的部分更值得看 编排层里跟"信息该怎么流转"沾边的设计，其实提到了好几处，但拆开看，没有一处真正把"一个 Agent 积累的上下文该以什么方式、什么粒度让另一个 Agent 看见"当成一个独立的问题来处理。 围绕信息流转，AgentTeams 其实已经有几条工程化处理：Worker 可以通过消息和工具请求其他成员，可以通过共享文件按需读取结果，也可以通过 Project/Task 状态读取任务进度。这些机制已经在控制消息噪音和上下文规模，但 Worker 拉到的是什么粒度的东西，是一段摘要、一个结构化结论，还是完整执行轨迹，这一层没有展开。 为了不让全连接通信在 Worker 数量增加时把 context 撑爆，常见的工程约束会包括按能力路由、成员关系限制、按需查询和通信预算。这些更像是控制谁能跟谁说话、说多少的流量阀门，不是上下文本身该怎么分层披露的设计。AgentTeams 的 Skill、Team 成员和 Matrix 权限能够限制协作范围，但还没有进一步规定：一个结论应该向谁可见、应该带哪些来源、以什么摘要粒度出现、在什么条件下失效。 AgentTeams 案例里还提到用 MinIO 做跨 Worker 的共享文件系统，降低 token 消耗。这是另一条路子：不把东西塞进 context 反复传递，存到共享存储里，需要时按引用去取。但共享的是文件产出物，不是 Agent 各自在对话里积累的那部分上下文。 唯一明确提到分层可见性的，是任务结束后的团队复盘产出——团队共享知识库，所有 Worker 都能读；角色专属经验，只对当前岗位有意义。这是两层可见性没错，但这是复盘沉淀下来的经验资产，不是任务执行过程中实时的上下文流转。 四处放在一起看，编排层已经处理了消息传不传得到、文件传不传得到、任务走不走得通，但还没有把"上下文该怎么分层暴露"和"共识该如何被验证"单独立项。 --- 编排层能做到的极限，大概就是让人类想看的时候能看见，让 Agent 之间能把消息、文件和任务结果递到彼此手上。它可以记录任务如何流转，却还不能决定那些消息里有没有真正的讨论，也不能决定一个 Agent 攒下来的经验，该以什么方式、什么粒度、带着哪些证据，变成另一个 Agent 能直接用的东西。这两件事，都还在 AgentTeams 当前的编排层够不着的地方。 --- ## 当AI开始解牌：一场安静的意义坍缩 URL: https://yachiyo.im/article/2026-09-15-ai-tarot-collapse/ 发布时间: 2026-09-15 标签: AI, 产品思考, 塔罗, 随笔 摘要: AI 解牌真正的风险不是它编造了什么，而是它把本该多义的解读，悄悄拉向训练数据里最常见、最不冒犯任何人的那个安全答案。它压缩的不是随机性，是解读本该拥有的方差。 > **TL;DR**：当解读这件依赖个人投射与情境判断的开放性任务交给AI，真正的风险从来不是它"编造"了什么，而是它把本该多义的解读，悄悄拉向训练数据里出现频率最高、最不冒犯任何人的那个"安全答案"。塔罗只是让这件事变得肉眼可见的一个样本，但它指向的是一个更大、更容易被忽略的问题。 ## 从一次抽牌说起 最近看了不少AI塔罗小程序，抽牌逻辑都差不多：随机数生成器洗牌，大模型接过牌面组合，吐出一段解读。体验很顺滑，几乎感觉不出"哪里不对"。 但把同一类问题连着问几次——换几个人、换几种问法，都问"这段感情要不要继续"——按这套机制推下去，会指向一件微妙的事：牌面在变，解读的骨架却越来越像。措辞会换，情绪的落点、给出的建议方向，却在往同一个地方收拢。这不是bug，是一个值得拆开来看的结构性现象。 ## 塔罗的严谨性，从来不在随机数 先澄清一个容易被误解的点：程序生成的随机数，统计意义上不比人工洗牌更"不严谨"。真正的问题不在抽牌这一步，而是很多人下意识把"随机性"和"意义的多样性"划了等号，以为只要抽牌够随机，解读自然就是多元的。 事实上塔罗的意义从来不是从随机性里直接跑出来的，而是从"解读者带着自己的处境、直觉、甚至当天的情绪，去锚定一个随机结果"这个过程里跑出来的。荣格谈塔罗和易经时用"共时性"来描述这种关联——它强调的不是统计意义上的均匀分布，而是抽牌者当下的心理状态与结果之间，被主观赋予的那层关联。这个锚定动作，才是塔罗真正依赖的东西，它不是数学意义上的随机，而是**被个体经验重新赋值的随机**。 这里也能顺手纠正一个常见的比喻误用。很多人（包括我自己一开始）会想用"薛定谔的猫"来形容AI解牌——好像多重可能性因为被AI观测而坍缩成了一个固定答案。但量子坍缩的核心特征是**不可预测的随机坍缩**，而AI解读的"坍缩"恰恰相反，它是高度可预测、被语境和训练分布决定的。真人解读者的坍缩，靠的是他此刻的直觉和即兴反应，天然带着偏离均值的噪音；AI的坍缩，锚点从"这个人此刻的状态"悄悄挪到了"这张牌在语料里最常见的说法"。AI抽牌没有让随机性变得不严谨，它悄悄拿走的，是人主动锚定意义这个动作本身。 ## 一个思想实验：同一张牌，三种问法 下面这个例子是推演，不是实测记录——我没有跑一组对照实验再来写它，只是顺着前面的机制往下想，看它会落到哪里。假设抽到的是"宝剑三"，三个人分别用不同方式问了关于感情的问题：一个人问"我该不该分手"，一个人问"这段关系还有救吗"，一个人只是说"最近感情不太顺，帮我看看这张牌"。 如果是三个不同的真人解读者，答案很可能天差地别——有人会直接劝分，有人会追问"三"这个数字在这段关系里具体对应着什么伤害，有人会完全绕开建议，只是描述"心碎但清醒"这个意象，把判断权交还给来访者。风格、立场、甚至价值观的差异，会明显体现在解读里。 但如果是同一个大模型处理这三个问法，我的预期是三段解读的底层结构会高度一致：先确认"宝剑三"代表心碎、背叛或痛苦的清醒认知，然后给出一段"接纳伤痛、理性面对、时间会带来疗愈"式的中段，最后落在一个温和、不激进、几乎适用于任何感情困境的建议上。提问方式变了，答案的骨架没变——这正是我们前面说的，AI把"这个人此刻的状态"这个锚点，换成了"这张牌最常见的说法"。 ## 同一张牌，为什么答案会越来越像 这个现象背后，是三层机制叠加的结果。 第一层是训练数据本身就窄。塔罗解读的书籍、网站翻来覆去就那么几大流派的表述被反复采样，某张牌配某个问题方向的"标准答案"，在语料里出现的密度远高于个体化的、偏离主流的解读。模型学到的，本质上是这个高频语义簇的加权平均。 第二层是对齐训练的方向性偏好。RLHF这类流程在优化"用户满意度""无害性"的同时，会系统性地削弱输出里极端、偏执、甚至互相矛盾的表述——而这些"不温和"的部分，恰恰是一个真人解读者身上最像"他自己"的地方。这和机器学习里另一个熟悉的现象——生成模型的"模式坍缩"(mode collapse)——有些结构上的相似：当优化目标过度收敛于某种"安全/讨喜"的分布时，输出的多样性会被压缩，即便底层机制不完全相同，效果是相通的。 第三层，也是最容易被误解的一点：即便把提示词写得更中性、更克制，依然救不回这个问题。中性化的提示词本身就是一种收敛指令，它引导模型进一步靠拢"教科书共识"，而不是拉开差异。至于调高采样温度，能换来的多是措辞层面的随机——换几个近义词、调整句式——结论框架本身的多样性，温度参数动不了。检索增强(RAG)理论上能引入更多样的解读文本，但如果检索源本身就是那几个高频流派的重复变体，引入再多素材，收敛的终点也不会变。 三层叠加的结果是：表达在变，内核趋同。而且这种趋同还带着一层伪装——因为输出用的是"你"、提到了具体的牌面和问法，读者会误以为这是一段为自己量身定制的解读，而不是一个被套上了个性化外壳的均值答案。这种"个性化幻觉"比一本印刷出来的塔罗解读书更隐蔽，因为书不会假装自己在跟你对话。 ## 这不只是塔罗的问题 塔罗只是这个现象里最容易被观察到的样本，因为它的"答案"足够具体、足够容易两两对照。但同样的结构，会出现在任何一种依赖用户把个人经验投射进模糊输入里的场景——职业选择建议、情感倾诉式的对话、"帮我看看这段关系值不值得"这类主观评价请求，甚至是"我这个决定对不对"式的日常求助。 这些场景有一个共性：用户要的不是一个"正确答案"，而是一个能容纳自己独特处境的解读空间。历史上类似的收窄其实发生过——印刷术让圣经解读一定程度上标准化，大众媒体让文化叙事趋于集中——但那些媒介至少不会假装在"和你对话"。AI的特殊之处在于，它用第二人称、用你提供的具体细节，营造出一种"这是专属于你的答案"的错觉，而底层给出的其实是被训练分布拉平之后的均值。这种反差，正是它比过去任何一种大众媒介都更值得警惕的地方。 如果说AI在事实性问题上要提防的是"说错了"，那么它在这类开放性问题上更该被提防的，其实是"说得太对、太普适、太没有偏离"。 ## 能不能把方差设计回来 我觉得能，但需要反直觉地设计，而不是顺着"更安全、更普适"这个默认方向走下去，也要接受这样做会牺牲一部分"看起来很顺滑"的用户体验。几个具体的思路： 把流派或视角做成显性变量，而不是让模型默认给出"综合最优解"——让用户选择解读者的风格倾向甚至矛盾立场，把方差重新变成产品的一部分，而不是被悄悄磨平的噪音。代价是产品会显得不够"省心"，需要用户多做一次选择。 少给结论，多给追问——一个经验丰富的解读者很多时候不直接给答案，而是抛回一个问题让对方对照自己的处境。这个交互形态本身，就能打破"AI给出唯一确定结果"的默认预期，但也意味着产品的"即时满足感"会打折扣，一部分只想要快速答案的用户可能会流失。 让随机性可见——比如同一次抽牌，主动生成两种相悖的解读方向，把"选哪个"这个动作交还给用户，而不是让模型替用户悄悄选好。这会增加用户的认知负担，和"降低使用门槛"这个产品直觉是相反的。 这三条思路有个共同的代价：它们都在用"更麻烦"去换"更真实的多样性"，这和多数产品追求的顺滑体验是对着干的。但如果一个产品的核心价值本来就建立在"帮用户找到专属于自己的解读"这件事上，那顺滑很可能从一开始就是错误的优化目标。 ## 写在最后 AI不会让塔罗变得"不准"，它会让塔罗变得"太准"——准到每个人得到的答案都长得差不多。这大概是这类技术在处理开放性、依赖个人意义的任务时，一个还没被充分讨论的代价：它压缩的不是随机性，而是解读本该拥有的方差，以及，人在模糊面前主动赋予意义这件事本身正在被悄悄外包出去。 ---