Ai on elonnzhang

Agent Development Kit (ADK) · 13 - Session Vertex AI

Wed, 23 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Vertex AI Session：远端后端怎样保持 Session 契约

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。以下“当前实现”均指此版本。

返回 ADK 源码阅读合集 · 前置阅读：Session、Event 与 State、InMemory、Database · 配套阅读：Runner、Server。

session.Service 是 Runner 依赖的抽象，但不同后端并不提供相同的性能和事务语义。InMemory 把对象放在进程内，Database 把对象编码进本地数据库；session/vertexai 则把 Session、Event 和 State 映射到 Vertex AI Agent Engine 的 RPC。

这篇文章只追踪这个适配层，不把 Agent Engine 当成另一个 Runner。Runner 仍然负责 invocation 和事件消费，Vertex AI service 负责远端 Session 的创建、读取、列举、删除及追加。

一、源码入口与阅读地图

入口	源码	要回答的问题
构造	`session/vertexai/vertexai.go#L34-L56`	Project、Location、ReasoningEngine 怎样变成 Service？
Service	`vertexai.go#L58-L155`	五个公开操作如何委托远端 client？
本地句柄	`session.go#L29-L91`	远端 Session 返回后，Runner 持有的对象保存什么？
State	`session.go#L116-L154`	State 的读写是否需要再次 RPC？
RPC 映射	`vertexai_client.go#L69-L110`	Create 如何映射 Agent Engine resource？
Get 并发	`vertexai.go#L69-L114`	Session 元数据和 Events 如何同时读取？

runner.Run
 │ session.Service
 ▼
vertexAiService
 ├─ vertexAiClient.Get/Create/List/Delete
 ├─ Vertex AI Agent Engine RPC
 └─ localSession（本地句柄与快照）
 ├─ State() → 本地 map + mutex
 └─ Events() → 本地切片快照

二、接口与数据：远端资源加本地句柄

1. 配置中的 AppName 不是 Reasoning Engine ID

VertexAIServiceConfig 要求 ProjectID、Location 和 ReasoningEngine。创建 Session 时，client 会根据 req.AppName 解析对应的 Agent Engine resource，再把 req.UserID、初始 State 和可选 SessionID 转成 CreateSessionRequest（vertexai_client.go#L69-L105）。因此一个 service 可以服务多个 app，但每个 app 必须能解析到自己的 reasoning engine。

Agent Development Kit (ADK) · 20 - Auth、Telemetry 与 Platform

Wed, 23 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Auth、Telemetry 与 Platform：横切能力怎样进入一次运行

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。本文的“当前实现”均指这个版本。

返回 ADK 源码阅读合集 · 配套阅读：Runner、Context、Plugin、Server。

ADK 的主链文章通常从 Runner 开始：取得 Session，运行 Agent，保存 Event。但真实应用还要解决三类横切问题：工具访问外部服务时用谁的凭据，运行过程怎样被观测，以及事件里的时间戳和 ID 怎样在测试中变得可控。

这三件事分别落在 auth、telemetry 和 platform 包。它们都不负责调用模型，也不拥有 Session；它们通过接口和 context.Context 进入调用树，把能力交给真正的请求、事件或服务。

凭据和测试 provider 都沿着 context 或对象边界传递。因此“配置了 ADC”不等于每个 HTTP 请求都会自动带 token，“初始化了 Telemetry”也不等于已经注册成全局 provider。

阅读前先分清三个层次

层次	负责什么	不负责什么
`auth.CredentialProvider`	在一次请求上下文中解析可用凭据	不发送 HTTP 请求
`auth.Credential`	把已解析凭据写入 HTTP headers	不决定何时刷新或重试
`auth.Transport`	每次 `RoundTrip` 解析并应用凭据	不替调用方管理用户授权
`telemetry.Providers`	持有 OTel tracer/logger provider，注册和关闭	不自动创建业务 span
`platform` provider	为当前 context 提供时间、UUID 和任务调度策略	不改变包级默认行为

