{"data":{"project":{"slug":"project-sinceforge-os","title":"SinceForge OS：把目标，变成系统","summary":"一套本地优先的企业 AI 工作操作系统，把对话、文件、知识、数据、任务、自动化和 AI 应用放进同一个可持续工作的环境中。","industry":"AI 工作操作系统与企业生产力","industry_group":"企业与专业服务","kind":"产品项目","url":"https://deepevolutions.com/cases/project-sinceforge-os","api_url":"https://deepevolutions.com/api/v1/public/projects/project-sinceforge-os","source":"static_editorial_archive","verification_status":"not_independently_verified","source_url":"https://www.deepevolutions.com/cases/project-sinceforge-os","source_retrieved_at":"2026-08-30","disclaimer":"本案例展示 SinceForge OS 自研产品已经形成的核心 Forge App 平台、受治理执行路径，以及 2026 年 7 月完成的代表性本地环境与合同验收成果。","body_markdown":"# SinceForge OS：把目标，变成系统\n\nAI 工作操作系统与企业生产力\n\n一套本地优先的企业 AI 工作操作系统，把对话、文件、知识、数据、任务、自动化和 AI 应用放进同一个可持续工作的环境中。\n\n## 项目进程\n\n项目没有从一张理想架构图开始重写，而是先沿真实运行路径盘点：目标怎样进入系统，上下文怎样组装，模型怎样调用工具，复杂任务怎样运行，成果怎样保存，反馈又怎样回到下一次工作。盘点之后，团队冻结了一组核心边界——Vora 是智能入口而不是整个 OS；通用能力归 OS，Forge App 只负责界面、场景和薄适配；迁移必须保留历史数据、文件标识与兼容入口。\n\n“做一个 AI OS”随后被拆成一条可以逐项验收的最小竖切：任务创建、入队执行、状态与事件记录、Task Center 投影，以及 Runtime Ops 的健康与积压视图。在这条主干跑通后，再逐步补齐 Capability Gateway、Permission、Data Space、Content Object、Sandbox 与 Native Host，并用 Knowledge、Vora、Forge Studio 和 Enterprise Data Center 做代表性验证。\n\n## 背景与痛点\n\n多数聊天式 AI 解决的是一次回答。文件仍在文件夹里，知识、任务和最终成果分散在不同工具中；遇到需要多步骤执行、人工确认、失败恢复或持续编辑的工作，聊天记录很难成为可以继续推进的正式上下文。\n\nSinceForge 早期已经积累了多个 AI、知识、数据、本地执行和自动化产品，但模型调用、存储、身份、权限、任务状态与运行逻辑也因此出现多套入口。与此同时，本地资料与云端账号、同步、授权和应用分发之间缺少统一路由。真正要解决的不是再增加几个 AI 功能，而是让所有应用共享一套可治理、可追踪、可扩展的工作底座。\n\n## 解决方案\n\nSinceForge OS 先用统一启动器、窗口、Dock、设置与通知组织不同 Forge App。用户可以从 Vora 说出目标，简单问题保持即时回应；需要多步骤、持续运行或人工确认的工作，再升级为由 OS 管理的任务。Knowledge 和数据库提供受控上下文，Paper、Tables、Story 与 Reader 则承接可以继续编辑的正式成果。\n\n在受治理路径中，模型、工具、数据库、本地运行时和外部连接统一经过 Capability Gateway、权限与审批，再进入 Task Runtime、Forge Native Host 或 Sandbox。Task Center 集中投影运行、待审批、阻塞、失败、完成、步骤进度与成果，让复杂工作可以被观察、取消、恢复和复盘。\n\n当一条方法跑通后，Forge Studio 再把它沉淀为 Agent、Prompt、业务语义、Forge App、Skill 或 Tool，并进入各自的版本、测试、审查与复用流程。本地优先也被落实为运行策略：数据和能力可以留在本机或私有环境，但账号、同步、授权与分发仍保留受控云端边界，而不是被笼统宣传为完全离线。\n\n### AI 技术\n\nFORGE_APP_RUNTIME / CAPABILITY_GATEWAY / TASK_RUNTIME / LOCAL_FIRST_EXECUTION / CONTENT_OBJECT\n\n### 工作流、管道与 Agent\n\nVora 智能入口 / Forge App Manifest / Capability Gateway 与权限审批 / Task Runtime 与 Task Center / Native Host 与 Sandbox / Artifact 与 Content Object\n\n在标准受治理路径中，系统根据用户、应用、工作区、风险和数据边界决定能力在本机、私有环境或远端执行；历史兼容路径沿统一 OS 模型持续收敛。\n\n## 从统一桌面，到受治理执行与能力复用\n\n### 让复杂工作拥有状态与证据\n\n![SinceForge OS Task Center 展示本机运行状态、任务步骤和受治理能力调用](/images/cases/sinceforge-os/02-task-center-governed-execution.jpg)\n\n本地示例中的 Task Center 集中呈现任务状态、步骤进度、能力调用和 Forge Native Host 环境。画面证明的是状态模型与受治理执行路径，不代表繁忙的生产负载。\n\n### 把会做一次，沉淀成可复用能力\n\n![Forge Studio 展示 Agent、Prompt、Semantic、Apps 与 Tool 五类构建入口](/images/cases/sinceforge-os/03-forge-studio-capability-builders.jpg)\n\nForge Studio 为 Agent、Prompt、Semantic、Forge App 与 Tool 提供独立构建入口。界面证明的是产品结构与资产路径，不代表已经发布大量生产级 Agent 或数字员工。\n\n## 效果反馈\n\n多应用体系已经开始收敛到统一 SinceForge OS 桌面与 Forge App 运行模型：注册表中的 26 个入口由 22 个当前主要入口和 4 个历史兼容入口组成，Vora 逐步转为受 OS 能力支持的智能入口与薄 Shell，旧文件标识、数据和兼容路由则在迁移中被保留。\n\n在 2026 年 7 月的本地环境与合同验收基线上，41 / 41 项代表性 Runtime 与应用 Smoke、Knowledge 真实 Docker Smoke 1 / 1、795 / 795 项合同回归均通过；当时的 371 / 371 项能力合同清单仅通过合同字段与静态质量门，不等同于 371 项能力均已完成真实环境或生产交付验收。\n\n这些结果证明了核心 Forge App 平台、统一运行合同和代表性本地路径已经形成，但不代表所有 Runtime Pack 或企业生产 Authority 已完成。当前也没有可公开引用的客户评价、ROI 或业务效率提升百分比，因此案例不把内部工程验收外推为客户经营成果。\n\n本案例展示 SinceForge OS 自研产品已经形成的核心 Forge App 平台、受治理执行路径，以及 2026 年 7 月完成的代表性本地环境与合同验收成果。\n\n## 资料范围\n\n本文是网站公开的静态编辑资料，不等于已独立核验的客户成果或客户背书。请结合项目说明与原始来源判断。\n\n原始来源：https://www.deepevolutions.com/cases/project-sinceforge-os\n\n来源读取日期：2026-08-30","content_sha256":"9abd4c55dc8dc986ed8eda483f9e079d79c0673034f71655b403f920a1c764ef","capability_codes":["FORGE_APP_RUNTIME","CAPABILITY_GATEWAY","TASK_RUNTIME","LOCAL_FIRST_EXECUTION","CONTENT_OBJECT"],"deployment_mode":"HYBRID"}},"meta":{"request_id":"ff63cda8-24b5-4c89-b551-ff853d47848a","timestamp":"2026-09-29T12:52:02.053Z"}}