企业为什么需要这样的系统
让分散的软件、数据和 AI，在同一套业务体系中工作。
公司刚起步，几张表格就能开展业务。客户和员工增加后，逐渐引入销售、订单、财务和售后软件。每套软件解决一个问题，也带来不同的数据、账号和操作方式。销售承诺的交期，安装人员可能要去群里问；售后处理问题，又要重新查找客户和设备资料。
数据孤岛也限制了 AI：它只能看到局部信息，不知道哪份记录为准，缺少跨业务执行和回写结果的入口。为让各处的 AI 工作，团队继续复制资料、建立知识库、增加脚本和机器人，又产生新的数据副本与维护任务。
数据孤岛带来智能孤岛，智能孤岛反过来加剧数据孤岛。 缺少共同的组织和协作机制时，软件投入不断增加，人工核对、交接和维护的成本也随之累积，成为企业的长期顽疾。
kageos 希望把业务应用、数据和操作放进一个共同的体系，让人和 AI 能找到工作、完成操作，并让后续同事从同一份记录继续接手。
一套业务应用，就是一个服务目录
把可用的业务应用，积累成企业自己的软件资产。
“服务目录”可以理解为一套能在网页上直接使用的业务应用。例如，一个售后目录可以包含设备台账、报修表单、工单操作、处理说明和自动任务。打开目录，用户就能找到办理这项业务所需的资料和入口。
kageos 把这些目录作为企业可以持续维护的软件资产来管理：
| 管理方式 | 对企业的意义 |
|---|---|
| 搜索与查找 | 按名称和业务关键词找到已有应用，减少到处找入口或重复建设 |
| 按职责授权 | 决定谁能访问目录、使用哪些操作，AI 也在获准范围内工作 |
| 复制与调整 | 复用已经成熟的应用，再按新团队的规则修改 |
| 持续维护 | 应用、说明和任务随业务更新，已有成果继续使用 |
公司可以先有一个客户目录，再逐步增加订单、交付和售后。新业务继续沿用平台的界面、权限和操作机制，并与已有目录建立关联。从使用者眼里看，业务增长体现为目录树上增加新的应用。
↗ 放大查看员工打开页面，就能办理业务
员工用熟悉的界面操作，每一次提交都有业务结果。
日常使用以页面操作为主。用户填写表单、查询表格、执行操作、查看图表；不同应用沿用共同的界面和交互习惯。例如学会在一个目录中查找记录、填写信息后，进入其他目录仍能用熟悉的方式办事。
下图是收银结账：选择商品和会员，提交后，页面返回订单号、支付结果和金额信息。
↗ 放大查看▶ 看实际操作：切换业务目录，查询记录与提交表单 · 50 秒
收银只是其中一个场景。同样的操作方式也可以用于客户登记、设备报修、会议室预约、活动报名、物品领用和问卷提交。各应用保留自己的字段和处理规则，用户通过统一的方式提交信息并查看结果。
背后的“函数”负责办理具体业务。可以把它理解成一个明确的动作：查询订单、记录跟进、预约房间或检查网站。函数接收所需信息，按规则执行，并返回结果；需要保存的记录由应用写入。页面和 AI 都可以调用这些业务能力。
多个目录协作，完成一件工作
从查询到执行，再到结果保存，让工作接得起来。
企业的工作经常跨越多个应用。招聘确定了面试时间，还需要行政安排房间。kageos 可以让 AI 在一次任务中读取招聘目录的安排，再查询会议室目录、调用预约能力，并汇总处理结果。
↗ 放大查看▶ 看实际操作：AI 读取访客预约，安排会议室 · 38 秒
这类协作建立在各目录已有的能力上：招聘负责面试信息，会议室负责房间和预约规则。AI 根据任务组合这些能力，用户可以回到相应页面查看和继续处理。
客户、订单、设备和售后也可以采用这个方式。具体关联、访问权限和业务动作需要配置或开发；把几个目录放在一起，并不会自动接通所有数据。
AI Native：AI 能理解业务结构，也能参与工作
人和 AI 使用共同的业务基础，按职责和权限各司其职。
对 AI 来说，业务目录是一张可查阅、可操作的企业业务地图。 它可以发现有哪些业务，阅读说明理解规则，查询记录了解当前状态，再调用获准的动作处理任务，把结果写回业务记录。
例如处理设备售后，可以先找到客户与订单，再查询关联设备和历史工单，最后调用已有的处理动作。AI 按任务逐步展开相关业务，了解范围由权限和已接入的数据、规则及关联决定。
这套应用从建设时就为人和 AI 提供共同的业务基础。人通过页面操作，AI 通过明确接口调用；两者都要遵守相应规则，结果留在业务系统里，可以互相接续。
| 使用方式 | 适合的工作 |
|---|---|
| 员工直接操作 | 提交事实、办理业务、确认需要人决定的事项 |
| AI 工作台 | 临时交办查询、分析或跨目录任务，查看结果后继续补充要求 |
| 数字员工 | 按职责和计划持续处理任务，保存结果，按配置通知或交接异常 |
| 定时函数 | 按固定规则执行巡检、检查等动作，无需每次经过模型判断 |
网站监控就是固定任务的例子。企业登记目标后，任务按计划检查并记录结果。负责人查看看板和趋势，在出现异常时回查具体记录。
↗ 放大查看
↗ 放大查看从需求到应用，再到复用
安装现成应用，或从需求出发建设，再持续改进。
企业可以先在 Hub 查找现成目录，安装后按自己的业务配置。没有合适的应用，或者需要改规则时，再由 AI 和必要的开发人员协助建设。
例如，一家小公司提出需求：
每个客户有负责人和下次联系时间。销售记录沟通结果，主管查看整体进度，每天整理需要跟进的客户。
围绕这项需求，可以建设客户台账、跟进表单、查询与更新动作、使用说明，再配置每日简报任务。AI 可以协助生成代码、页面定义和业务逻辑，检查构建问题，并调用操作验证结果。这个例子说明建设过程，实际交付仍需试用验收。
生成后的成果是可以打开、提交数据、持续使用和修改的业务应用。 代码与相关文件保存在工作空间中。以后新增客户阶段、调整跟进规则，可以在原应用上继续修改，并检查已有数据和常用操作是否正常。
▶ 看实际操作：用自然语言创建任务管理应用 · 1 分 14 秒
↗ 放大查看▶ 看实际操作：从 Hub 安装会议室管理应用 · 30 秒
成熟的目录可以复制、调整，也可以打包给其他工作空间复用，或按需提交 Hub。复制能力时，应确认业务数据、权限和外部账号的处理范围；公开分享并非企业内部使用的前提。
▶ 看实际操作：导出目录，带到另一个工作空间复用 · 28 秒
整个过程是：提出需求 → 安装或生成 → 配置验证 → 日常使用 → 持续调整 → 复用成熟能力。 Hub 提供起点，AI 帮助建设，业务目录承载运行，使用中积累的数据和经验再用于改进应用。
从一家小公司的第一项工作开始
先跑通一件真实工作，再逐步扩展公司的业务体系。
一家设备服务公司，可以先把客户跟进做好：记录谁负责、谈到哪里、何时再联系。员工能实际录入、更新和交接后，再增加订单与交付目录，把销售承诺交给安装人员；之后接上设备与售后，让维修人员查到对应客户和历史记录。
规则稳定后，再安排定时任务和数字员工处理重复工作。每一步都留下可继续使用的应用、数据与说明，新业务从已有成果上扩展，逐渐形成公司的业务服务资产库。
kageos 适合愿意按自身业务逐步建设和调整系统的团队。落地时仍要安排业务负责人确认规则、组织试用，技术维护者负责部署、备份、更新和故障处理。生成结果需要验证，连接已有财务或 ERP 系统需要具体接口，数字员工的异常也需要有人接手。
平台源码公开，支持自托管，具体授权以项目许可证为准。企业可以从一件真实工作开始，判断它是否减少了重复录入、人工交接和遗漏，再决定下一步扩展。