平台对比很容易变成无法验证的功能清单。更可靠的方法是：用同一业务流程、同一数据边界和同一验收标准完成实测，再比较结果、运营成本与所有权。
先确定购买对象
| 目标 | 更应关注 |
|---|---|
| 个人问答与轻量自动化 | 安装速度、日常入口、模型选择和本机权限 |
| 团队任务交付 | 结果一致性、共享上下文、失败处理和用量 |
| 企业系统集成 | API、MCP、Connector、身份、写回边界 |
| 组织级 Agent 平台 | 部署、治理、可观测、运营责任和扩展成本 |
| 持续运行的 AI 应用 | 安装、升级、持久数据、隔离和分发生命周期 |
先确认要购买的是助手、开发框架、集成层还是组织操作层。它们可以组合，但不能用同一张“功能数量”表替代选型。
统一验证矩阵
业务结果
- 能否从真实输入完成约定交付物，而不只给出建议；
- 完成周期、人工修改量、错误率和返工是否改善；
- 多名用户能否在固定条件下重复得到可接受结果；
- 失败时是否可以定位原因并由人工接管。
数据与集成
- 是否支持现有系统需要的 REST、MCP、Connector 或 SDK 路径；
- 数据在客户端、平台、模型服务和第三方工具之间如何流动；
- 是否能把读取与修改权限分开，并从只读试点开始；
- 凭证由谁保存、轮换和撤销。
运行与治理
- Run 是否有明确生命周期、取消、重连和事件记录；
- 模型、用户、接入应用和用量能否被管理；
- 沙箱具体使用什么后端，目标操作系统是否具有相同隔离强度；
- “审计”覆盖哪些事件，是否还需要外部系统日志；
- 单节点与多实例拓扑分别有哪些限制。
部署与所有权
- 支持本机、托管和客户环境中的哪些实际拓扑；
- 数据库、文件、备份、升级和恢复由谁负责；
- 能否更换模型、连接器和部署方式；
- Skills、应用、配置和运行数据能否导出与迁移；
- 许可是否允许计划中的生产或托管方式。
Fellow 当前适配范围
Fellow 更适合需要以下组合的场景：
- 在 Desktop 本机验证任务，再迁移到 Server；
- 通过 Agents 运行任务并保存工作区成果；
- 使用 Connectors、MCP 或 Client SDK 接入现有系统；
- 通过 AI Gateway 统一 Run、模型和事件流；
- 使用 Console 管理实例、用户、模型、接入应用和用量；
- 将稳定流程固化为 Skills 或当前 HTTP Runtime 子集下的 Applications。
当前实现也有明确边界：
- 默认 Cloud Docker 镜像是单节点路径，不应直接推断为多副本架构；
- Agent 工具使用 OS 沙箱，Server 的 Sandbox 由 Profile 决定；
- 运行记录不是覆盖所有外部系统操作的统一合规审计；
- HARP Host 尚未完整实现规范中的所有权限和 API。
建议 POC 方法
- 选择一个高频、只读为主、有明确验收人的流程。
- 准备固定输入、人工基线、敏感数据规则和预期交付格式。
- 让候选平台在相同模型或可比模型条件下重复运行。
- 记录结果质量、人工干预、运行成本、失败恢复和配置工作量。
- 再加入身份、权限、一个真实数据源和目标部署环境。
- 由业务、信息化、安全和运维共同做 Go / No-Go，而不是只看演示。