Artificial Intelligence 与个人主动型 AI 助手的发展讨论

聊到 Claude Code、Codex 和其他 AI 的能力区别时，我们先谈到了 Harness。像 Claude Code、Codex 这样已经搭建了较完整工作环境的产品，交付结果受到模型、工具和工作流程的共同影响。如果选择了一个更强的模型，却没有清楚的提示、合适的工作环境和完整的任务逻辑，工作产出未必就能提高。

我的直觉是，对相当一部分日常任务，豆包工作或者豆包本身已经够用了。多数使用者未必会把模型能力推到极限，更常遇到的问题，可能是需求没讲清楚、资料没有准备好，或者不知道该怎么拆解任务。当然，到了复杂编码、专业推理和需要反复核实的工作里，模型之间的区别仍然会体现出来。

Claude 模型的发展也早于 Claude Code 带来的这一轮关注。我记得，在 Claude Code 被更广泛讨论之前，Claude 的能力已经在 Cursor 等工具的用户中受到关注。后来让人印象更深的，是它能在一个完整环境里把事情做完。对普通使用者来说，这种交付结果比单独讨论模型参数更容易感知。

还有一点值得带到后面：当你深入使用一个模型或产品时，它也在培养你的使用习惯。历史资料、工具配置和协作方式一点点积累，下一次工作就会接着上一次继续。这个持续贯穿任务的 Context，是我理解 Agent 如何吸引用户、留住用户时很看重的一部分。

ChatGPT 补注｜模型与 Harness 共同影响交付

• 纠错 · Harness 可以组织上下文、工具、执行状态与反馈，帮助模型稳定工作，但无法抹平模型能力差异。通用助手是否“够用”需要落到具体任务上，目前引用的资料不足以给出覆盖普通用户需求的固定比例。^[1][2]

• 知识点 · Claude 3.5 Sonnet 先于 Claude Code 研究预览发布，可以确认模型与产品的发展有先后；公开发布信息不足以证明某个地区何时“爆火”，或把热度主要归因于 Harness。^[3][4]

• 补充 · “豆包工作”是明确的产品名称。飞书官方将其描述为与飞书原生融合的 AI 工作产品；不宜进一步概括成飞书整体与豆包合并。^[34]

• 知识点 · Context 可包括本次任务材料、历史记录、检索结果与工具状态。使用习惯、长期记忆和迁移成本与它有关，但获客、留存也受价格、渠道和实际交付质量影响。^[1][2]

回到个人主动助手的发展方向，我本来很看好“豆包手机”这种形态：通过软硬件结合来售卖，大家对着手机讲话，内置助手就能完成各种操作。如果用起来足够顺畅，它很有可能改变我们的生活习惯，也会成为 AI 变现的一条重要路径。

对方对这条路的判断更谨慎。他提到，个人助手进入硬件已经有相当长的探索过程，华为、阿里等公司都尝试过把语音或模型能力放进设备。软件公司想顺着 AI 的发展进入硬件，还需要补上行业经验、制造、供应链和渠道这些环节。

讨论中还提到了豆包的 Ola Friend 耳机。它把语音助手做进了一个随身入口，但产品形态成立之后，仍然有一笔账要算：用户为什么要额外买一件硬件？增加的便利能否支撑价格？成本、利润率和使用频率能否形成持续的生意？我觉得这些问题比“能不能把模型接进去”更难回答。

同时，它还会面对已有硬件厂商的竞争。华为在耳机和手机上的积累很深，一些耳机已经能够唤醒豆包这样的第三方应用。用户要使用同一种 AI 服务，未必需要购买 AI 公司自己推出的设备。这也让独立硬件的差异化变得更重要。

软硬件结合仍然是一种值得关注的模式，但软件能力很难自动迁移成硬件优势。工业化经验、制造成本、交付与售后，都会影响最后的产品。我更想继续观察的是：这些额外投入，最终能不能换来手机 App 很难提供的体验。

ChatGPT 补注｜硬件入口还要面对成本与使用频率

• 知识点 · Ola Friend 确有其产品，是豆包出品的开放式智能耳机，通过手机上的豆包 App 提供交互能力。华为部分耳机支持唤醒豆包，但有型号、软件版本和绑定条件，不能推广到全部产品。^[5][6][26]

