利唐蜂巢企业智能体工作平台白皮书

本白皮书按照不同职能角色的核心关注点组织，建议读者按需查阅对应篇章：

• 战略与商务（第 1 ~ 4 章）：适合管理层、CIO 与商务决策者，阐述定位、接入价值、触点形态与合作模式；

• 产品与能力（第 5 ~ 6 章）：适合产品经理、数字化负责人与架构师，详解 Agent 架构、端云协同与场景矩阵；

• 技术接入（第 7 ~ 11 章）：适合技术团队、研发与系统管理员，提供 A2A、Webhook 协议规范与端到端联调代码；

• 落地与运营（第 12 ~ 13 章）：适合项目经理、实施团队与运营负责人，明确四步推进节奏、三级 SLA 与联合共创。

利唐蜂巢由六大核心能力支柱构筑而成：

1. 智能规划执行：自动拆分复杂业务目标、编排工具链、串联多轮推理，将用户一句自然语言目标转化为确定性的可执行动作序列；

2. 本地环境操作：在用户授权的桌面 PC 上受控读取文件、调用本地软件、生成交付物落地，实现真正实用的端云协同；

3. 多智能体协同：支持多个子智能体并行分工、结果交叉校验与自动汇总，让每位员工背后都有一个专属 AI 专家团队；

4. 跨端遥控与续接：在手机 App、企业微信或钉钉发起的任务，可在桌面客户端继续查看与控制，Thread 会话与产物多端无缝流转；

5. 定时与主动服务：7×24 小时后台运行定时任务，实现系统巡检、经营盯盘、例会准备、舆情监测等主动式推送；

6. 生态扩展与资产复用：集成五级能力资产（应用、插件、智能体、技能、工具），支撑开箱即用与持续演进。

• 管理层与 CIO：关注全员协同提效、跨部门数据对齐、经营指标透明与数据资产私有安全；

• HR 与职能业务负责人：关注新员工入职协同、考勤假勤问答办理、薪酬规划、员工心声分析等高频业务闭环；

• IT 运维与安全团队：关注统一身份 SSO 鉴权、受控网络网关、沙箱隔离、操作审计与告警处置；

• 开发者与数字化搭建者：关注 A2A 智能体互联、Webhook 自动化接入、技能与插件开发、工具（连接器：CLI 与 MCP）扩展。

• 触点密度放大：桌面、移动端与即时通讯多触点覆盖，使 AI 从“偶尔想起打开使用”转变为“随身待命、主动协同”；

• 上下文深度放大：结合企业组织主数据、业务历史、知识库与现场数据，使 AI 的规划决策建立在真实的业务上下文之上；

• 执行半径放大：通过连接器触达 ERP、CRM、OA 与本地桌面软件，让 AI 的决策能够真正落地为业务动作，不再停留在聊天屏幕内。

• 痛点 1（缺少专业语境）：通用 AI 不懂企业特有术语与制度。解法：注入利唐 i人事主数据与 垂直领域专家智能体，天生具备专业业务深度；

• 痛点 2（跨系统流程割裂）：数据散落在 CRM、OA、ERP 中。解法：统一连接器与 MCP 协议标准，支持跨系统一键取数与回写；

• 痛点 3（本地云端脱节）：云端大模型无法批量处理用户本地桌面报表。解法：桌面智能体受控沙箱，安全操作本地文件与应用；

• 痛点 4（安全与合规风险）：担心核心商业数据泄露。解法：私有化/混合云部署、最小权限管控、关键操作强制 HITL 审批留痕。

• 利唐蜂巢平台：提供稳定安全的 Agent 规划引擎、受控沙箱、A2A 与 Webhook 开放能力及专家资产库；

• 业务部门 / 实施伙伴：提供业务场景需求、行业数据规范、系统集成连接与本地化运维；

• 终端用户（员工/管理者）：在日常工作中享受无缝智能体协同，提供真实业务反馈与验收。

• 模式① 深度联名与桌面预装：在企业 PC 或定制终端中预装蜂巢客户端，深度集成系统级快捷唤起能力；

