01Agent · 飞书 · 企业任务
MaaS 百事通|企业任务型 Agent
把飞书中的自然语言请求转化为可恢复、可审批、可审计的业务任务,而不只是生成一段回答。
01
问题与角色
要解决的问题
公司内部十余个业务系统让员工反复找入口、找字段和找负责人。传统聊天 Agent 能生成答案,却无法可靠回答:它代表谁操作、事实是否过期、谁批准了发送、失败后从哪里恢复。
我的职责
我负责产品定义、目标架构、业务控制面实现、安全治理和验收体系。底层通用 Runtime 基于开源 Hermes Agent 扩展;NormalizedEvent、Task/Evidence/Approval/Delivery、上下文组装、长期偏好记忆、飞书接入和企业能力目录为项目新增部分。
从一句话,到一次受控交付
以脱敏业务场景还原飞书任务链路,展示身份绑定、事实校验、用户确认与幂等交付如何协同工作。
把核心闭环讲给面试官看
中文旁白依次展示请求进入、事实治理、审批代码门、幂等交付与总体架构;业务画面经过脱敏重绘。
推理归 Runtime,权力归控制面
一个生产飞书入口、一个业务任务真相源。Hermes 保留工具循环、MCP、Subagent 与预算控制,但不能绕过权限和审批代码门。

身份不可由模型填写
user_id、chat_id 和业务权限来自已认证事件及企业权限源。
记忆不是业务事实库
价格进 Evidence,执行状态进 Task,稳定偏好才进入长期 Memory。
副作用必须可证明
preview → confirm → execute → receipt,全链路绑定同一 Payload。
上下文不是聊天记录拼接
Context Assembler 按权威性和 Token 预算组装每次请求。当前 Task 永远高于历史默认值,低优先级信息可以舍弃并按需从权威存储重新加载。
用户:“把刚才那个产品发出去。”
关键设计选择
比产出清单更重要的,是为什么做这些取舍,以及它们如何降低用户成本和企业风险。
用统一入口替代机器人孤岛
- 问题
- 不同机器人拥有不同入口和上下文,用户必须先理解系统边界,复杂任务无法跨能力完成。
- 选择
- 使用飞书作为统一自然语言入口,以 Capability Catalog 组织企业工具,由 Agent 依据完整上下文选择能力。
- 结果
- 产品信息、价格、知识研究、文档生成与通知可以在同一任务中组合,用户无需切换多个机器人。
把高风险动作做成代码级状态机
- 问题
- 仅依赖 Prompt 要求模型确认,无法防止参数变化、重复执行和越权操作。
- 选择
- 建立 Preview → Confirm → Execute → Evidence 链路,将操作者、目标、参数摘要、有效期和幂等键绑定在服务端。
- 结果
- 查询可直接执行,写操作必须预览确认;参数变化后旧确认自动失效,重复请求不会造成重复发送。
用业务评测连接线上问题与产品迭代
- 问题
- 单元测试只能证明代码能运行,无法证明模型会选对工具、遵守顺序并给出可用结果。
- 选择
- 基于 Langfuse 建立任务、工具、知识与交付指标,把真实会话沉淀为 Gold Set 和异常样本。
- 结果
- Prompt、工具描述、路由和兜底策略都有可重复回归依据,首批真实模型业务评测达到 8/8。
让当前 Task 高于历史 Memory
- 问题
- 把全部会话和长期记忆直接注入 Prompt,会让旧价格、旧对象和历史默认值覆盖本轮任务,同时造成 Token 浪费。
- 选择
- 建立 Context Assembler,按当前实体、回复链、Task、Session、Memory 的权威顺序组装上下文;动态事实进入 Evidence,稳定偏好才进入长期记忆。
- 结果
- 指代消解、任务恢复和上下文压缩都有确定依据;低优先级内容可舍弃并从权威存储按需重载。
从产品方案到可验证系统
项目围绕产品闭环、业务能力和验证体系完成交付,让每一次任务执行都有明确输入、状态、授权、证据与结果。
产品闭环
从请求理解到结果交付
- NormalizedEvent 与身份绑定
- Task / Job / Step / Artifact 状态机
- Context Assembler 与 Token 预算
- 显式授权的 Preference Memory
- 审批、Payload 校验与原子幂等
- 文本 / 卡片 / 文件 / 进度交付
- Capability Catalog 与风险策略
业务能力
覆盖高频企业任务场景
- 产品搜索与产品详情
- 权限校验与套餐查询
- 企业知识库问答
- 通讯录与部门通知
- 飞书鉴权与 Bot 身份
- WebSocket 事件接入
- 统一回执与异常恢复
验证体系
功能、链路与模型三层验证
- 业务控制面自动化测试
- 飞书 Gateway 链路测试
- 真实模型 Gold Set 8 / 8
- 失败路径与恢复测试
- 审批参数一致性校验
- 重复请求幂等验证
- 可追溯 Evidence 与 Delivery 回执
我负责的不只是方案,
还有落地边界和验收证据
借鉴 Doraemon 的异步任务与证据链思路,但没有复制第二套入口、Session 或 Memory;业务状态始终只有一个真相源。
产品与场景
拆解产品查询、查价、知识库、部门通知四条高价值链路,确定飞书为唯一生产入口。
架构与实现
在 Hermes 外建立业务控制面,定义 Task、Evidence、Approval、Delivery、Identity/Policy 的边界。
安全与治理
把“请先确认”从 Prompt 文案升级为代码门,增加身份绑定、精确 Payload 校验和原子幂等。
评测与迭代
建设 Gold Set、失败路径和分层测试矩阵,让 Prompt、路由、工具调用和交付结果具备可重复回归依据。
三层验证分别覆盖业务控制面、飞书链路与模型任务表现,所有公开画面和业务数据均已脱敏。
09
结果与复盘
结果
完成从飞书统一入口、业务控制面、上下文与记忆,到审批、幂等交付和评测证据的完整闭环,形成可恢复、可审批、可审计的企业任务执行系统。
企业 Agent 的护城河不是工具数量,而是对业务身份、任务状态、证据时效、风险和交付回执的建模。模型负责理解和规划,产品必须保证操作可控、结果可验证。
公开案例已完成数据脱敏:公司系统名称、业务价格、组织关系、接口地址和用户信息均使用演示数据替代。