• 纠错 · 目前引用的公开信息不足以证实 Ola Friend 的总体销量、利润或商业成败。硬件成本和利润率值得作为商业问题讨论，但不能仅凭产品形态推断某条硬件路线已经失败。^[5]

• 知识点 · 语音助手与智能硬件已有多年积累，阿里也公开过通义千问接入天猫精灵等产品的计划。能响应语音指令与能持续理解需求、主动行动，属于不同的能力要求。^[7]

讲回应用本身，我们谈到了个人主动助手的三个核心问题：能否把复杂交互留在后台，能了解用户多少，以及能不能主动推进事情。其中，Context 延展出了最多的话题。一个助手如果每次都要从头认识你，再强的能力也很难真正融入生活。

对方比较看好拥有庞大生态的平台，典型的例子是微信和苹果。它们已经进入了通讯、工作、消费和娱乐等高频场景，能够形成连续的使用习惯。我理解他的判断：谁离用户的日常生活更近，谁就更有机会建立一个完整的个人助手。

以苹果为例，Apple Music、播客、通讯工具和 App Store 组成了一个长期积累的生态。我的设想是，如果系统可以用统一接口连接不同应用，助手获取信息和执行任务就会更直接，不必每次都在不同页面之间反复操作。个人资料和使用习惯积累得越深，用户换到另一个平台的成本也可能越高。

支付宝也是一个值得观察的入口。支付、出行和生活服务，本身就和一个人的日常安排紧密相连。它与其他平台的合作，是否能进一步延伸到购物和工作场景，会影响助手能完成多少事情。

相比之下，豆包手机要推进跨应用操作，就会直接面对接口和权限的问题。其他平台愿意开放到什么程度，哪些操作只能通过界面完成，哪些行为会被限制，都关系到最终效率。用户希望助手少走几步，应用平台则需要考虑业务、安全和竞争关系，这些诉求未必总能对上。

硬件合作可以帮助助手进入系统，但无法一次解决所有应用之间的边界。软件公司进入手机生态，也需要和厂商、开发者逐步磨合。对我来说，这正是个人助手有吸引力、同时又很难做的地方：它承诺的是一套连续体验，背后却连接着许多各有规则的服务。

Context 的价值，最终还是要落到对一个人的理解有多深。我猜想，当用户足够信任自己的 AI 助手时，可能愿意告诉它一些平时不会随意公开的事情。长期使用积累的资料、偏好和习惯，会让助手越来越贴近个人，也让这种关系更难迁移。平台生态在这里有优势，但优势能转化成多少实际能力，还要看它能不能把这些信息用对。

ChatGPT 补注｜个人 Context 的价值取决于质量和权限

• 纠错 · 苹果的 App Intents 由开发者提供可调用的动作与内容。操作系统整合能力不等于可以强制读取全部 App 的内部数据；开发者开放范围、用户授权与隐私设计仍然构成边界。^[8][9]

• 纠错 · 蚂蚁集团、支付宝与阿里巴巴旗下的淘宝不能视为一个天然互通的数据池。生活服务生态能够提供入口，具体的信息和操作权限仍需看合作及授权安排。^[12]

• 知识点 · 豆包手机助手已有手机厂商的系统级合作，界面操作与工具调用可以并存，不能仅归结为安卓辅助功能。豆包公布的 SAEP 策略也明确了第三方应用拒绝屏幕自动化的边界；这是平台自身的策略，不代表行业已有统一规则。^[10][11]

• 补充 · 大型生态有场景和入口优势，但用户授权的连接器、开放接口与端侧处理也能组织个人信息。Context 的价值还取决于相关性、准确性、时效和可检索性；信息越多，不会自动意味着判断越好。用户是否愿意分享私密信息，也需要具体观察。^[1][9]

接着往下想，具备主动性的 Personal Agent 究竟意味着什么？过去我们先想到要做一件事，再打开应用、输入需求。未来的个人助手如果已经了解我们的工作和生活，就有机会先发现需要推进的事情，主动给出推荐和安排。

比如，我和客户聊到了下周见面的时间。如果相关消息和日历已经获得授权，助手就可以提取约定、检查时间，再把日程整理出来。我不需要把同一件事重新告诉它一遍。一个能把分散信息接起来的助手，对我的帮助会比多一个问答入口大得多。

