做 Agent 产品，先做平台还是先做具体场景？

我们团队正在做 ZGI ，一个开源的 Agent Runtime 项目，主要关注 Agent 调用知识和工具、执行工作流、处理权限与状态这些运行环节。

项目即将进入更大范围的市场验证阶段。准备对外内容时，我开始思考一个很现实的问题：做 Agent 产品，应该先把通用平台讲清楚，还是先从一个具体业务场景切进去？

过去的 SaaS 产品通常按照账号、功能和席位收费。用户登录系统，学习操作，再利用软件完成工作。

Agent 带来的产品形态有些不同。用户给出目标，系统负责查找知识、选择工具、执行步骤，最后交付结果。界面可能越来越轻，背后的运行过程却越来越复杂。

这种变化会直接影响 Agent 创业团队的选择。

做垂直 Agent ，早期更容易说明价值。合同审查、客服回复、数据分析、销售线索整理，都有明确任务和结果，也方便找到愿意付费的客户。

但 Agent 一旦进入实际业务，团队很快会碰到一批共性问题：

它可以读取哪些资料？

能以谁的身份调用工具？

任务中断后从哪里继续？

高风险操作由谁批准？

出现错误时能否找到完整过程？

模型更换后，业务流程是否需要重做？

这些问题看起来偏技术，最后都会落到产品体验和交付成本上。权限模糊，客户不敢开放数据；过程无法追踪，出了问题很难解释；每接一个客户都重新开发，团队会逐渐变成项目外包。

因此，我感觉 Agent 创业可能会逐渐分成两类。

一类深入具体行业，把业务知识、流程和交付结果做深。另一类建设更底层的运行能力，为不同 Agent 提供知识、工具、权限、工作流、状态和运行记录。

两条路都有机会，也都不轻松。垂直产品需要理解行业，基础设施需要面对更长的验证周期。创业团队很难在早期同时做好两边，产品边界会成为一个很现实的选择。

我们做 ZGI 时，选择了 Agent Runtime 这个方向，希望把 Agent 执行任务时反复遇到的共性能力整理出来。目前项目已经开源：

我现在比较好奇的是，未来企业会继续为“软件使用权”付费，还是会越来越愿意按照 Agent 完成的任务和结果付费？

这个变化一旦发生，Agent 产品的设计、定价和交付方式可能都会跟着改变。