模型
理解输入、推理，并选择下一步行动。
ARRIVAL / 博士旅程完成
进入新的问题 ↘博士毕业。问题继续。
读博这几年，研究、产品和创业一路并行。现在，AI 开始持续工作，我也把目光投向更宏观的产品方向。
2026 / AGENT RUNTIMEAI 开始持续工作。
AI 开始持续工作。
产品该怎样重做？
GPT-6 到来，长程自主 Agent 继续向前。AI 承担的任务越来越完整，许多原来分属不同岗位的工作开始连在一起。
我现在更关注平台产品：模型、Runtime 与业务应用怎样分工？开发者、企业和模型厂，又各自负责什么？
这一章从我在 写的《Anthropic vs Kimi 研究报告》第一、二部分展开。
先试一次产品判断 ↘YOUR TURN / 轮到你来划边界
如果由你来做
这个 Agent 平台？
三个场景，试试你的选择。
看看分工怎样变化，再对照我的产品判断。
PRODUCT DECISION LAB / 20260 / 3 处边界已探索
01 / 从竞品路径看产品分工
模型之上，
Runtime 正成为产品。
模型能力进入完整任务，需要有人承担持续运行的工程。
我沿着工具与 Runtime 的托管程度，比较产品路径。
Agent 运行时
组织工具、状态与执行环境，让任务持续运行。
业务应用
定义具体目标、用户体验与业务流程。
提供模型调用
平台提供模型能力，开发者接入工具并组织执行。
托管部分工具
平台执行部分云端工具，业务工具与整体流程按产品分工。
开放运行能力
开发者在自己的环境运行 Agent，负责部署与运维。
托管 Runtime
平台运营 Agent 运行时，向客户提供任务与运行环境等能力。
这是文中比较产品责任的四条路径；同一产品可以提供多种能力。
02 / 三组宏观产品判断
Runtime 做成标品，
要想清楚什么？
切换三组判断，查看这篇研究的八个要点。
从产品价值，看到模型演进与企业落地。
先把共性工程，变成客户愿意用的产品。
文中从产品价值、早期用户和工程基础，判断 Hosted Agent 应该从哪里开始。
替客户承担共性工程
Session、工具执行、状态保存与失败恢复都需要工程投入。平台把这些能力做成标品，客户就能减少重复建设。
先服务已自建 Agent 的开发者
文中首先关注已基于 Kimi 自建 Agent、并验证模型对任务有效的开发者。他们接着需要稳定执行、保存状态、恢复失败与监控任务。
从 SDK 走向平台托管
SDK / Server API 开放第一方 Agent 的运行能力，由开发者运营。Hosted Agent 再将部署与持续运行交给平台。
03 / 我想继续理清的边界
三条边界，
决定产品怎么做。
模型与 Runtime
模型承担更多判断，Runtime 保障状态、权限与执行。
标准产品与企业定制
平台提供共性能力，客户与生态完成业务接入。
一次请求与完整任务
围绕 Session 管理过程，用任务结果衡量价值。
当 AI 持续推进跨岗位的任务，平台怎样定义产品，企业怎样组织工作，人怎样重新分工？
这是我现在想继续研究和验证的方向。
继续读这篇研究
/ 本页为第一、二部分导读Anthropic vs Kimi
研究报告
从四条产品路径，到八个宏观判断，再看 Hosted Agent 应该承担哪些责任。具体竞品状态与详细设计，见当时的研究原文。
打开完整原文 ↗浏览全部随笔 ↗