这种设想还可以延伸到出行、消费，甚至财务安排。它了解我的行程、住址和已经授权的账户信息，就有可能做出更贴近个人情况的规划。相比普通私人助理，它能够持续处理的信息量更大，也不必把工作时间限定在一天的几个小时里。当然，它能看见哪些信息、能替我决定到哪一步，是需要另外约定的。

交互上，我希望它把大部分过程留在后台，直接递交结果。用户没有必要一直看着搜索、读取文件和调用工具；只有真正需要自己判断的地方，再停下来沟通。从使用体验来看，这是一种很深的产品封装：复杂的工作仍然发生着，但人不必陪着系统走完每一步。

顺着这个想法，还可以继续问：如果中间步骤不再反复组织成人类可读的文字，是不是也能减少一部分开销？省掉这些来回转述之后，系统能否把更多计算用在真正需要解决的问题上？

如果这样的助手逐渐成熟，一部分基础 App 的操作入口可能会被它接管。原来需要自己打开日历、搜索行程、整理消息的步骤，都有机会放到一次任务里完成。用户长期依赖它处理事情，习惯和资料也会继续积累。从商业角度看，这种持续使用形成的黏性，是个人助手很有价值的一部分。

ChatGPT 补注｜隐藏过程与减少计算需要分开判断

• 纠错 · 聊天生成日历在这里是有授权前提的产品设想，不能读成微信已默认持续读取全部聊天并自动排程。现有条款按用户操作、指令与任务使用相关内容；模糊意向与确定约定也需要区分。^[13]

• 知识点 · 读取账户信息、给出建议和执行交易属于不同能力与权限。个人助手能接入更多数据，也仍需处理判断错误、时间冲突、授权范围和行动后果。

• 纠错 · 隐藏中间过程不会自动节省计算。未展示的推理仍可能消耗 Token；减少无用生成、压缩传输、改用结构化数据，则是需要单独评估的优化。^[19]

• 补充 · 助手接管前台操作后，日历、支付、出行等服务仍可能以工具或接口的形式存在。长期黏性也需要建立在可靠交付上，包括让用户查看和修正记忆、理解重要行动，并在需要时停止或接管任务。^[1][2]

话题后来回到了自动化。对方提到，可以沿着工业革命以来的这条线索去理解 AI：机器逐渐接手人的体力劳动，计算机承担大量信息处理，今天的 Agent 则在尝试接手更复杂的知识工作。这样看，许多看似全新的产品，也和过去的技术变革有相通之处。

他比较看好 Anthropic 这类 AI 公司的发展潜力。苹果曾经展示了科技平台可以扩张到怎样的规模，而依托模型和信息处理能力的公司，业务复制的速度可能更快。这让我想到，AI 公司的想象空间，很大一部分来自它能把多少原本依赖人的工作变成持续运行的服务。

GPU 等底层计算能力，是这种扩张的重要条件。适合并行的任务可以被更快地执行，已经形成的方法也有机会反复部署到新的场景里。对我来说，值得关注的是这种组合：算力、软件和任务组织逐渐成熟之后，一家公司服务更多客户，是否还需要按同样比例增加人手和成本？

从蒸汽机、工业生产到软件和 Agent，自动化始终在拓展人们对效率的想象。我更愿意沿着这条线继续想：当前我们在尝试让 AI 完成工作，下一步也许会进一步改变信息流动的方式——如何找到信息，如何判断和处理它，再把它交给下一个能够行动的环节。

如果这些过程能够持续复制，未来确实可能出现覆盖范围更广、规模更大的公司。但“信息自动化”具体会长成什么样，还很难提前给出定论。它最终能走多远，我觉得要看那些复杂的任务，能否真正被拆解成稳定交付的工作。

ChatGPT 补注｜自动化是观察产业变化的一条线索

• 纠错 · 自动化适合作为观察工业革命以来技术变化的一条线索，不能概括全部人类历史，也无法单独解释公司规模与市值。关于信息分发和企业扩张的判断，还需要结合需求、成本、竞争与制度环境分析。

• 知识点 · Anthropic 是公司，Claude 是模型与产品品牌。对发展潜力的看好属于判断，不能直接推导上市进程、估值或投资回报；本文不据此补充相关预测。^[25]