一、源码入口与阅读地图

阅读顺序	源码	要回答的问题
1	`auth/credential.go#L25-L120`	一个凭据怎样写到请求头？
2	`auth/providers.go#L29-L178`	Static token、ADC、Service Account 的解析边界是什么？
3	`auth/transport.go#L22-L75`	provider 何时被调用，Request 是否会被原地修改？
4	`telemetry/telemetry.go#L28-L119`	OTel provider 怎样创建、注册和关闭？
5	`telemetry/config.go#L55-L136`	Cloud 导出和自定义 processor 怎样组合？
6	`platform/time.go#L22-L50`、`uuid.go#L23-L52`	时间和 ID 的 provider 如何只影响当前调用树？
7	`platform/exec.go#L22-L94`	模型工具并发怎样替换为宿主自己的 TaskRunner？
8	`auth/gcp/client.go#L203-L370`	Agent Identity / IAM Connector 的 transport client 如何轮询和映射凭据？

agent.Context / request.Context
 │
 ├── auth.Transport.RoundTrip
 │ ├─ CredentialProvider.Credential
 │ ├─ Credential.Apply
 │ └─ Base.RoundTrip
 │
 ├── session.NewEvent / other ADK code
 │ ├─ platform.Now(ctx)
 │ └─ platform.NewUUID(ctx)
 │
 └── telemetry.New → Providers.SetGlobalOtelProviders
 └─ Providers.Shutdown

二、核心接口与数据

1. Provider、Credential、Transport 是三次分工

CredentialProvider 只返回一个实现 Apply(http.Header) 的 Credential。例如 BearerCredential 设置 Authorization: Bearer ...，APIKeyCredential 设置调用方指定的 header；OAuth2Credential 则在每次 Apply 时从 TokenSource 取得 token（credential.go#L47-L95）。

Agent Development Kit (ADK) · 06 - Runner

Mon, 21 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Runner：一次输入的执行、持久化与恢复

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。本文的“当前实现”均指这个版本。

范围：普通 Run 的两条执行路径、消息与 Plugin、HITL、Live 和 Context Compaction。模型与工具内部循环见 Flow，数据库内部存储见 Session 配套文章。

返回 ADK 源码阅读合集 · 配套阅读：Agent、Flow、Context、Plugin、Workflow、Session Event。

用户问“杭州天气怎么样”，Agent 可以调用工具并产出答案，但应用还需要决定：这条输入属于哪个会话、由哪个 Agent 接着回答、工具结果何时保存、用户确认回来后从哪里继续，以及前端断开后还执行哪些收尾。

Runner 把输入、运行环境、事件持久化和恢复入口接成一条调用链。 它不直接实现模型推理，却决定 Agent 产生的记录怎样进入 Session、怎样经过 Plugin、怎样交到调用方。

本文回答三个问题：

Runner 为一次输入创建哪些对象，它们被谁读取和修改？
用户消息、模型 FunctionCall、工具结果、最终答案如何按序保存并流出？
错误、提前停止、长任务恢复、Live 和压缩分别改变哪一段协议？

阅读前先分清这些词

术语	本文中的含义	易混淆之处
Runner	长期持有 root Agent、服务、Plugin 和配置的运行器	不是每次模型调用都新建
Session	App + User + SessionID 关联的历史与状态	一个 Session 可以有多次 invocation
Invocation	一次执行关联的逻辑 ID	暂停和恢复可能共用 ID
普通 Run	返回一个迭代函数，range 时才执行	非 LLM root 与 LLM root 内部路径不同
Node runtime	LLM root 的合成 workflow / 节点运行路径	不代表所有 root 都进入它
Partial	流式过程中尚未形成完整记录的响应	final 判断和 partial 标志不是同一件事
AppendEvent	服务收到一条待记录事件	不等于跨工具、artifact、数据库的原子事务

贯穿示例

