Posts

据 TechShots 十月九日报道，由前 DeepMind 研究员 Misha Laskin 与 Ioannis Antonoglou 在 2024 年联合创办的 AI 初创公司 Reflection AI，已完成二十亿美元新一轮融资，由英伟达领投，投后估值升至八十亿美元。跟投方包括前谷歌 CEO Eric Schmidt、花旗以及十七家一线机构。公司成立至今不过两年，团队规模仍属精干，但估值已经踩到 Unicorn 之后的下一档。这一轮数字摆出来，市场最直接的反应是：英伟达不仅在卖铲子，也在押注谁能用这些铲子挖出最值钱的矿。 为什么是 Reflection？ Reflection AI 的核心叙事集中在强化学习与世界模型方向，两位创始人都有 AlphaGo 与 AlphaZero 血脉。英伟达在这个时点领投，逻辑不是单纯财务回报，而是把最前沿的 RL 实验留在自家 GB300 与 Rubin 集群上跑。换句话说，这二十亿美元里有相当一部分会以算力采购的形式回流英伟达自身的数据中心合同。八十亿估值对应的不是当下收入，而是未来两年在具身智能与机器人控制上的训练需求曲线。 对一级市场估值锚意味着什么？ 两年时间从零到八十亿美元，Reflection 的 PS（市销率）暂时还无法用常规口径算清，因为公司尚未披露规模化收入。这恰恰是当前一级市场最棘手的问题：前沿实验室的估值锚已经从 ARR（年度经常性收入）倍数，滑向「创始人履历加算力订单加战略稀缺性」的复合定价。花旗与 Schmidt 的加入，本质是在给这种非财务估值背书。对后续同赛道公司而言，Reflection 把 RL 方向的估值地板又抬高一截。 接下来该盯哪些信号？ 第一件事是看 Reflection 会不会在六个月内公布首份算力采购协议，尤其是与哪家云厂或主权 AI 平台绑定。第二件事是看英伟达会不会把 Reflection 的模型作为参考架构写进 CUDA 生态白皮书。第三件事是观察同赛道 RL 初创在下一轮融资里是否被机构用同一套公式重估。八十亿美元只是起点，真正的考验在两年后收入兑现那一刻。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 OpenAI 官方文档更新，Agent Builder 和 Evals 两个产品将在二零二六年十一月三十日正式下线。这两个产品曾是 OpenAI 平台上的可视化 Agent 搭建和评估工具——拖拽配置提示词、选择工具、跑评测。现在官方给了明确的迁移路径。 如果你之前用 Agent Builder 做的是代码化工作流——比如需要版本控制、CI 集成、复杂逻辑——官方推荐迁移到 Agents SDK。这是 OpenAI 的代码优先 Agent 框架，所有 Agent 定义、工具调用、会话管理都写在 TypeScript 或 Python 里。 如果你用 Agent Builder 只是自然语言配置、不需要写代码，官方推荐搬到 ChatGPT 的 Workspace Agents。这是给非工程师用的图形界面 Agent 搭建入口。Evals 产品则推荐用开源评测框架替代，比如 promptfoo 或 DeepEval。 OpenAI 砍产品的节奏越来越快。从早期的 ChatGPT 插件商店到现在的 Agent Builder，很多面向普通开发者的可视化工具都在逐步收缩。平台的重心明显在往 API 和旗舰模型上集中，非核心的周边产品说砍就砍。 对于依赖这些产品的团队来说，教训很深刻：不要把关键业务建在平台的实验性功能上。Agent Builder 和 Evals 从发布到下线也就一年多时间，如果你在这上面投入了大量配置和数据，迁移成本会很高。更稳妥的做法是用代码优先的 SDK，至少你的资产是可移植的。 如果你现在还在犹豫要不要迁移，建议尽早行动——距离十一月三十日下线只剩一个多月，迁移和测试都需要时间。 为什么 OpenAI 要砍掉这两个产品？ OpenAI 砍产品的逻辑很清晰：集中资源做核心 API 和旗舰模型。Agent Builder 这种可视化工具维护成本高但收入贡献小，不如让开发者去用代码 SDK，或者去 ChatGPT 里点鼠标。平台正在从全栈覆盖转向专注 API。 ...