• 纠错 · GPU 与 CPU 没有固定的数量换算关系。实际加速取决于任务并行度、算法、数值精度、内存和通信等条件，硬件速度也不能直接换算为公司增长速度。^[14]

讨论到 AI 自身的发展时，我原本试着把 Transformer、Agent 和 Harness 放在一条线上理解：模型处理信息，Agent 分工完成任务，再由 Harness 把执行过程组织起来。它们都让工作更容易自动化，但具体怎样连接，我当时并没有完全想清楚。尤其是模型里的注意力机制，和应用里多个 Agent 的协作，是否真的有对应关系，这是我需要补课的地方。

我们还谈到了输入、内部处理和输出。在我的直观理解里，输入和结果比较容易看见，中间究竟怎样得出答案却很难解释，所以常常被称为“黑箱”。如果研究者能够更细地观察这些内部过程，找到哪些环节影响结果，再逐步优化，AI 的能力和可控性是不是都能向前推进？

顺着这个问题，我也会想：系统能否逐渐学会选择更合适的处理路径，减少不必要的步骤？如果它能根据输入和结果不断调整，把寻优过程也逐步自动化，我们能够交给机器完成的工作是不是还会继续增加？

另一个让我感兴趣的问题，是中间表达链条有没有可能缩短。从使用者的角度看，深度思考（thinking）或推理过程很像系统在一步步组织分析。可这些步骤是否都需要写成自然语言？如果下一步只是把数据交给另一个工具，直接传递结构化结果，会不会比重新解释一遍更合适？

我想追问的是：哪些表达是任务本身需要的，哪些只是为了让人阅读？系统内部已经有自己的计算过程，人能看到的文字只是其中一部分。如果能把这些环节分清，就有可能找到重复生成和来回转述的地方，再具体讨论怎样减少开销。

这也让我想到一个很粗浅的类比：电脑主机不用一直接着显示器也能运行，程序员还可以通过 PowerShell 直接组织任务。人能看懂的界面，并不需要出现在每一个执行环节。Agent 会不会也逐渐采用更适合机器协作的表示方式，只在需要沟通、检查和交付时，再转换成人容易理解的形式？

我对“思考”这件事仍然有疑问。人脑里的活动与说出口的语言，并不能完全画上等号；AI 接收到自然语言后，也未必必须始终用同一种形式继续处理。未来的系统能否在文字、结构化数据和其他内部表示之间选择，取决于什么方式更适合当前任务，这是一条我想继续了解的方向。

ChatGPT 补注｜Transformer、Agent 与 Harness 处在不同层级

• 纠错 · Transformer 的注意力机制属于模型内部计算；Agent 组织模型、工具和环境反馈来完成任务；Harness 提供持续执行所需的上下文、状态和约束。多 Agent 分工不等于把注意力头展开成独立助手，也不能据此写成一条技术演进史。^[15][16][2]

• 知识点 · AI 包括多种技术路线，不能整体等同于模拟神经网络。Transformer 的运算结构可以明确描述，“黑箱”主要涉及学到的表示和具体输出成因难以完全解释。机制研究已有进展，但观察内部状态仍不等于完全理解模型；执行时调整计划也不等于自动修改模型权重。^[15][17]

• 纠错 · Token 是模型处理的信息单位，算力是执行计算的资源。简化的文本流程包括编码、数字表示、网络计算和解码，不存在“Token 变算力再变机器语言”的通用转换链条。自然语言中间步骤也可能帮助求解，不能一概视为额外的显示包装。^[18][15]

• 知识点 · 连续潜在空间推理已有研究。Coconut 尝试让隐藏状态直接参与后续推理，减少逐步解码为文字的需要；特定任务上的结果说明这一方向值得探索，但不足以证明所有 Agent 都会更快、更省或更可靠。模型本来就在数值空间计算，也不宜称作突然拥有一种全新的“机器语言”。^[20]

• 补充 · PowerShell 是命令行、脚本与自动化工具，本身并非 Agent 或机器语言。“不用显示器”的类比只适用于展示与执行的区别。人类语言和思考的关系也不足以推出自然语言推理违背认知规律；不同表达路径仍应比较正确率、时延、成本和可检查性。^[21][20]