主线使用 AppName=weather_app、userID=user-1、sessionID=session-1，root 为 chat 模式 weather_agent。输入是“杭州天气怎么样”，模型先请求 get_weather(city="Hangzhou")，工具返回 temperature=26，第二次模型调用生成中文回答。

Agent Development Kit (ADK) · 01 - Overview

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Overview：从一次请求看懂整个框架

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 下一篇：Quickstart · 执行主线：Runner、Flow。

用户问“杭州现在多少度”，模型输出一个 get_weather 调用，工具返回 26°C，模型再组织成自然语言回答。这里至少发生了两次模型请求、一次工具执行和多次事件追加。

ADK-Go 把这些工作分给不同组件：Agent 描述行为，Runner 驱动执行，Flow 连接模型和工具，服务保存历史与状态。一次模型响应只是 Agent 运行过程中的一步。

这篇总览围绕三个问题展开：

从程序入口到模型、工具和数据库，中间有哪些边界？
一次输入怎样变成事件，工具结果又怎样进入下一次模型请求？
接口抽象提供了什么，又有哪些必须结合具体实现理解的限制？

一、源码入口与阅读地图

ADK-Go 是用 Go 代码构建 Agent 应用的框架。应用通过构造函数组合 Agent、Model、Tool、服务和运行入口，不需要先把整个应用写成一份声明式工作流。

阅读层次	文件 / 入口	解决的问题
应用示例	`examples/quickstart/main.go`	最小应用怎样装配
启动入口	`cmd/launcher/launcher.go`	console / web 如何共用应用配置
Agent 契约	`agent/agent.go`	什么对象可以被执行
请求驱动	`runner/runner.go`	一次输入如何进入运行时
模型工具循环	`internal/llminternal/base_flow.go`	模型提出调用后由谁执行
会话记录	`session/session.go`	历史、状态和事件如何表达
图调度	`workflow/scheduler.go`	节点、事件和恢复如何协调

先把模块放在同一张结构图上：

Application
 |
 +-- Launcher / HTTP handler / 自定义入口
 | |
 | v
 | Runner <------ SessionService
 | | <--------- ArtifactService / MemoryService
 | v
 | InvocationContext：绑定本次执行所需的对象
 | |
 | v
 | Agent / node runtime
 | |
 | +-- LlmAgent --> Flow --> Model
 | | | |
 | | +<- Tool <-+ FunctionCall
 | |
 | +-- 自定义 Agent / Workflow / 远程 Agent
 |
 +-- Plugin：在已接入的生命周期边界观察或改变行为

Model 适配器与 Tool 的业务实现可以替换，运行层仍围绕请求、响应和事件协作。但是模型共用接口并不意味着所有 provider 支持相同工具、多模态或流式能力。

Agent Development Kit (ADK) · 02 - 初见 ADK

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Quickstart：一个 main 函数怎样启动 Agent 应用

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 前置阅读：Overview · 后续阅读：Launcher、Model、Agent。

一个能回答天气问题的程序，为什么既要创建 Model，又要创建 Agent，还要经过 Loader 和 Launcher？因为这几个对象回答的是不同问题：调用哪个模型、如何组织行为、如何找到应用入口、用户通过什么界面交互。

官方 Quickstart 把这条装配链放在一个 main 中。先看它的结构，再跟踪用户输入到达以后发生的事情，就能把配置代码与运行代码分开。

一、源码入口与阅读地图

文件 / 符号	在这个例子中的职责
examples/quickstart/main.go	创建模型、Agent、Loader 与 Launcher
gemini.NewModel	创建 Gemini SDK client 和模型适配器
llmagent.New	把配置装配为 LlmAgent
agent.NewSingleLoader	用一个 Agent 提供加载入口
full.NewLauncher	提供 console 与 web 两类启动方式
console.Run	创建 Session 和 Runner，进入输入循环