• 模式② A2A 与 Webhook 集成：智能体通过 A2A 发现并调用蜂巢能力，业务系统通过 Webhook 触发预配置自动化任务；

• 模式③ 私有化部署与战略共创：针对大型政企客户提供全栈私有化部署，共同开发定制化行业专家智能体；

• 模式④ 混合云与算力托管：敏感数据留在企业内网，复杂计算与大模型推理通过安全网关接入托管算力。

• 样板 A · 大型集团全员 AI 工作台：覆盖 5000+ 员工，打通企微消息入口与内网 OA，实现经营周报与审批流转自动化；

• 样板 B · 利唐 i人事与 HR 专家深度融合：将薪酬规划、面试官辅助、假勤问答直接注入 HR 业务流，服务数百家企业 HR 团队；

• 样板 C · 智能硬件与会议终端集成：智能麦克风采集音频后直连蜂巢云端，自动输出会议纪要并派发待办任务。

• 理解层：多模态输入解析（文本/语音/文件/界面截图），结合上下文精准识别业务意图；

• 规划层：将复杂目标自主拆解为步骤链条，动态挑选合适工具与子智能体；

• 记忆层：跨端长期记忆（企业知识与历史习惯） + 任务短期会话上下文，支持跨端无缝续接；

• 执行层：在受控沙箱内调用 Skill / 连接器 / 本地应用，产生确定性交付物；

• 调度层：7×24 小时定时轮询、事件监听与多智能体并行调度。

• 桌面端（Local）：专注本地环境与文件操作，利用本地算力与受控权限保障隐私；

• 云端（Cloud）：承载全天候持续运行、消息通道长连接、大规模多模态推理与跨系统调度；

• 能力市场：按应用、插件、智能体、技能、工具五级分层，支持企业自由组合。工具包含连接器（CLI 与 MCP）。

• Agent Card：对端无需登录即可发现账号公开的智能体能力与 RPC 地址；

• JSON-RPC：使用 Bearer Token 调用 SendMessage / message/send 发起任务，使用 GetTask / tasks/get 查询状态；

• 上下文续接：同一 peerName 与 contextId 映射到隔离会话，支持多轮协作；

• P0 边界：支持文本任务与任务查询；CancelTask、SSE、任务列表及主动向对端推送暂不开放。

• 外部系统以 HTTP POST 触发 kind=webhook 的自动化任务，接口入队后立即返回 202；

• 调用方使用 X-Timestamp、X-Signature 与 Idempotency-Key 完成 HMAC 鉴权和幂等控制；

• 请求仅接收任务已声明的扁平参数，参数被视为不可信数据，不会获得额外工具或凭证权限；

• 调用方可使用同一 HMAC 规则按 runId 查询 queued、running、succeeded、failed 或 cancelled 状态。

• Base URL：https://xhive.ihr360.com；

• Agent Card：GET /mc/a2a/{tenantCode}/{accountId}/.well-known/agent-card.json；

• 兼容发现：GET /mc/a2a/{tenantCode}/{accountId}/.well-known/agent.json；

• JSON-RPC：POST /mc/a2a/{tenantCode}/{accountId}/a2a/v1；

• tenantCode 由平台生成；调用方应优先读取 Agent Card 中的接口 URL，不自行拼接生产地址。

Agent Card 发现不要求 Authorization；JSON-RPC 必须携带 Authorization: Bearer <peer_token>。Token 在账号范围内映射为固定 peerName，消息体不能自行声明或覆盖调用身份。凭证应保存在服务端密钥系统中，不得写入 URL、前端代码、日志或 Agent Card。

returnImmediately=true 时接口立即返回 WORKING，调用方随后使用任务 id 轮询；未设置时平台可在配置的 replyTimeoutMs 内等待终态，超时仍诚实返回 WORKING。默认每个 peer 每分钟 30 次请求，具体以账号配置为准。

调用方只能查询由同一 peer 创建的任务。任务状态与最终文本产物保留有限时间；当前实现中 WORKING 与终态默认保留 24 小时。

• POST https://xhive.ihr360.com/mc/automation/{tenantCode}/{automationId}；