回到产品视角，我还是想把输入、内部处理和输出这三步保留下来。不过，设计时可以先从第三步倒推：用户最后想得到什么，怎样的结果最容易理解、最方便使用？想清楚这一点，再回头决定需要哪些输入、怎样组织处理，可能更接近真正的需求。

第一步是输入与预处理。输入可以有很多形式，文字、声音、图像，甚至更直接的信号。脑机接口让我想到，人与机器之间的沟通方式还有很大的变化空间。如果某些意图不必先完整转换成一句话，就能进入系统处理，交互过程也可能发生变化。这里我关心的是输入渠道带来的可能性。

知识库也是一个让我比较容易理解的例子。长材料需要切分、组织，再变成便于检索的表示。我当时想到“向量切片”和“降维”这些做法：如果输入已经过预处理，能否让后续步骤更快拿到完成任务真正需要的内容，减少反复理解和传递信息的开销？

第二步是内部处理。拿到合适的输入后，Agent 应该能够判断怎么做：直接回答、继续查找、调用工具，还是把任务拆给不同的执行环节。我期待它能够在结果不够好时调整路径，逐步积累完成任务的方法。至于哪些能力通过训练形成，哪些由运行时的流程和工具提供，需要根据任务具体设计。

第三步是输出与交付。就像人向新人解释一件事，会灵活地画图、讲解、举例或者演示，Agent 也应该判断哪种形式最适合当前问题。文字讲不清楚时可以画图，数字多时可以做表格，需要实际操作时就交付能用的结果。能够主动选择表达方式，我觉得是产品成熟很重要的一步。

我想要的自主判断力，还包括对成本和效果的权衡。输出图像、视频或者更复杂的交互内容，当然可能更直观，但也未必每次都值得做。系统能否知道何时应该展开、何时一句话就够了，最终影响的是理解效率和使用体验。

如果能把输入、处理和交付整理成可复用的任务单元，就有机会把已经完成的一类工作，继续组合成更复杂的流程。多 Agent 的协作也可以在这个基础上展开。我期待的是这种不断抽象、封装和扩展的过程：今天还需要人反复协调的工作，未来是否可以由系统更完整地接住。自动化能推进到什么程度，也会继续改变我们对 AI 的想象。

ChatGPT 补注｜输入、处理和交付之间需要反馈

• 纠错 · 相关脑机接口临床研究通过记录神经活动并解码成光标等控制信号，不能概括为模拟神经突触或恢复所有身体功能。它可以启发对输入渠道的讨论，但与大语言模型推理机制不同，也不意味着通用思维已经能够直接数字化传输。^[22]

• 知识点 · 分块是把材料拆成适合处理的单元；Embedding 把内容编码成用于相似度等计算的向量；降维减少表示的维度；量化降低数值精度。向量化不会自动让数据更小、传输更快，也不能取代后续理解。压缩与预处理应检查任务信息是否丢失。^[23][24]

• 补充 · “输入—处理—输出”适合作为产品设计框架，三步之间还需要反馈和检查。Agent 可以根据工具结果修正计划，但这与训练模型权重属于不同过程；任务失败后如何恢复，也应进入设计。^[16][2]

• 纠错 · 多模态已是现有能力。输出形式的选择可以由模型、提示、路由、工具和后训练共同实现，不必只靠预训练；一般的路径优化也不自动构成博弈论问题。图像或视频可能增加成本，不能保证节省 Token。^[1]

• 补充 · 标准化有助于复用，但不会自动带来无限泛化，也不等于解释模型内部机制。多 Agent 还会引入协调开销和错误传播；应根据任务需要选择数量，并明确目标、权限、停止条件与错误恢复方式。^[1][2]

第一次见面交流时，我还有不少很基础的疑惑：模型到底怎么选，推理成本为什么会下降，Agent 的普及又会给芯片和数据中心带来什么变化。下面按我的记忆，整理当时听到的解释和留下的思考。

1. 模型选型：榜单、调用量和业务效果，应该先看哪个？

公开榜单排名高、平台调用量大，能说明一个模型更适合我的具体业务吗？

我的理解