构造阶段
 genai.ClientConfig
 |
 v
 gemini.NewModel -> llmagent.New -> NewSingleLoader
 |
 v
 launcher.Config
 |
运行阶段 v
 os.Args[1:] ----------------> Launcher.Execute
 |
 console 或 web 入口
 |
 Runner / Agent

创建了 Agent 对象，还不代表模型已经生成过一次回答。模型请求通常要等到入口收到输入并消费运行事件时才发生。

Agent Development Kit (ADK) · 03 - Launcher

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Launcher：从命令行到 Runner

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 前置阅读：Quickstart · 后续阅读：Runner、Flow。

Launcher 是 ADK 应用的进程入口层。它处理命令行参数、校验进程级配置、选择运行方式，并把同一份 AgentLoader、SessionService、Plugin 和鉴权配置交给 console 或 web 子入口。

它不负责模型推理，也不负责工具执行。Launcher 选择怎么进入应用，Runner 才驱动一次 Agent 运行。

一、源码入口与阅读地图

层次	文件 / 符号	作用
顶层契约	`cmd/launcher/launcher.go`	Launcher、SubLauncher、Config
选择器	`cmd/launcher/universal/universal.go`	按第一个关键词选择入口
预设组合	`cmd/launcher/full/full.go`	console + 全部 web 子入口
生产组合	`cmd/launcher/prod/prod.go`	REST API + A2A
终端运行	`cmd/launcher/console/console.go`	Session、Runner、stdin 循环
HTTP 运行	`cmd/launcher/web/web.go`	router、sublauncher、HTTP server
REST 挂载	`cmd/launcher/web/api/api.go`	创建 `adkrest.Server` 并挂到 path prefix

整体关系可以先压缩成一张图：

Agent Development Kit (ADK) · 04 - Model

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Model：统一接口怎样连接不同模型服务

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 配套阅读：Quickstart、Flow、Tool。

Flow 已经准备好用户消息、历史、指令和工具声明，下一步要把请求交给模型服务。Gemini 和 OpenAI 的请求字段、角色、函数调用与流式事件并不相同；Model 层把这些差异放在适配器中处理，向上提供统一的 LLMRequest → LLMResponse 接口。

实现了同一个 LLM 接口，不代表所有模型支持相同的配置和工具。这篇文章围绕一次天气函数调用，说明统一数据怎样跨过 provider 边界，以及信息在转换中如何被保留或拒绝。

一、源码入口与阅读地图

model/
├─ llm.go LLM / LLMRequest / LLMResponse
├─ registry.go 模型名正则 -> Factory
├─ gemini/gemini.go GenAI SDK 适配器
├─ openaimodel/
│ ├─ openai.go Responses API 调用与流式收尾
│ ├─ request.go 请求、消息、配置转换
│ ├─ tools.go 函数声明与 tool choice
│ ├─ response.go 返回内容、usage、结束原因
│ └─ stream.go Responses 事件 -> GenAI 中间结构
└─ apigee/apigee.go 配置代理后委托 Gemini adapter

入口 / 文件	阅读时要回答的问题
model/llm.go	上层到底传什么、收到什么
Flow.callLLM	哪些 callback 返回后不再调用模型
gemini.GenerateContent	普通调用和流式调用如何选择
buildOpenAIParams	通用请求如何转换成 Responses 参数
streamTranslator	provider 的 delta 事件怎样转成通用 part
streamingResponseAggregator	增量和完整响应怎样共存
model.Register / NewLLM	字符串名称怎样解析成实例

二、核心接口与数据结构

1. 两个方法的公共契约

下面是接口与请求结构的源码摘录：

Agent Development Kit (ADK) · 07 - Flow

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Flow：一次 LLM Agent 回合是怎样跑完的

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。以下“当前实现”均指这个版本。

返回源码阅读合集 · 配套阅读：Runner、Context、Tool、Plugin。相关模块的阅读顺序见合集。

