The 2026-05-08 product package (docs/product-package/) redraws the client / Manager boundary. Per 08-client-guide.md §1-7, the client explicitly does NOT carry resource binding, permission grants, or any account / security surface — those move entirely to Manager. This commit removes the client-side resources surface that landed in slices 2-4 (commitsd1db2c1,c0363be,a28c900): Deleted: - cc-haha/desktop/src/api/heicodeResources.ts (API client) - cc-haha/desktop/src/stores/resourceStore.ts (zustand) - cc-haha/desktop/src/pages/ResourceBindings.tsx (page) - cc-haha/desktop/src/components/resources/Modals.tsx (3 modals) - cc-haha/src/server/api/heicode-resources.ts (proxy) Reverted: - Sidebar.tsx: drop the Resources nav item + RESOURCES_TAB_ID import - ContentRouter.tsx: drop the 'resources' branch + import - tabStore.ts: drop RESOURCES_TAB_ID + 'resources' from TabType - router.ts: drop 'heicode-resources' case + handler import - i18n zh.ts + en.ts: strip ~63 keys (sidebar.resources + resources.* + grants.*) Kept (still useful for the new spec's Manager-side data needs): - mcpAuth schema in types/provider.ts - mcpAuth wired through CreateProviderInput / UpdateProviderInput - providerService persistence of mcpAuth on add/update - Path A login flow that decodes JWT exp claims and stores the pair on the saved provider Why keep token persistence even though the client doesn't expose binding/grant UI any more? Per product spec the Manager will surface 余额 / 模型 / 用量 / 调用日志 (§2.3.1 in mcp-server's 待办 doc), and the client will surface high-risk approvals (08-client-guide.md §5). Both flows need a JWT pair we can refresh without re-prompting for password — that machinery is already in place. Next slice candidates per product spec (08 + 10 + 11): - High-risk approval dialog (新增 Tier 1, mock-wired UI first) - Task card + intent input as main client surface - Execution feedback panel (Agnet sub-stage status) - Delivery result panel None of those are in this commit; this commit is purely cleanup. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.7 KiB
3.7 KiB
07. CodeGW、OpenBao、Agnet 平台边界说明
目标
本文用于讲清楚 Heicode 与 CodeGW、OpenBao、Agnet 平台之间的产品和技术边界,避免再次变成缝合式系统。
总体边界
| 系统 | 能力归属 | 普通用户是否直接进入 |
|---|---|---|
| Heicode | 产品总入口,包含客户端主体验与 Manager 辅助控制台 | 是 |
| CodeGW | 模型网关、模型调用、余额、额度、用量日志 | 否 |
| OpenBao | 长期凭证保管、短期凭证租约 | 否 |
| Agnet 平台 | AKS 执行层、状态、日志、事件、指标 | 否 |
Heicode 与 CodeGW
Heicode 使用 CodeGW 的方式:
- 查询普通用户可见模型。
- 查询余额和额度。
- 查询用量和调用日志。
- 建立
channelId、CodeGW user、token 或 group 的映射。
Heicode 不做:
- CodeGW 渠道管理。
- CodeGW 模型供应商配置。
- CodeGW 价格配置。
- CodeGW 管理员用户管理。
- 把 CodeGW 后台开放给普通用户。
产品口径:
CodeGW 是 Heicode 的模型网关和计费底座,用户在 Heicode 中查看模型和用量,不直接使用 CodeGW 后台。
Heicode 与 OpenBao
Heicode 使用 OpenBao 的方式:
- 写入用户授权后的长期凭证。
- 保存和管理
secret_ref。 - 执行密钥 health、metadata、轮换、禁用、撤销。
- 为高危操作申请短期凭证。
Heicode 不做:
- 在数据库保存明文密钥。
- 把 OpenBao token 交给前端。
- 把 OpenBao 作为普通公网服务暴露。
产品口径:
密钥保管器负责保存凭证,Heicode 只保存引用。子 Agnet 使用资源时,平台按权限和审批结果获取短期访问能力。
Heicode 与 Agnet 平台
Heicode 传给 Agnet 平台:
- 用户上下文。
- 任务目标。
- 子 Agnet 角色。
- AGENT.md。
- resource context。
- permission manifest。
secret_ref。- 审批策略。
- 模型和预算配置。
sk_context/tool_permissions。- 回调地址。
Agnet 平台回传 Heicode:
- deployment 状态。
- 子 Agnet 状态。
- 事件。
- 日志。
- 指标。
- 审计事件。
- 使用量。
- 当前子环节状态。
- 中间交付物。
- 部署结果。
Heicode 不传:
- 长期明文密钥。
- CodeGW key 原文。
- OpenBao root token。
- 数据库密码。
产品口径:
Heicode 决定用户想做什么、能用什么资源和谁来做;Agnet 平台负责把这些任务安全运行起来,在过程中按权限调用需要的 SK 工具,并把子环节状态、交付物和部署结果回传给 Heicode。
客户端与 Manager 的边界
客户端主做:
- 登录 Heicode。
- 对话和任务输入。
- 继续补充要求和修正方向。
- 展示 Heicode 提供的模型。
- 高危操作审批。
- 查看执行反馈和交付结果。
Manager 主做:
- 账号与安全。
- 客户端下载。
- Git、文档、SK、云资源绑定。
- Agnet 部署。
- 任务状态、用量和审计查看。
- 风险与授权范围确认。
客户端不做:
- 选择模型提供方。
- 配置 CodeGW 渠道。
- 直接访问 OpenBao。
- 直接保存长期云密钥。
Manager 不做:
- 主开发对话。
- 网页编码。
- 替代客户端完成高危审批。
当前延期项
Heicode 到 Agnet 平台真实部署 API 的完整联调仍可延期。
但 Heicode 侧必须准备好:
- payload。
- manifest。
- 审计字段。
- callback URL。
- 本地占位控制面。
- 日志、事件、指标的数据展示位置。
验收口径
- 普通用户只进入 Heicode。
- 客户端只登录 Heicode。
- CodeGW 独立服务运行。
- OpenBao 只通过受控内网或后端访问。
- Agnet 平台接口只收结构化上下文和
secret_ref,不收长期明文密钥。