据 AI Tool Tier 评测数据，Cognition 的 Devin Fusion 采用 lead/sidekick 双模型编排架构，实测每个编码任务的成本比单一大模型方案降低百分之二十三到四十六。这个架构跟传统的单 Agent 循环思路完全不同。 分工是这样的：lead 模型负责理解任务、拆解步骤、审查 sidekick 的输出；sidekick 模型负责实际写代码、跑测试、改文件。lead 用强模型但调用次数少，sidekick 用便宜快速的模型但承担大部分 token 消耗。两模型通过结构化消息通信，不是简单的提示词嵌套。 这种编排的经济学很直观：大模型贵但你不需要它全程参与——只需要在关键决策点用它。执行层面的重复劳动交给小模型。九月十五日 Cognition 跟 AWS 签了多年期协议，把这个架构跑在 AWS 基础设施上，说明成本优化已经到了可以规模化的阶段。 Devin Fusion 的双模型架构给整个编码 Agent 行业提供了一个新的思路。以前大家都在追求一个超大模型包打天下，Fusion 证明了用两个各司其职的模型组合起来，效果更好还更便宜。这个思路很可能会被其他编码 Agent 产品借鉴。 从成本结构上分析，lead 模型虽然单价高但调用次数少，sidekick 模型单价低但承担大部分 token。这种组合的总成本比全程用大模型低百分之二十到四十六，这个数字在规模化之后是非常可观的节省。对于每天处理成百上千个编码任务的团队，每省一块钱乘以任务量就是大钱。 为什么两个模型比一个大模型更省钱？ 这个思路其实跟人类团队的分工一样：架构师不用亲自写每一行代码，但要审查每个关键决策。初级工程师写大部分代码，但每个 PR 都要过架构师这关。Devin Fusion 把这个模式复制到了 AI Agent 里。 lead 和 sidekick 具体怎么分工？ 对自建编码 Agent 的团队来说，这个架构值得借鉴。你不一定需要用 Devin，但可以用同样的思路：用一个强模型做路由和审查，用便宜模型做执行。这种分层可以显著降低每次编码任务的边际成本。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Cline 项目 README，这个开源编码 Agent 的命令行工具提供四种运行模式。默认的 cline 或 cline -i 打开完整终端交互界面，带 plan/act 切换、斜杠命令、文件提及和实时工具审批——适合人在旁边盯着的交互式编码。 cline 直接加 prompt 参数则是一次性模式：跑一个回合就退出，适合脚本里调用。cline –json 模式以 NDJSON 格式流式输出事件，可以管道接进其他工具或 CI 系统——你可以自己解析事件流，在工具执行前加自定义审批逻辑。 最激进的是 cline –yolo 模式：跳过所有审批提示，让代理自主执行直到任务完成。这个模式威力巨大但风险也大——它会自己改文件、跑命令、装依赖。建议只在隔离的 Docker 容器或临时分支里用，千万别直接在主力开发机上开 Yolo。 Cline 作为开源编码 Agent，最大的优势是透明和可控。跟闭源的 Devin 或者 Claude Code 不同，你可以看到它的每一步操作、修改它的提示词、定制它的工具权限。这种可控性对于有安全合规要求的企业特别重要。 四种运行模式覆盖了从交互式开发到全自动化 CI 的完整场景。TUI 模式适合人在旁边盯着的探索性编码，one-shot 模式适合脚本里的简单任务，JSON 模式适合接入自研的审批流程，Yolo 模式适合在隔离环境里批量处理。选择哪个模式取决于你对自动化程度和风险承受力的平衡。 JSON 事件流模式怎么接入 CI 流水线？ JSON 事件流模式是接入 CI 的关键。你可以写一个脚本启动 cline –json，监听事件流，在代理要执行危险命令时插入人工审批或者自动拒绝。这样就实现了半自动化——代理做大部分工作，关键节点人来把关。 Yolo 模式到底有多危险？ Cline 作为开源项目，跟闭源的 Devin 和 Claude Code 相比，优势在于你可以完全掌控它的行为。所有提示词、工具列表、审批规则都可以自定义。对于有安全合规要求的企业，这种可控性是闭源工具给不了的。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Mastra 官网更新，十月一日平台新增了 VPC 隔离的托管 Postgres 数据库服务。这不是给普通 Web 应用用的——它是专门给 Mastra Agent 做状态存储的：会话历史、记忆条目、工作流中间状态、工具调用日志，全部持久化在这个 Postgres 里。 VPC 隔离意味着你的数据库跟 Mastra 平台其他用户的数据库在网络层面完全隔离，只能通过你自己的 VPC 连接。对企业用户来说这是合规要求——Agent 处理的数据不能跑在共享多租户环境里。 同期发布的 Server Adapters 则解决了部署痛点：以前你要单独起一个 Mastra 服务端口，现在它可以作为中间件挂在你已有的 Express 或 Hono 应用里。Agent、工作流、工具和 MCP 服务器自动暴露为 HTTP 端点，不需要额外的运维负担。 Agent 应用的状态管理一直是个被低估的难题。跟普通 Web 应用不同，Agent 的状态不是简单的用户数据——它包括对话历史、长期记忆、工作流检查点、工具调用审计。这些数据量很大，而且查询模式很特殊。专门为 Agent 设计的 Postgres 托管服务正在填补这个空白。 Server Adapters 的出现则意味着 Mastra 的部署模型更加灵活。你不再需要单独部署一个 Mastra 服务，而是可以把它作为中间件嵌入现有的 Node.js 应用。对于已经有 Express 或 Hono 后端的团队，这省去了维护额外服务的运维负担。 从产品演进的节奏来看，Mastra 几乎每个月都有重要功能发布，这种迭代速度在开源 Agent 框架里算是很快的。 Agent 为什么需要专用 Postgres？ Agent 应用的状态存储比普通 Web 应用复杂得多。你需要存多轮对话历史、长期记忆向量、工作流的检查点、工具调用的审计日志。用普通 Postgres 也能存，但 schema 设计和查询优化很费时间。Mastra 把这些都做好了。 ...