用户问“杭州天气怎么样”，模型返回 get_weather(city="Hangzhou")。到这里，天气查询还没有执行，用户也还没有得到答案。程序还必须找到工具、执行代码、把结果交回模型，并判断是否还要继续调用模型。

Flow 就是把这些阶段接起来的内部控制层。 它让一次模型调用成为可以反复“请求 → 执行 → 反馈”的 Agent 运行过程。理解它，关键是同时追踪控制流和数据：下一步由谁触发，上一轮结果又通过什么对象进入下一步。

本文回答三个问题：

谁创建 Flow，它依赖哪些接口和数据？
一条模型 FunctionCall 如何变成工具结果，再进入下一次模型请求？
Flow 与 Runner、Model、Tool 之间的职责边界在哪里？

主线先看普通 Run 的一次工具调用闭环；SSE、确认、transfer 和 Live 放到第四节展开。本文不是 Workflow scheduler 或 Session 数据库实现的完整说明。

阅读准备。 只需要了解 Go 的接口、指针、map，以及大语言模型的 Function Calling：模型输出函数名和参数，实际函数由应用执行。如果不熟悉 iter.Seq2，第三节会结合代码解释；无需先掌握 ADK 的全部模块。

先约定几个容易混用的词：

术语	本文中的含义	天气例子中的数量
Session	持续保存多次交互的会话及其历史、状态	1 个，可以继续提问
Invocation	一次执行上下文所关联的运行；恢复路径可能沿用原 invocation ID	普通无暂停路径为 1 次
Flow step	一次 `runOneStep`：准备请求、消费模型响应、处理工具及后续动作	通常 2 步
模型调用	真正进入 `GenerateContent`；BeforeModel 可使它被跳过	本例 2 次
Event	一条向上返回的运行记录，可能承载文本、函数调用、结果或控制信息	主线为用户输入、调用、结果、答案 4 条；外层还可能有控制事件
Partial / final	Partial 表示响应尚未聚合完成；`IsFinalResponse()` 是事件的结束判定方法	不是“每条 Event 都是一轮模型调用”

第一次阅读可先读第一至第三节，再看第五至第七节；第四节用于沿具体问题深入。文中标为“源码摘录”的代码对应固定 tag；省略外围代码会明确说明。“伪代码”“示意数据”和教学示例不冒充源码原文。

ADK-Go 源码阅读系列

Sat, 19 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读合集

用户发来一句“杭州天气怎么样”，从接收输入到给出答案，中间会经历模型请求、工具执行、事件保存和下一轮推理。多 Agent、人工确认、流式输出和长会话则会改变这条路径。

这个系列沿着一次请求追踪 ADK-Go 的实现：谁创建对象，谁调用接口，数据在哪一步变成事件，结果又如何成为下一次输入。 各篇聚焦一个模块，并用相邻模块的实际调用方说明它的边界。

系列源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

各篇使用同一版本的接口、实现和调用方。普通 Run、Live、不同模型适配器与存储后端的行为分别说明；一种运行方式的结论不自动适用于其他方式。

阅读路线

Overview / Quickstart
 ↓
Launcher / Model / Agent
 ↓
Runner → Flow → Tool
 ↓
Context → Session / Event
 ↓
Memory / Plugin / Workflow
 ↓
Artifact → Server → Registry
 ↓
Auth / Telemetry / Platform

如果还不了解 ADK，先读 Overview 和 Quickstart；如果已写过简单 Agent，可从 Flow 的天气示例进入，再沿 Runner → Tool → Context → Session 追踪它上下游的实现。

Attention 背后的数学：Q、K、V 白话详解

Mon, 31 Aug 2026 00:00:00 +0800

基于 Outcome School 文章《Math behind Attention - Q, K, and V》的中文整理与扩展讲解。

原文链接：https://outcomeschool.com/blog/math-behind-attention-qkv

原文作者：Amit Shekhar

原文页面标注日期：2026 年 4 月 3 日

一句话理解 Attention