• Header：X-Timestamp 为 Unix 秒，允许与服务器时间相差不超过 300 秒；

• Header：Idempotency-Key 必填，长度 1–128；同一 key 与相同 body 在 24 小时内返回同一组 runIds；

• Header：X-Signature=sha256=<hex>；禁止使用 ?token=；

• canonical：{timestamp}.POST.{path}.{idempotencyKey}.{sha256_hex(rawBody)}；

• 请求体最大 64 KiB，格式为 { "params": { ... } }。

成功入队返回 HTTP 202、runIds 与 Location；多项目任务可能一次产生多个 runId。查询单条运行使用 GET /mc/automation/{tenantCode}/{automationId}/runs/{runId}，GET 仍需 X-Timestamp 与 X-Signature，但 canonical 不包含 Idempotency-Key：{timestamp}.GET.{path}.{sha256_hex(emptyBody)}。公网接口不提供运行列表或取消接口，也不返回 threadId、runtimeId 和工具轨迹。

A2A 适合需要能力发现、自然语言任务、contextId 续接和任务轮询的智能体对接；Webhook 适合 PR、告警、订单状态等结构化事件触发预配置任务。Webhook 参数不能临时扩大任务的工具、凭证或数据权限。

A2A 请检查 RPC 是否携带正确的 peer Bearer Token；Webhook 请检查服务器时间、X-Timestamp、原始请求体哈希、请求 path、Idempotency-Key 与 HMAC secret 是否完全一致。签名必须基于发送前的原始 UTF-8 body 计算。

Webhook 在 24 小时内复用同一个 Idempotency-Key 但请求体发生变化时返回 409。若是同一业务事件，请保持请求体一致；若是新的业务事件，请使用新的幂等键。暂停的 Webhook 任务也会返回 409。

按响应中的 Retry-After 退避重试。A2A 默认按 peer 限流；Webhook 在鉴权成功后按任务限流，并同时受任务并发占用约束。重试 Webhook 时应保持原 Idempotency-Key 与原始请求体，避免重复创建运行。

所有公网路径都包含平台生成的 tenantCode，并在服务端按 tenantId 与账号或任务联合查找。A2A Task 还校验 owner peer；Webhook 查询只允许通过对应任务 secret 的 HMAC 访问指定 runId。

• 01 · 需求挖掘：梳理企业高频业务场景、明确痛点断点、目标用户与关键业务指标；

• 02 · 结合点确认：确认业务系统接口、知识库现状与蜂巢能力的交集，选定首批验证智能体包；

• 03 · 模式设计：确定部署形态（私有云/混合云/A2A 或 Webhook 集成）、鉴权方式与商务口径；

• 04 · 技术落地：完成身份对接、网络打通、沙箱配置、灰度内测与全量发布。

• 阶段一 · 概念验证（PoC，约 2~4 周）：跑通核心高频场景 Demo，输出可行性验证报告；

• 阶段二 · 最小可行上线（MVP，约 4~8 周）：完成标准集成与单部门试运行，建立运维闭环；

• 阶段三 · 全量推广（GA，约 8~12 周）：全员或全渠道正式发布，开启持续联合运营。

• 合作原则：安全第一、数据私有、责任明确、持续共赢；

• 专属对接：为每个战略企业项目配备专职解决方案架构师（SA）与技术客户经理（TAM）。

• L1 · 常规支持：提供开发者文档、视频教程、知识库与技术社区；

• L2 · 运维技术支持：通过企业微信或工单系统受理，响应时限以服务约定为准；

• L3 · 专家级支持：按问题复杂度协调架构与产品人员，具体支持范围以服务约定为准；

• 服务级别约定：可用性目标、故障分级与响应时限由双方结合部署方案和服务合同确认。

• 数据看板与用量洞察：提供可视化仪表盘，实时观察任务调用量、成功率、Token 消耗与瓶颈分析；

• 联合宣发与生态共创：优秀企业实践入选官方标杆案例，共享行业峰会与品牌曝光资源；

• 版本持续演进：保持月度小版本迭代与季度大版本升级，定期吸纳企业共创需求。