← 返回项目

01Agent · 飞书 · 企业任务

MaaS 百事通|企业任务型 Agent

把飞书中的自然语言请求转化为可恢复、可审批、可审计的业务任务,而不只是生成一段回答。

角色产品负责人 & 技术负责人
周期2026.04 — 至今
状态完整案例
飞书 · 销售协同群场景演示
销售协同群18 人
10:24
林可

@MaaS 百事通 把“影眸 X3”的最新价格发给销售一部。

M
MaaS 百事通 机器人

已确认当前产品与有效价格,并生成发送预览。

发送前确认业务通知
影眸 X3¥ 12,800 / 套 · 产品中心 10:24 更新
发送范围
销售一部 · 12 人
内容状态
已通过权限与有效期校验

回复 销售协同群

☺ ⌘

01
问题与角色

要解决的问题

公司内部十余个业务系统让员工反复找入口、找字段和找负责人。传统聊天 Agent 能生成答案,却无法可靠回答:它代表谁操作、事实是否过期、谁批准了发送、失败后从哪里恢复。

我的职责

我负责产品定义、目标架构、业务控制面实现、安全治理和验收体系。底层通用 Runtime 基于开源 Hermes Agent 扩展;NormalizedEvent、Task/Evidence/Approval/Delivery、上下文组装、长期偏好记忆、飞书接入和企业能力目录为项目新增部分。

02 / INTERACTIVE DEMO

从一句话,到一次受控交付

以脱敏业务场景还原飞书任务链路,展示身份绑定、事实校验、用户确认与幂等交付如何协同工作。

飞书 · MaaS 百事通 场景演示
今天 10:24
林可 · 产品运营

把“影眸 X3”的最新价格发给销售一部。

脱敏业务场景 · 展示任务状态与安全确认
03 / 73 秒演示视频

把核心闭环讲给面试官看

中文旁白依次展示请求进入、事实治理、审批代码门、幂等交付与总体架构;业务画面经过脱敏重绘。

73 SEC · 1920 × 1080 · 中文旁白H.264 + AAC
04 / SYSTEM ARCHITECTURE

推理归 Runtime,权力归控制面

一个生产飞书入口、一个业务任务真相源。Hermes 保留工具循环、MCP、Subagent 与预算控制,但不能绕过权限和审批代码门。

MaaS 百事通总架构:飞书入口经过身份策略和业务控制面,进入 Hermes Runtime,再通过能力网关、审批与交付完成任务
统一入口 · 业务控制面 · Hermes Runtime · 能力网关 · 分层状态存储
01

身份不可由模型填写

user_id、chat_id 和业务权限来自已认证事件及企业权限源。

02

记忆不是业务事实库

价格进 Evidence,执行状态进 Task,稳定偏好才进入长期 Memory。

03

副作用必须可证明

preview → confirm → execute → receipt,全链路绑定同一 Payload。

05 / CONTEXT & MEMORY

上下文不是聊天记录拼接

Context Assembler 按权威性和 Token 预算组装每次请求。当前 Task 永远高于历史默认值,低优先级信息可以舍弃并按需从权威存储重新加载。

本轮明确实体回复链当前 TaskSession长期 Memory
Session 早期A 产品
长期默认B 产品
当前 TaskC 产品

用户:“把刚才那个产品发出去。”

系统解析C 产品task_focus · confidence 0.95
Session当前语言现场
Task目标与执行状态
Evidence有时效的业务事实
Approval精确动作授权
Memory明确保存的稳定偏好
Knowledge继承 ACL 的组织知识
06 / PRODUCT DECISIONS

关键设计选择

比产出清单更重要的,是为什么做这些取舍,以及它们如何降低用户成本和企业风险。

01

用统一入口替代机器人孤岛

问题
不同机器人拥有不同入口和上下文,用户必须先理解系统边界,复杂任务无法跨能力完成。
选择
使用飞书作为统一自然语言入口,以 Capability Catalog 组织企业工具,由 Agent 依据完整上下文选择能力。
结果
产品信息、价格、知识研究、文档生成与通知可以在同一任务中组合,用户无需切换多个机器人。
02

把高风险动作做成代码级状态机