Attention 可以理解成：

每个词都先问一句：“当前情况下，我应该重点参考哪些词？”然后根据相关程度，从其他词那里提取信息，形成一个包含上下文的新表示。

例如句子：

I love AI

处理 I 时，模型可能会发现 love 和它关系比较大，于是给 love 更高权重；处理 AI 时，也可能重点参考 love。

完整公式是：

Attention(Q, K, V)
= softmax(Q × Kᵀ / √dₖ) × V

这条公式可以拆成 6 步：

文字
 ↓ embedding
数字向量 X
 ↓
生成 Q、K、V
 ↓
Q 和 K 做匹配
 ↓
Softmax 转成权重
 ↓
用权重加权混合 V
 ↓
得到包含上下文的新向量

梁文锋投资人会议文字稿（修订版）

Thu, 23 Jul 2026 00:00:00 +0800

梁文锋投资人会议文字稿修正稿

文章

仅在原稿上修正了错别字、错误术语和逻辑不通顺的地方

会议时间：5月20日会议时长：4 小时会议目的：DeepSeek 创始人梁文锋与投资人交流会

我以及我们公司的其他同事，我们一开始来做这个公司，初衷是没有想到说我最后要赚多少钱，要到资本市场上去，要上市，要怎么样的，所以我们是没有这个初衷的。

最开始的几十个人完全没有这么想过。如果他这么想，他就不会来。所以总体讲，我们是怀着一个对这个世界非常大的善意来做这个事情，然后我们觉得这是对人类有用的，这是一个金钱以外的事情。

当然，到了后面，这个事情发现利益非常大之后，又有其他的诱惑，这个是另外的事情。但是我们出发的初衷、我们的愿景，以及我们保持到现在的这个愿景，不是按照一个商业利益最大化的方式来做的。我觉得这点比较关键。

大概二十年前的时候，在管理上我最崇拜的是杰克·韦尔奇，就是 GE 的前 CEO。现在回来看，他说的大部分东西可能都已经不对了，但是他最重要的一点说对了：一个公司最重要的是它的愿景。

管理一个大公司，靠的不是你的规章制度，靠的是愿景。愿景是什么呢？愿景不是挂在墙上的标语，愿景是你怎么做，不是怎么说，就是你怎么实际运行。反正杰克·韦尔奇说的原话我忘了，大概是这个意思。

所以，我们是怎么管理这么多人、怎么组织起来的？其实我们没有组织，就是愿景驱动的，靠一个愿景来组织。我们是没有组织的。

这个有好处，也有坏处。未来我们会想办法扬长避短，但这个是我们的特色。我们并不是以一个"我要实现什么 KPI、没有考核"的方式来做，只有愿景。

这个愿景甚至也不是成文的，并不是写出来的，没有写出来过任何东西。这个愿景是在我们做事情的方法、我们对待这个世界的态度里。可能我们公司每个人对这个愿景的理解也不一样，可能每一个人的愿景也是有差别的，但是在一个大的方向上是一致的。

我觉得还是怀着对这个世界非常大的善意，然后想做一点事情。我们是用这个来组织起来的。

接下来我先讲，讲完之后大家再提问。我可能会围绕着这个愿景来讲后面的事情。这个愿景是真的，不是编出来的，我们是真的这么想，真的这么做的。否则你没法解释我们的很多事情。

这个愿景为什么我们这么坚持开源？因为这个愿景本身就要求开源。你没有这个愿景，你没法把人组织起来。

比如说，智谱也开源，但是智谱的开源跟我们的开源不一样。智谱的开源有一种被迫的感觉，他们觉得这不是本意，但是对我们来讲，这就是我们的本意。

然后在开源这个事情上面，我们一开始就想得非常清楚。首先，第一个就是愿景；第二个，我们认为要把 AI 这个事情在商业上做成，开源是有好处的。