选模型时，榜单排名和调用量是很容易看到的两个指标。交流中也聊到，企业客户往往会用自己的任务做评测。我的理解是，公开测试里的高分、平台上的热度，以及客户真正用起来的效果，可能存在相当大的距离。对于一个具体项目，最后还是要回到它需要完成什么工作。

ChatGPT 补注

• 知识点 · 榜单、调用量与业务成功率各有统计边界。OpenRouter 的排名反映经其平台路由的使用情况，不能直接外推全球市场份额；token 量也不能作为模型能力评分。^[27]

• 补充 · 选型时可以先准备一组真实任务，统一输入、权限和工具条件，比较完成率、错误类型、人工返工量、总成本与延迟。这样的结果更容易转化为采购或部署决策。

2. 参数与成本：模型变大，单次推理为什么还能变便宜？

总参数不断增加，是否意味着每次调用都要付出更多计算和存储成本？

我的理解

这一点最初让我有些困惑。按直觉理解，模型越大，计算就应该越贵。交流中提到了 MoE 和低精度计算：工程师可以一边扩大模型规模，一边设法控制每次任务实际用到的计算量。我才开始理解，讨论一个模型有多大，和讨论它运行一次有多贵，需要看不同的指标。

ChatGPT 补注

• 知识点 · MoE 需要区分总参数与每个 token 激活的参数。每次计算通常只调用部分专家，因此总参数增加，并不意味着单次计算量同比增加。总参数仍会影响权重存储，专家路由和跨设备通信也会带来开销。^[28]

• 补充 · 推理成本还受精度、上下文长度、输出长度、批处理和硬件利用率等因素影响。降低数值精度可以减少部分资源开销，但需要结合模型效果与硬件支持评估，不能仅凭参数量判断质量或价格。^[29]

3. KV cache：单次推理更省显存，行业总需求会减少吗？

如果 KV cache 压缩越来越有效，能否据此判断未来的显存或存储需求会下降？

我的理解

听到模型可以通过优化减少缓存占用时，我想到的是另一个问题：如果每次推理需要的资源越来越少，当前市场对基础设施需求的预期，会不会偏高？这是我从设备和项目的角度很关心的问题。算法每前进一步，究竟是在压低资源需求，还是让更多原本太贵的应用变得可行，值得继续观察。

ChatGPT 补注

• 知识点 · KV cache 保存自回归推理中已计算的注意力键和值，以减少重复计算。其占用与模型结构、序列长度、并发等条件有关；缓存压缩减少的是特定环节的资源开销，模型权重等需求仍然存在。^[28][29]

• 纠错 · 单位任务更省资源，尚不足以推出行业总需求下降。还需要把上下文增长、并发数量和调用规模纳入判断，并区分 GPU 显存、服务器内存与持久化存储。不同层级的需求不能合并成一个结论。^[29]

4. 推理芯片：专用化能够解决哪些问题？

训练和推理的负载不同，芯片是否也会进一步分工？专用推理芯片的价值体现在哪里？

我的理解

当时聊到了训练与推理的分工，也谈到面向推理做专门设计的芯片。我的理解是，当一类任务足够明确、规模足够大，就有机会围绕它重新安排硬件和软件。不过，芯片研发有自己的周期，模型又一直在变化。如何在效率和适应能力之间取得平衡，是我听完之后留下的疑问。

ChatGPT 补注

• 知识点 · 推理内部还可区分 prefill（处理输入上下文）和 decode（逐步生成输出），两阶段的资源需求有所不同。专用化可以围绕计算、内存、带宽和调度展开；哪些环节被固定下来，要看具体架构。^[29]

• 补充 · 专用推理芯片已有公开产品，例如 Groq 的 LPU。厂商公开的架构说明能帮助理解其设计取舍；实际选型仍应比较目标负载下的效果、成本和软件支持，不能直接推导出 GPU 将被全面替代。^[30]

5. 训练平台：为什么峰值算力不能代表实际训练效率？

采购训练算力时，除了芯片规格，还需要判断哪些系统能力？

我的理解

看计算设备时，规格和算力数字很容易成为比较的起点。那次交流也谈到了系统能不能持续、稳定地运行：芯片与模型是否适配，任务中断后怎样恢复，团队要花多少时间处理问题。设备纸面上很强，和一个训练任务顺利完成，中间还有不少工程工作。这种差距与我熟悉的项目交付有相通之处。

