产品开发哲学

本文档描述 Monkeys 开源生态的产品开发哲学。它不是路线图、部署指南或功能规格说明。

Monkeys 应该被开发成一套以数据为中心、AI 原生的产品系统。Studio、Kernel、Compute、Agent、工作流、工具和服务不应该各自变成孤岛，而应该围绕同一套数据模型、同一套业务语义和同一套产品契约协同工作。

核心思想

数据是 Monkeys 的第一性产品对象。

页面、工作流、工具和 Agent 是创建、转换、展示或操作数据的不同方式。它们是重要的用户体验和开发者体验，但不应该成为架构中最稳定的中心。真正稳定的中心是数据结构、语义模型、访问契约，以及围绕它们展开的执行模型。

Monkeys 的核心数据模型可以这样理解：

Global Data 不是每个界面都必须暴露给用户的业务标签。用户可以看到数据仓库、数据集、视图、工作区、任务和生成结果。系统内部通过 Global Data 保证事实数据统一、可治理、可查询，并能被不同产品界面和 Agent 复用。

任何功能开发都应该先回答数据问题：

页面只是数据的一种交互界面。工作流只是数据变化的一种执行路径。Agent 只是能够操作数据的一类行动主体。即使某个具体界面发生变化，产品整体仍然应该保持一致。

Monkeys 应该避免为单个客户、单个项目或单个页面硬编码业务规则。

业务变化应该优先通过 ontology 定义、视图配置、工作流配置、工具配置、工作区配置和其他声明式数据表达。代码负责提供稳定的运行时、协议、组件和扩展点。

这样才能保持产品对开源开发者友好：开发者可以通过增加数据、配置、工具和产品模块来扩展系统，而不是把场景专属逻辑分叉进核心代码。

Global Data 是组织级全量历史事实层，支撑跨 ontology、跨 view、跨应用、跨工作流、跨 Agent 的数据复用。

Global Data 应该让产品行为更加一致：

Global Data 应该保持清晰的系统职责。产品界面应该暴露适合用户理解的抽象，而不是把内部术语强行放到界面上。

Ontology 是 Monkeys 描述业务世界的方式，不应该只被理解成 bucket、表或存储细节。

不同行业、部门、工作流和设计阶段需要不同的业务对象。Ontology 把原始记录和字段组织成 Studio、Kernel、Compute、工具和 Agent 都能共同理解的对象。

没有 ontology，数据只是记录和字段。有了 ontology，数据才成为共享的业务语言。

Studio、Kernel 和 Compute 不是三个割裂产品，而是同一套数据中心架构上的三个界面。

三者应该共享产品概念和数据契约。如果某个能力已经存在于共享数据架构中，单个界面不应该再发明一套隐藏模型。

Agent 应该能够读取数据、写入数据、调用工具、触发工作流、生成交付物，并推动业务状态变化。

但 Agent 不应该绕过产品模型任意行动。Agent 的行为应该被 ontology、view、权限、工作流契约、工具契约和运行时策略约束。这样 Agent 的行为才可解释、可审计、可复用，也更适合严肃的生产场景。

目标不是让 Agent 变得神秘，而是让产品数据和产品动作足够结构化，使 Agent 能够安全地使用它们。

Monkeys 是开源生态。它应该作为面向团队和组织的完整产品系统服务全球开发者，同时也足够强大，能够支撑复杂企业场景。

这意味着：

产品不应该变成一堆一次性项目的合集。复杂企业场景应该增强开源架构，而不是把它撕开。

新增或修改产品行为时，优先遵循这些默认判断：

Monkeys 围绕组织级全量历史事实开发：Ontology 定义业务语义，Filter 和 View 定义访问与展示方式，Studio、Kernel、Compute 和 Agent 围绕同一套数据契约协同工作，让产品既保持开源、可组合，也足以支撑复杂企业工作。