据 Simon Willison 博客，OpenAI 在最近的 DevDay 上发布了 Jev 风格的 Decisions API。跟普通聊天接口不同，Decisions API 专门处理结构化决策：给一个输入，模型返回是或否、多个选项中的一个、或者一个评分，每个选项附带概率。 Simon Willison 看到文档后，直接让 GPT-6 Astra 读了一遍 OpenAI 的新 API 文档，然后写了一个 llm-openai-decisions 插件。这个插件接入他已有的 llm-typesafe 插件体系，让终端用户可以直接用命令行调用 OpenAI 的决策端点。整个过程就是 AI 辅助写 AI 工具。 决策 API 的工程价值在于：你不需要在业务代码里写一堆解析逻辑来从自然语言输出中提取结构化结果。模型直接返回 schema 约束好的答案和置信度，下游系统拿到就能用。这比让模型输出 JSON 再做容错解析可靠得多。 Jev 风格的决策 API 代表了大模型应用化的一个重要方向：从通用聊天到专用判断。以前你想让 AI 做内容审核，得写一大堆提示词让模型输出 JSON，然后在业务代码里解析和容错。现在直接调决策接口，模型返回带概率的选项，下游系统直接用。 Simon Willison 用 GPT-6 Astra 自己读文档写插件这件事本身就很有象征意义——AI 辅助开发 AI 工具已经成为常态。这个插件从想法到发布只用了很短时间，放在以前是不可想象的。开发者的生产力正在被 AI 本身重塑。 决策 API 跟普通聊天补全有什么区别？ 典型应用场景包括：内容审核判定、用户意图分类、工单优先级评分、风险评估打分。这些场景的共同点是：输出空间有限、需要置信度、下游系统要自动处理。用普通聊天接口做这些事，你得写一堆 prompt 工程和 JSON 解析。 为什么说这是 AI 工程化的新方向？ 值得注意的是，Ollama 在九月底也宣布支持了 Jev 风格的决策模型——TypeSafe 的 Jev API 已经可以在本地跑。这意味着决策类工作流的本地部署路径也打通了，敏感数据不用出内网。 ...

