kageos-system-introduction-v5.md
Rama main · réplica de lectura del repositorio original.
# kageos：像管理文件一样，管理公司的业务
kageos 帮助企业搭建和运行自己的业务系统。客户管理、收银、招聘、售后等应用，都可以像文件夹一样组织在一起。员工打开就能办理业务，AI 也能按权限查询和操作。企业可以安装现成应用，或借助 AI 生成和修改，再让不同应用协同工作。
## 1. 企业为什么需要这样的系统
公司刚起步，几张表格就能开展业务。客户和员工增加后，逐渐引入销售、订单、财务和售后软件。每套软件解决一个问题，也带来不同的数据、账号和操作方式。销售承诺的交期，安装人员可能要去群里问；售后处理问题，又要重新查找客户和设备资料。
数据孤岛也限制了 AI：它只能看到局部信息，不知道哪份记录为准，缺少跨业务执行和回写结果的入口。为让各处的 AI 工作，团队继续复制资料、建立知识库、增加脚本和机器人，又产生新的数据副本与维护任务。
**数据孤岛带来智能孤岛，智能孤岛反过来加剧数据孤岛。** 缺少共同的组织和协作机制时，软件投入不断增加，人工核对、交接和维护的成本也随之累积，成为企业的长期顽疾。
kageos 希望把业务应用、数据和操作放进一个共同的体系，让人和 AI 能找到工作、完成操作，并让后续同事从同一份记录继续接手。
## 2. 一套业务应用，就是一个服务目录
“服务目录”可以理解为一套能在网页上直接使用的业务应用。例如，一个售后目录可以包含设备台账、报修表单、工单操作、处理说明和自动任务。打开目录，用户就能找到办理这项业务所需的资料和入口。
kageos 把这些目录作为企业可以持续维护的软件资产来管理：
| 管理方式 | 对企业的意义 |
| --- | --- |
| 搜索与查找 | 按名称和业务关键词找到已有应用，减少到处找入口或重复建设 |
| 按职责授权 | 决定谁能访问目录、使用哪些操作，AI 也在获准范围内工作 |
| 复制与调整 | 复用已经成熟的应用，再按新团队的规则修改 |
| 持续维护 | 应用、说明和任务随业务更新，已有成果继续使用 |
公司可以先有一个客户目录，再逐步增加订单、交付和售后。新业务继续沿用平台的界面、权限和操作机制，并与已有目录建立关联。从使用者眼里看，业务增长体现为目录树上增加新的应用。
*左侧组织不同业务，右侧展示所选目录的资源和运行情况。*
## 3. 员工打开页面，就能办理业务
日常使用以页面操作为主。用户填写表单、查询表格、执行操作、查看图表；不同应用沿用共同的界面和交互习惯。例如学会在一个目录中查找记录、填写信息后，进入其他目录仍能用熟悉的方式办事。
下图是收银结账：选择商品和会员，提交后，页面返回订单号、支付结果和金额信息。
*截图展示表单内容、提交入口及应用返回的结果。*
收银只是其中一个场景。同样的操作方式也可以用于客户登记、设备报修、会议室预约、活动报名、物品领用和问卷提交。各应用保留自己的字段和处理规则，用户通过统一的方式提交信息并查看结果。
背后的“函数”负责办理具体业务。可以把它理解成一个明确的动作：查询订单、记录跟进、预约房间或检查网站。函数接收所需信息，按规则执行，并返回结果；需要保存的记录由应用写入。页面和 AI 都可以调用这些业务能力。
## 4. 多个目录协作，完成一件工作
企业的工作经常跨越多个应用。招聘确定了面试时间，还需要行政安排房间。kageos 可以让 AI 在一次任务中读取招聘目录的安排，再查询会议室目录、调用预约能力，并汇总处理结果。
*这次会话列出当天 4 场面试，跳过已过去的场次，返回下午 3 场的会议室与预约编号。*
这类协作建立在各目录已有的能力上：招聘负责面试信息，会议室负责房间和预约规则。AI 根据任务组合这些能力，用户可以回到相应页面查看和继续处理。
客户、订单、设备和售后也可以采用这个方式。具体关联、访问权限和业务动作需要配置或开发；把几个目录放在一起，并不会自动接通所有数据。
## 5. AI Native：AI 能理解业务结构，也能参与工作
**对 AI 来说，业务目录是一张可查阅、可操作的企业业务地图。** 它可以发现有哪些业务，阅读说明理解规则，查询记录了解当前状态，再调用获准的动作处理任务，把结果写回业务记录。
例如处理设备售后，可以先找到客户与订单，再查询关联设备和历史工单，最后调用已有的处理动作。AI 按任务逐步展开相关业务，了解范围由权限和已接入的数据、规则及关联决定。
这套应用从建设时就为人和 AI 提供共同的业务基础。人通过页面操作，AI 通过明确接口调用；两者都要遵守相应规则，结果留在业务系统里，可以互相接续。
| 使用方式 | 适合的工作 |
| --- | --- |
| 员工直接操作 | 提交事实、办理业务、确认需要人决定的事项 |
| AI 工作台 | 临时交办查询、分析或跨目录任务，查看结果后继续补充要求 |
| 数字员工 | 按职责和计划持续处理任务，保存结果，按配置通知或交接异常 |
| 定时函数 | 按固定规则执行巡检、检查等动作，无需每次经过模型判断 |
网站监控就是固定任务的例子。企业登记目标后，任务按计划检查并记录结果。负责人查看看板和趋势，在出现异常时回查具体记录。
*按网站汇总检查次数、成功率、响应耗时和最近状态。*
*不同目标的耗时变化，帮助负责人找到需要进一步检查的时段。*
## 6. 从需求到应用，再到复用
企业可以先在 Hub 查找现成目录，安装后按自己的业务配置。没有合适的应用，或者需要改规则时，再由 AI 和必要的开发人员协助建设。
例如，一家小公司提出需求：
> 每个客户有负责人和下次联系时间。销售记录沟通结果，主管查看整体进度，每天整理需要跟进的客户。
围绕这项需求，可以建设客户台账、跟进表单、查询与更新动作、使用说明，再配置每日简报任务。AI 可以协助生成代码、页面定义和业务逻辑，检查构建问题，并调用操作验证结果。这个例子说明建设过程，实际交付仍需试用验收。
**生成后的成果是可以打开、提交数据、持续使用和修改的业务应用。** 代码与相关文件保存在工作空间中。以后新增客户阶段、调整跟进规则，可以在原应用上继续修改，并检查已有数据和常用操作是否正常。
*Hub 将应用用途、界面、版本和能力清单放在一起，方便选择。*
用成熟的目录可以复制、调整，也可以打包给其他工作空间复用，或按需提交 Hub。复制能力时，应确认业务数据、权限和外部账号的处理范围；公开分享并非企业内部使用的前提。
整个过程是：**提出需求 → 安装或生成 → 配置验证 → 日常使用 → 持续调整 → 复用成熟能力。** Hub 提供起点，AI 帮助建设，业务目录承载运行，使用中积累的数据和经验再用于改进应用。
## 7. 从一家小公司的第一项工作开始
一家设备服务公司，可以先把客户跟进做好：记录谁负责、谈到哪里、何时再联系。员工能实际录入、更新和交接后，再增加订单与交付目录，把销售承诺交给安装人员；之后接上设备与售后，让维修人员查到对应客户和历史记录。
规则稳定后，再安排定时任务和数字员工处理重复工作。每一步都留下可继续使用的应用、数据与说明，新业务从已有成果上扩展，逐渐形成公司的业务服务资产库。
kageos 适合愿意按自身业务逐步建设和调整系统的团队。落地时仍要安排业务负责人确认规则、组织试用，技术维护者负责部署、备份、更新和故障处理。生成结果需要验证，连接已有财务或 ERP 系统需要具体接口，数字员工的异常也需要有人接手。
平台源码公开，支持自托管，具体授权以项目许可证为准。企业可以从一件真实工作开始，判断它是否减少了重复录入、人工交接和遗漏，再决定下一步扩展。
---
## 内部附录：实施、验收与材料依据
正文用于产品介绍，以下保留内部实施细节与待验证事项。官网更新时取正文，并保留配图必要的事实说明。
### A. 建设与验收示例
假设一家设备服务公司刚起步。销售谈完客户后，要把承诺的交期交给安装人员；售后接到维修请求时，需要知道客户买了哪台设备。这家公司可以先把客户跟进做好，再接上后面的工作。
#### 第一步：选择最值得先解决的问题
先做客户跟进：统一客户记录，指定负责人，保留每次沟通，安排下一次联系。业务负责人提供实际做法，例如客户分哪些阶段、哪些人能看、什么情况下需要提醒。
第一项应用范围可以很小，但应覆盖一次完整工作：新客户录入后，有人接手，后续能查询、更新和交接。
#### 第二步：安装现成能力，或按自己的需求生成
先在 Hub 查看有没有合适的目录。有合适的就安装、配置；没有合适的，或需要改变规则，就在工作台描述需求，由 AI 和必要的开发人员协助建设。
企业可以这样提出要求：
> 我们有三名销售，每个客户有负责人和下次联系时间。销售保存沟通结果，主管查看整体进度。每天早上整理需要跟进的客户，并保留原始记录供查看。
先确认字段和规则，再生成或修改应用。能够运行后，用几条业务例子检查结果，最后配置员工权限和任务计划。
生成后仍然要验证。例如记录是否保存正确，同事能否接手，提醒是否重复，普通员工能否看到不该看的内容。企业负责人判断业务是否合适，开发或实施人员处理复杂规则和集成。
具体到这项客户跟进需求，一次建设过程应当让企业看到下面这些成果。这是过程示例，尚未附上对应的生成实录。
| 过程 | 企业可以看到和检查的内容 |
| --- | --- |
| 说清需求 | 客户有哪些字段，谁能查看和修改，什么情况需要提醒 |
| 生成应用 | 客户台账、记录跟进的表单、查询动作及使用说明；每日简报另行配置任务 |
| 实际试用 | 录入一位测试客户，保存沟通记录，再从台账中查到刚才的内容 |
| 检查协作 | 销售能处理自己的客户，主管能查看所需范围，交接后负责人信息正确 |
| 修改规则 | 比如增加“暂缓跟进”阶段，并让每日简报排除这类客户，再检查旧记录仍能正常使用 |
企业验收时，应拿到可以打开的应用、能够回查的业务记录和必要的使用说明。日后提出新需求，AI 和开发人员可以在已有代码与文件上继续修改；业务负责人仍要确认修改后的行为符合实际做法。
#### 第三步：连接客户之后的工作
客户跟进用顺之后，再连接订单、交付和售后：
| 建设顺序 | 希望形成的结果 |
| --- | --- |
| 客户与销售 | 谁在跟、谈到哪里、下一步何时做，都有记录 |
| 订单与交付 | 销售承诺能交给交付人员，延期和异常有人处理 |
| 设备与售后 | 设备能关联客户与订单，维修过程可以追踪 |
| 经营简报 | 老板集中了解待推进客户、延期订单和未结工单 |
这些关联需要按企业情况配置或开发，尤其要明确客户和订单如何识别、数据由谁维护、哪个动作推进业务状态。多个目录放在同一工作空间，并不会自动完成业务整合。
公司扩大后，第一张客户表可以继续使用。新增合同、安装任务和维修记录时，围绕已有客户建立关联，再补充新的岗位权限和操作入口。企业可以按业务进展逐步建设；是否需要调整已有数据结构，则取决于新需求。
#### 第四步：把用顺的应用复用到其他地方
做好的应用可以继续修改，也可以整理打包，在其他工作空间复用。适合对外分享时，再准备说明与展示，提交 Hub 审核。其他团队获取之后，用自己的数据和规则继续运行。
企业内部使用和公开投稿是两种选择，使用 kageos 不要求公开企业的业务成果。
### B. 日常运行与数字员工配置
系统配置好之后，销售每天打开客户目录，查看需要联系的人。沟通结束，补一条记录，安排下次跟进。交付和售后人员则在各自的目录更新进度，老板查看汇总和异常事项。
#### 人、AI 工作台、数字员工和定时函数怎样分工
同一套应用可以有不同的使用方式，按工作需要选择即可。
| 使用方式 | 适合的工作 | 例子 |
| --- | --- | --- |
| 员工直接操作 | 录入事实、办理业务、确认需要人决定的事项 | 销售保存沟通记录，负责人确认特殊安排 |
| AI 工作台 | 临时交办任务、跨目录查询和操作、生成或修改应用 | 根据今天的面试安排预约会议室 |
| 数字员工 | 按职责和计划，持续处理需要阅读、判断和多步操作的工作 | 定期检查面试安排，处理符合规则的预约并汇总异常 |
| 定时函数 | 按固定规则反复执行明确动作 | 定期检查网站访问情况并保存结果 |
工作台适合当场提出要求、查看结果、继续补充条件。数字员工则需要提前约定职责和运行计划。两者能做哪些业务操作，都取决于可访问的目录和已提供的能力。
#### 数字员工怎样上岗
沿用前面的招聘与会议室案例，可以把一次预约任务扩展成“面试安排助理”的日常工作。下面是一份可用于实施的职责说明；现有截图展示的是一次会话中的跨目录操作，这套持续运行过程仍需配置和验收。
| 上岗前要确定的事 | 面试安排助理的约定示例 |
| --- | --- |
| 负责什么 | 检查近期面试安排，为符合条件且尚未预约的面试安排会议室 |
| 使用什么资料 | 招聘目录的面试记录、会议室目录的房间与预约记录，以及场地使用说明 |
| 什么时候工作 | 按配置的计划检查；临时变更是否等下一次检查，由业务负责人确定 |
| 可以做什么 | 查询安排与空闲房间，调用获准的预约动作，保存面试与预约的对应关系 |
| 哪些情况交给人 | 没有空房间、面试信息不全、场地要求不明确，或变更超出已约定规则 |
| 怎样算完成 | 预约表中能查到记录，能对应到面试，负责人能看到结果或待处理原因 |
| 谁负责管理 | 招聘负责人检查业务结果，技术维护者处理调用失败和运行问题 |
每次运行时，先检查已有预约，避免同一场面试重复订房。发现改期或取消时，要按明确规则处理原预约；如果应用尚未提供修改或取消能力，就交给负责人处理。通知应说明预约了什么、哪些没有完成，并带上相应记录，便于接手。
正式安排它持续工作前，先试一场正常面试，再试已有预约、无空房间和临时改期等情况。运行以后，负责人主要查看结果和异常，并在业务规则变化时同步更新说明与应用逻辑。
完成后的记录要能供同事接着使用。例如数字员工已经预约会议室，行政人员打开预约表就能查到时间、房间和对应面试；没有完成的事项则保留原因，交给负责人处理。任务是否完成，应以业务记录和实际结果判断。
#### 业务变化后继续调整
业务变化后，原来的应用还可以接着修改。例如新增一个客户阶段，或者给维修工单增加一个处理步骤。修改完成后检查已有数据和操作是否仍然正常，再交给员工使用。
第一轮使用后，可以问几件很实际的事：主管还需不需要在群里反复问进度？同事交接客户时是否还要重新整理资料？自动提醒有没有帮人发现遗漏？这些比安装了多少个应用更能说明效果。
#### 落地时先把责任和规则定下来
第一项工作最好由每天使用它的人参与设计。客户跟进让销售检查，售后工单让接单的人试用。应用有没有用，往往体现在某个字段是否难填、一次交接是否漏信息。
规则明确的部分写进业务动作，例如必填项、状态转换和重复提交的处理。需要读资料、做分析的部分再交给 AI。每个目录都应有负责人，确保规则改了以后，应用和说明也跟着更新。
### C. 实施边界与维护职责
| 适合用 kageos 推进的事情 | 采用时需要明确的边界 |
| --- | --- |
| 建设客户跟进、工单、台账、巡检等业务工具 | 不同企业的规则仍需配置、开发和验收 |
| 通过 AI 加速生成与修改应用 | 生成结果需要验证，复杂问题需要开发或实施人员参与 |
| 让 AI 在业务中查询、分析、处理任务 | 必须明确权限和可执行动作，重要决定应落实到具体业务规则 |
| 在一次任务中跨目录查询与执行 | 需要相关目录的访问权限、可调用动作和明确的关联规则；执行后核对业务记录 |
| 让任务按计划持续运行 | 仍需监控失败、维护依赖，并安排人工接手 |
| 连接已有业务系统 | 需要具体接口和数据关联，不会自动打通任意软件 |
| 安装与复用目录，逐步扩展能力 | 每次安装仍需确认版本、外部配置和适配情况 |
如果企业已经有成熟的财务或复杂 ERP 系统，应评估如何保留并与 kageos 配合。平台的通用能力不意味着已经包含完整的行业规则。
#### 小公司实际需要安排的人和事
采用 kageos，需要有人确认业务规则，也需要有人维护运行环境。这两种职责可以由同一个人承担，技术维护也可以交给实施服务方。
| 什么时候 | 业务负责人负责什么 | 技术维护者负责什么 |
| --- | --- | --- |
| 开始建设 | 选定第一项工作，提供真实做法，指定使用者与负责人 | 准备运行环境，配置账号、模型与所需外部服务 |
| 上线试用 | 用实际业务检查字段、结果和交接方式 | 检查权限、数据保存、任务执行和异常记录 |
| 日常使用 | 处理业务例外，检查数字员工结果，更新操作说明 | 处理运行失败，维护依赖、备份和外部连接 |
| 修改与更新 | 确认新规则，安排使用者试用 | 检查已有数据和常用操作，准备必要的恢复方案 |
已有客户、财务等系统可以按需要保留。接入前先约定哪套系统的记录为准、哪些信息需要同步、同步失败由谁处理，再开发或配置具体接口。
费用除了运行环境，还可能包含模型调用、外部服务，以及定制和维护投入。本文没有经过统一口径核算的成本数据，不给出固定的省钱或省时比例。
通用可视化工作流、通用审批以及企业私有 Hub 等内容，本文不作为已完整交付的能力承诺。具体版本以实际实现与验收结果为准。
如果团队需要完全标准化、买来就用且不打算维护的专业系统，应先核对现有目录是否覆盖自己的要求。kageos 更适合愿意根据业务逐步建设和调整应用的团队。
---
### D. 配图与验证范围
- 工作空间、Hub、监控图片来自演示环境；收银和跨目录图片由用户提供，保留原始尺寸与状态。
- 收银截图展示应用返回的订单号和支付结果，不作为真实资金交易凭证。
- 跨目录截图展示会话返回结果，尚未独立回查预约表。其中一场现场面试也被安排了视频面试室，需核对场地规则。
- 监控统计只代表截图时的演示环境，不能用于容量或 SLA 承诺；通知是否送达仍需核对通知记录。
- 应用生成、数字员工持续运行、Hub 安装的完整实录待补，正文中的建设过程为实施示例。
[巡检日志原图](docs/assets/kageos-enterprise/large/10-monitor-log.jpg)保留每次检查明细，截图时页面显示超过 26 万条记录。
定位依据见[背景与世界观](kageos-background-and-worldview.md)和[官网说明](https://kageos.com/zh/what-is-kageos/)。技术实现见[当前架构](docs/current-architecture.md)和[平台能力](docs/platform-capabilities.md)。配图来源与验证范围见[原始配图说明](docs/assets/kageos-enterprise/large/README.md)。