ChatGPT 补注

• 知识点 · 有效训练效率受到算子、编译器、设备内存、集群通信、检查点与故障恢复等环节共同影响。还需区分用户访问数据中心的广域网延迟，以及训练集群内部的通信延迟；后者可能直接影响分布式训练效率。^[31]

• 纠错 · 能够训练大模型的平台并不限于 NVIDIA。Google 已公开 TPU 上的大规模分布式训练案例。平台选择应结合模型适配、软件生态、可获得资源和运行成本判断，避免把某个平台的优势写成其他平台无法完成训练。^[31]

6. 基础设施：AI 的扩张会在哪里遇到物理约束？

从模型调用增长到数据中心扩建，电力、散热、网络和建设周期会怎样影响项目落地？

我的理解

话题转到电价、机房选址、供配电和液冷时，我回到了自己更熟悉的领域。模型和应用可以快速迭代，供电容量、建设周期与现场条件却需要逐项落实。也正因为如此，我很关心 AI 的需求最后会以什么形式传递到基础设施端：客户要多大的容量、能等多久，以及愿意为怎样的可靠性和效率付费。

ChatGPT 补注

• 知识点 · AI 的资源需求需要落到服务器、冷却与其他基础设施的实际用能上。项目层面应分别评估可用供电容量、功率密度、冷却条件、网络和建设周期，再讨论总体成本与扩展能力。^[33]

• 补充 · 描述容量时应区分功率与能量：MW/GW 表示功率，MWh/GWh 表示一定时间内的能量。时延要求也需要按业务定义，实时交互与可延后完成的任务，对机房位置和网络的要求可能不同。

7. Agent 运行环境：专属助手需要多少独立资源？

如果 AI 助手长期替用户执行任务，每个人是否都需要独占一个物理 CPU 核？

我的理解

交流中有一个判断让我印象很深：Agent 的普及可能带来更多 CPU 需求。如果把专属助手理解成每个人背后都有一台持续开着的电脑，用来保存状态、调用工具并完成工作，就会想到每个用户是否都需要独立计算资源的问题。这里的专属，究竟要独立到什么程度，我还需要进一步理解。

ChatGPT 补注

• 纠错 · 用户拥有独立身份、权限、状态和执行环境，不等于必须独占物理 CPU 核。运行隔离可以通过虚拟化和调度实现，例如 AWS AgentCore 提供基于 microVM 的会话隔离。^[32]

• 补充 · 估算资源时，应看活跃并发、任务持续时间、工具负载与服务目标。浏览器、代码执行和后台任务确实可能增加计算需求，但注册用户数不能直接换算成同等数量的物理 CPU 核。

8. 商业化与交付：接口越来越相似，客户究竟为什么付费？

当模型 API 越来越容易接入和切换，模型服务、销售与落地交付的价值还体现在哪些地方？

我的理解

这一部分和我的职业关系最直接。交流中谈到了 API 切换、模型价格竞争，以及销售和 FDE（前线部署工程师）的价值。给我留下的一个提醒是，产品最终要在客户的真实使用中证明自己。至于销售和交付工作会怎样变化，我还保留着疑问：企业要完成采购、接入、验证和持续使用，这些事情分别由谁来做，又需要什么能力？

ChatGPT 补注

• 补充 · 以下是本次共同整理时的分析：接口兼容可以减少部分接入工作，但模型行为、工具调用、数据权限、评测、稳定性、限流和支持服务仍需验证。迁移成本需要结合整个业务流程计算。

• 补充 · 对于 ToB 业务，可以继续追问谁能把客户需求转成可验证的任务，谁负责整合业务系统，谁推动部署后的实际使用。销售与 FDE 的分工可能随产品成熟度变化；把某类岗位的消失写成确定结论，目前缺乏足够依据。

这篇交流里最值得继续追问的，是个人助手怎样把“了解一个人”转成“替他完成事情”。Arthur 从产品体验和商业模式出发，抓住了入口、使用习惯、Context 和交付结果之间的联系。这些问题也能落到很具体的观察上：用户少做了哪些操作，系统多承担了哪些工作，新增的计算和交付成本由谁支付。