这听起来有点矛盾，有点违反直觉，因为在历史上，开源跟商业化都是有冲突的。但我觉得 AI 跟以前不一样。因为在历史上，一个软件公司，它的市场一年可能就几十亿美金，你开源了，它就没有了，可能就只剩下几千万或几亿美金了。

但是 AI 这个事情足够大，最终它可能得占掉人类社会 GDP 的百分之十，比如说。那么它其实是一个非常大的数字。一个人独占这个事情，你不可能独占这个事情，你一定得跟别人分享，否则你肯定活不下来。

这跟之前开源做一个软件可能是不一样的，因为那个软件的市场就没那么大。但是 AI 这个事情实在太大了。如果说我们想独占这个利益，那么一定是要被历史抛弃的。我觉得最主要这是一个客观的规律，这是一个历史观。

并不是说我不开源，我就能够独占这个市场，这在理论上就不符合客观事实。你一定会遇到很多阻力，一定会有其他的方法阻止你实现这个目标。

在这种情况下，我觉得不一定要按照传统的商业思维。你需要有一套机制来确保你自己能够获得的利益是有限的，那么你才有可能做成。需要克制，我觉得是需要克制。

如果说我们想在我们手上把 AI 这个事情做成，首先第一个，我觉得是需要克制的。不能够想着人类 GDP 的百分之多少都归我了，或者说中国 GDP 百分之多少都归我了。你越这么想，越做不成。

所以我们从一开始就觉得需要克制。你越克制，你越有可能能够做成这层事。这是一个商业上的考量，当然这是一个宏观的考虑。

我觉得这是符合直觉的，至少是符合我的直觉，或者说至少我是真的这么想的。我们并没有非常多的其他优势，我们没有什么本事，我们并没有比别人有钱，也没有说我们人员比其他公司更好，其实没有的。

你想，我们两年前成立这个公司的时候，我们又没有很多钱，又没有很多卡，又没有什么知名度，又没有什么号召力，我们就是一群非常平凡的人。

[00:11:49]

我真的就是一群平凡的人。如果说喜欢的一个叙事是一群平凡的人做出了不平凡的事情，而不是一群天才做出了不平凡的事情，这个跟我们的克制是很有关系的，跟我们的克制、跟我们的愿景是一脉相承的。

那么，开源跟商业化会不会有冲突？我觉得在 AI 这个事情上面，你不克制，你就做不成。

开源是属于克制的一部分，那么我们的克制不仅表现在开源上面，我们还表现在很多方面上。但总体上来讲，我们是不用考虑开不开源这个事，不用考虑要不要克制这个事情。

你越克制，可能就越容易做成，或者说至少到目前为止是印证的，到目前为止是能解释得通的。否则没有办法能够解释为什么我们能够做成：我们并没有什么武器，起点又非常低，资源又非常少，我们的人其实也就是随机的一群平凡的人。我自己也就是一个大学毕业的学生，也不是最顶级的那个学校毕业的。

这个克制也是我们愿景里的一部分。AI 这个事情太大了，利益太大了。我们非常克制，只要能够做成，最后利益都会非常大。你随便分一点，利益就非常大，所以现在根本不用考虑拿这里面的哪一部分利益、怎么拿，我觉得根本不用考虑这件事情，因为这个利益足够大了。

你只要分一点点，就已经很足够了。所以我们之前说，我们只赚取一个合理的利润，只看你的意愿，而不是利润最大化，这个是不一样的。这不是我们的 API 定价。我们 API 定价觉得一个合理的利润，大概是我们到市场上买一批设备回来，十个月收回成本，我觉得这是一个合理的利润。

在当前的情况下，考虑到你有风险、还有前期的投入等等，如果一个服务器我们在财务上按照三年或者五年的摊销，但在商业上，我们觉得大概十个月收回成本，我们觉得够了，OK，我们觉得够了。所以这个是我们现在 API 定价的逻辑。我们的 V3.2 Flash 跟其他的，都是十个月收回设备的成本。