Runtime Package
APP.md 只是发现入口；真实 UI、worker、storage、workflow 和业务实现属于 runtime package。
Agent App可执行的完整智能应用。
让完整智能应用通过共享宿主能力和 App Server bridge 契约运行。
Skip to content
Agent App 定义什么
| 契约 | 回答的问题 |
|---|---|
| App 包 | 这是哪个可安装应用，包含什么？ |
| 入口 | 宿主应暴露哪些 page、command、workflow、artifact、background-task 或 settings？ |
| 能力 | 这个 App 依赖哪些宿主标准和能力表面？ |
| 绑定与上下文 | 用户或租户需要满足哪些 Context、Knowledge、Skill、Tool、Connector、Artifact、Evidence、Policy 和 QC 依赖？ |
| 投影 | 宿主如何把 App 编译成目录，而不发明第二套 Runtime？ |
| 就绪检查 | 运行前哪些 runtime、connector、权限、evidence 和质量门禁必须通过？ |
快速入口
按角色阅读
| 角色 | 先读 | 再读 |
|---|---|---|
| App 作者 | 快速开始 | Runtime Package、Manifest 设计、权限、发布。 |
| 宿主实现者 | 桌面宿主一致性 | 运行时模型、Capability SDK、投影、Readiness、安全模型。 |
| 标准审查者 | 规范 | JSON Schemas、术语表、版本说明。 |
| 产品规划者 | 什么是 Agent App？ | App 与 Agent 标准生态边界、示例、小程序类比。 |
当前承诺
当前 App 应该在执行前可理解，不修改宿主 Core 也能安装，通过 typed capability handles 运行，通过 RuntimeCore 派生的 Agent task 事件观测，能说明交付边界，能说明用户如何安装它，并能说明 lime.agent / lime.workflow 调用如何进入 App Server JSON-RPC。它还应遵循共享宿主模型：用户态和平台能力来自宿主，App 私有存储和 App 后端服务保持隔离。如果一个 package 不能说明 entry、权限、数据边界、runtime assets、任务输出契约、外部集成、副作用、人工审批边界、安装模式、runtime bridge 和本地存储位置，它还不适合作为 Agent App 分发。
完整页面应回答什么
本 docs 中每个 Agent App 页面都应帮助读者回答四个问题：这个概念负责什么边界、manifest 或 runtime 用哪些字段表达、宿主应如何实现、达到发布级需要哪些检查。如果一个页面只解释术语，却没有实现线索、readiness 或失败模式，就应继续补齐。
典型实现顺序
- 定义 App 边界和用户可见 entries。
- 写清 requirements、boundary、integrations、operations。
- 写清 install contract，说明宿主内安装、独立安装、Runtime-backed 或 Web Host 分发方式。
- 写清 App Server bridge profile，说明
lime.agent/lime.workflow如何执行。 - 声明 capabilities、storage、Runtime、UI、Context、Knowledge、Skills、Tools / Connectors、Artifacts、Evidence、Policy、QC、permissions 和 Evals。
- 增加 runtime package assets，并通过 Capability SDK 调宿主能力。
- 先做 projection 和 readiness，再开放执行。
- 发布时带 package hashes、compatibility metadata、overlays、install metadata、bridge metadata 和 rollback guidance。