需要分清的地方集中在三个层级：模型内部怎样计算，Agent 怎样组织任务，产品和公司怎样创造价值。把这三层拆开，原本关于自动化的判断就更容易讨论，也更容易验证。自然语言中间步骤、潜在空间推理和多 Agent 协作各有用途，评判它们仍要回到任务本身：完成得是否正确，代价是否合理，出错后能否修正。

ChatGPT｜核验、补注与共同整理

1. Anthropic｜Building effective agents — Agent、工作流、工具与反馈的工程区分。
2. Anthropic｜Effective harnesses for long-running agents — Harness 与长期执行的局限。
3. Anthropic｜Claude 3.5 Sonnet — 2024 年 6 月的模型发布。
4. Anthropic｜Claude 3.7 Sonnet and Claude Code — 2025 年 2 月 24 日 Claude Code 研究预览。
5. Ola Friend｜产品官网 — 产品存在及基本定位；不证明商业成败。
6. 华为｜耳机豆包 App 唤醒功能介绍 — 支持型号、绑定及 App 运行条件。
7. 阿里巴巴｜通义千问发布公告 — 2023 年宣布接入天猫精灵等产品。
8. Apple Developer｜App Intents 入门 — 开发者向系统提供动作与内容。
9. Apple｜Apple Intelligence 与隐私 — 个人上下文、设备端处理与数据边界。
10. 豆包｜手机助手官网 — 系统级合作、消费者产品与操作方式。
11. 豆包｜SAEP 协议 — 平台公布的第三方应用屏幕自动化策略；不是行业统一规则。
12. 蚂蚁集团｜支付宝 AI 智能助理 — 2024 年 4 月 26 日公告，连接生态服务。
13. 微信｜隐私保护指引 — 按用户操作、指令与任务使用相关内容；不能推出全量持续读取。
14. NVIDIA｜CUDA Best Practices Guide — 并行加速受工作负载与系统瓶颈限制。
15. Vaswani 等｜Attention Is All You Need — Transformer 与注意力的模型内计算。
16. Yao 等｜ReAct — 结合模型推理、行动和环境观察的应用方法。
17. Anthropic｜Tracing the thoughts of a large language model — 内部机制研究及可解释性边界。
18. Hugging Face｜Tokenizer — Token、编码、输入标识及解码。
19. OpenAI｜Reasoning models — 未展示的 reasoning tokens 仍消耗计算与上下文。
20. Hao 等｜Training Large Language Models to Reason in a Continuous Latent Space — Coconut 在特定任务中的潜在空间推理研究。
21. Microsoft Learn｜What is PowerShell — Shell、脚本语言与任务自动化工具。
22. Neuralink｜PRIME Study Progress Update — 临床研究中的神经活动记录与光标控制。
23. Sentence Transformers｜Semantic Search — 语义向量及相似度检索。
24. Sentence Transformers｜Embedding Quantization — 量化压缩及质量权衡。
25. Anthropic｜Company — Anthropic 是公司；Claude 是产品与模型品牌。
26. 豆包｜隐私政策 — Ola Friend 与豆包 App 的连接说明。
27. OpenRouter — LLM Rankings / How these rankings are measured — 只统计经OpenRouter的流量；tokens与requests口径不同；不衡量准确率或推理能力。
28. DeepSeek-V3 Technical Report — 671B总参数、每token激活37B；MoE与MLA用于计算及内存效率。
29. NVIDIA — Mastering LLM Techniques: Inference Optimization — prefill/decode、KV缓存、批处理、显存与模型权重等推理优化要素。
30. Groq — What is a Language Processing Unit? — LPU为特定推理工作负载优化，使用确定性执行和编译调度；是厂商架构说明，不独立证明性能优于所有GPU。
31. Google Cloud — The world’s largest distributed LLM training job on TPU v5e — Google公开在50,000多张TPU v5e上运行分布式LLM训练；直接反证只有NVIDIA能训练大模型。
32. AWS — Use isolated sessions for agents — Agent会话可通过microVM提供CPU、内存、文件系统隔离；不能由隔离需求推出每位用户独占物理核。
33. IEA — Energy demand from AI — 数据中心用电分析区分服务器、冷却及其他基础设施，体现AI的物理资源约束。
34. 飞书｜豆包工作全新发布 — 豆包工作的正式名称、智能体工作平台定位及与飞书的原生融合关系。