据红帽官方博客，Red Hat AI 3.4 版本引入了搭载 ZenDNN 后端的 vLLM-CPU，专门为 AMD EPYC 处理器优化 LLM 推理性能。ZenDNN 提供经过调优的计算内核和原语，让 PyTorch 等框架在 AMD CPU 上高效运行。 ZenDNN 做的事情跟 Intel 的 oneDNN 类似：把矩阵乘法、注意力机制这些高频算子替换成针对 EPYC 微架构手工优化的汇编实现，充分利用 AVX-512 指令集和大内存带宽。对于 CPU 推理这种内存带宽受限的场景，内核优化带来的提升往往比算法改进更直接。 什么时候 CPU 推理比 GPU 划算？答案是：并发量不高、延迟要求不苛刻、但你已经有大批 EPYC 服务器在跑其他业务。把 LLM 推理作为附加负载跑在现有 CPU 集群上，边际成本接近零。红帽在 MLPerf v6.1 里的 CPU-only 提交证明了这条路的可行性。 AMD 在 CPU AI 推理这条路上投入了很多年。ZenDNN 就是他们针对这个场景打造的软件栈，跟 NVIDIA 在 GPU 上做的 CUDA 类似，只是战场从显卡转移到了服务器 CPU。随着企业级 AI 应用从云端 GPU 向边缘和存量 CPU 扩散，这个市场会越来越大。 从性价比角度看，用 EPYC CPU 跑小模型做推理，每路请求的成本确实比 GPU 低。但前提是你已经有这些 CPU 在跑其他业务——如果专门为了跑 LLM 去买 CPU 服务器，那就不如直接上 GPU 了。关键在于盘活存量资源。 ...

据 LLM Releases 变更日志，德国主权 AI 公司 Aleph Alpha 于十月三日发布了 Kolibri-1，一个 78B 参数的开源 MoE 模型，支持 1M token 上下文窗口，Apache 2.0 协议。权重在 Hugging Face 同时提供 FP8 旗舰版和 BF16 基础版。 主权 AI 的定位很重要：这不是又一个追 GPT 性能的模型，而是面向欧洲企业和公共部门的合规选择。数据不出欧盟、训练过程透明、许可证允许商用——这些在 GDPR 框架下是硬需求。德国政府一直在资助 Aleph Alpha 作为欧洲对抗美国模型依赖的战略棋子。 技术上它是 MoE 架构，78B 总参数但激活参数远小于此，推理成本比同等 dense 模型低。部署需要至少多卡服务器，不适合本地跑——但对企业来说，用它替换 GPT 做数据敏感的内部应用，合规风险低很多。 Kolibri-1 的发布在欧洲 AI 圈引起了不小的关注。这不是因为它的性能超越了 GPT 或者 Claude——它并没有。而是因为它代表了一种独立于美国科技巨头的技术路线。在数据主权和监管合规越来越重要的背景下，欧洲企业需要一个自己能掌控的大模型选择。 从技术规格看，78B 的 MoE 架构配 1M 上下文，说明 Aleph Alpha 走的是长文档处理和企业级知识库的路线。这个定位跟 Kolibri 这个名字很配——蜂鸟虽然小但飞得灵活，适合在企业内部的复杂文档网络中穿梭。 对于关注欧洲 AI 生态的观察者来说，Kolibri-1 的发布标志着主权 AI 不再只是口号，而是有了实际可用的产品级模型。后续可以持续关注它在企业场景中的落地案例。 主权 AI 模型跟普通开源模型差在哪？ FP8 版本和 BF16 版本的区别不只是精度。FP8 版本推理时显存占用小、吞吐高，但需要 Blackwell 或更新的 GPU。BF16 版本兼容性好但更吃显存。选哪个取决于你的硬件代际。 ...