问题
仅依赖 Prompt 要求模型确认,无法防止参数变化、重复执行和越权操作。
选择
建立 Preview → Confirm → Execute → Evidence 链路,将操作者、目标、参数摘要、有效期和幂等键绑定在服务端。
结果
查询可直接执行,写操作必须预览确认;参数变化后旧确认自动失效,重复请求不会造成重复发送。
03

用业务评测连接线上问题与产品迭代

问题
单元测试只能证明代码能运行,无法证明模型会选对工具、遵守顺序并给出可用结果。
选择
基于 Langfuse 建立任务、工具、知识与交付指标,把真实会话沉淀为 Gold Set 和异常样本。
结果
Prompt、工具描述、路由和兜底策略都有可重复回归依据,首批真实模型业务评测达到 8/8。
04

让当前 Task 高于历史 Memory

问题
把全部会话和长期记忆直接注入 Prompt,会让旧价格、旧对象和历史默认值覆盖本轮任务,同时造成 Token 浪费。
选择
建立 Context Assembler,按当前实体、回复链、Task、Session、Memory 的权威顺序组装上下文;动态事实进入 Evidence,稳定偏好才进入长期记忆。
结果
指代消解、任务恢复和上下文压缩都有确定依据;低优先级内容可舍弃并从权威存储按需重载。
07 / DELIVERY RESULT

从产品方案到可验证系统

项目围绕产品闭环、业务能力和验证体系完成交付,让每一次任务执行都有明确输入、状态、授权、证据与结果。

产品闭环

从请求理解到结果交付

  • NormalizedEvent 与身份绑定
  • Task / Job / Step / Artifact 状态机
  • Context Assembler 与 Token 预算
  • 显式授权的 Preference Memory
  • 审批、Payload 校验与原子幂等
  • 文本 / 卡片 / 文件 / 进度交付
  • Capability Catalog 与风险策略

业务能力

覆盖高频企业任务场景

  • 产品搜索与产品详情
  • 权限校验与套餐查询
  • 企业知识库问答
  • 通讯录与部门通知
  • 飞书鉴权与 Bot 身份
  • WebSocket 事件接入
  • 统一回执与异常恢复

验证体系

功能、链路与模型三层验证

  • 业务控制面自动化测试
  • 飞书 Gateway 链路测试
  • 真实模型 Gold Set 8 / 8
  • 失败路径与恢复测试
  • 审批参数一致性校验
  • 重复请求幂等验证
  • 可追溯 Evidence 与 Delivery 回执
08 / EVIDENCE & CONTRIBUTION

我负责的不只是方案,
还有落地边界和验收证据

借鉴 Doraemon 的异步任务与证据链思路,但没有复制第二套入口、Session 或 Memory;业务状态始终只有一个真相源。

01

产品与场景

拆解产品查询、查价、知识库、部门通知四条高价值链路,确定飞书为唯一生产入口。

02

架构与实现

在 Hermes 外建立业务控制面,定义 Task、Evidence、Approval、Delivery、Identity/Policy 的边界。

03

安全与治理

把“请先确认”从 Prompt 文案升级为代码门,增加身份绑定、精确 Payload 校验和原子幂等。

04

评测与迭代

建设 Gold Set、失败路径和分层测试矩阵,让 Prompt、路由、工具调用和交付结果具备可重复回归依据。

89 passed业务控制面 + 业务工具 + Replica
536 passed飞书 Gateway / Adapter / Background
8 / 8真实模型业务 Gold Set

三层验证分别覆盖业务控制面、飞书链路与模型任务表现,所有公开画面和业务数据均已脱敏。

09
结果与复盘

结果

完成从飞书统一入口、业务控制面、上下文与记忆,到审批、幂等交付和评测证据的完整闭环,形成可恢复、可审批、可审计的企业任务执行系统。

企业 Agent 的护城河不是工具数量,而是对业务身份、任务状态、证据时效、风险和交付回执的建模。模型负责理解和规划,产品必须保证操作可控、结果可验证。
公开说明

公开案例已完成数据脱敏:公司系统名称、业务价格、组织关系、接口地址和用户信息均使用演示数据替代。

下一个案例结构化模型生产与交付平台