据多家科技媒体十月初报道，Prime Intellect 正式推出 Prime Inference，一个专门服务开源前沿模型的推理平台。在公开发布之前，这个平台内部每天处理接近一万亿 token——流量来自 RL 训练 rollout、合成数据生成、模型评估和长期运行的编码 Agent。 平台提供两种模式：serverless 端点应对波动流量，按 token 计费；预留容量适合有稳定负载的生产场景，按月承诺。两种模式都跑在 Prime 自己跨多个数据中心的 GPU 集群上，接口兼容 OpenAI SDK。首发支持 GLM-5.3 等开源权重模型。 对开源模型开发者来说，Prime Inference 的价值在于：你不用自己买 GPU、搭 vLLM、调并发——注册就能拿到一个 OpenAI 兼容端点，先跑 serverless 验证需求，流量起来了再切预留容量降本。适合做产品原型和早期用户验证阶段。 Prime Inference 的出现，让开源模型的部署门槛又降低了一截。以前你要用 GLM 或者 Llama 系列模型做产品，要么自己租 GPU 搭 vLLM，要么找 Together 或 Fireworks 这样的托管平台。现在多了一个选择，而且背后是分布式 GPU 网络的成本结构，理论上价格可以更低。 对于初创团队来说，serverless 模式特别友好。你不需要预测未来一个月的流量，也不需要为了预留容量签长期合同。有请求就付费，没请求就不花钱。这种弹性对于产品验证阶段的现金流管理非常重要。 它跟 Together、Fireworks 这些推理平台有什么不同？ 跟 Together AI 和 Fireworks 相比，Prime Inference 的差异化在于它背靠 Prime Intellect 的分布式 GPU 网络——这个网络原本是为去中心化 AI 训练设计的，现在把闲置算力开放做推理服务。理论上成本可以比传统云厂商更低。 serverless 和预留容量怎么选？ 选型建议：如果你的应用流量波动大、不确定峰值在哪，先用 serverless。等运行一个月有了稳定流量基线，再切预留容量拿折扣。不要一开始就签长期预留合约——开源模型更新很快，你可能下个月就想换模型了。 ...

据 Red Hat 新兴技术团队十月六日博文，Red Hat AI Inference 3.5 的 CPU 部署指南完整公开。核心方案是：用 Podman 拉取红帽官方推理容器镜像，在纯 CPU 的 x86 服务器上启动 LLM 推理服务，然后通过标准 REST API 调用。 CPU 推理的定位很明确：开发测试、小规模部署、边缘场景。不要指望用 CPU 跑 70B 模型做高并发生产——那是 GPU 的活。但如果你是一个小团队，想在内网跑一个 7B 或 8B 模型做内部知识问答，CPU 方案能帮你省掉 GPU 采购和运维成本。 配套的 cpueval CLI 工具链可以自动化做性能基准：测吞吐量、测延迟、生成可复现的报告。红帽还开源了 vllm-cpu-perf-eval 框架，用 Ansible 和 GuideLLM 做标准化测试。在 MLPerf Inference v6.1 里，红帽跟 Intel 合作的 CPU-only 提交拿到了每核心 Llama-3.1-8B 最高吞吐量。 红帽推 CPU 推理方案的战略意图很清楚：企业已经买了大量 x86 服务器，现在 GPU 太贵、太缺，能在现有硬件上跑起来的 AI 应用就先跑起来。不需要一步到位上 GPU 集群，先在 CPU 上验证业务价值，等流量上来了再考虑硬件升级。 ...