Article

2026-03-03-企业数字化Agent

蚂蚁集团-人事板块

企业数字化 Agent 原型项目(组织文化方向)


一、项目背景

2023 年,组织文化团队希望探索“对话式数字化管理助手”,用于支持员工在组织文化相关场景下的事务查询与操作,例如会议预定、员工信息查询、日程安排协同等。

该项目本质上是一个早期企业内部 Agent 原型系统,目标是在对话场景中完成从意图识别到能力调度再到接口执行的完整闭环。

我作为 HR 技术部门 P5 后端开发工程师,因资源紧张临时参与该项目约两个月时间,主要负责后端能力模型设计与接口调度逻辑实现。


二、目标与范围

项目目标

构建一个基于对话驱动的事务执行框架,实现:

  • 对用户输入进行意图识别
  • 匹配对应业务场景
  • 在限定能力范围内调度接口执行
  • 支持知识库检索与业务接口调用并行存在

项目范围

系统核心抽象结构包括:

  • 场景(Scenario)
  • 插件(Plugin)
  • 接口(API)
  • 知识库能力(Knowledge Retrieval)

典型场景示例:会议室预定

  • 查询参会人员规模
  • 查询会议室可用情况
  • 查询日程冲突
  • 最终执行预定接口

三、核心逻辑与技术方案

1. 整体执行模型

系统采用“强约束式能力分层模型”:

意图识别

场景匹配

插件集合(插件组)

接口调用

知识库能力与插件能力处于并行位置,在场景范围内可同时被调用。


2. 数据模型设计

围绕能力抽象设计三类核心配置表:

  1. 场景表(Scenario)
  2. 插件表(Plugin)
  3. 接口表(API)

结构关系:

一个场景

绑定多个插件(插件组)

插件下包含多个接口

设计原则:

  • 场景用于限制能力范围
  • 插件用于封装业务领域能力
  • 接口是最小执行单元
  • 知识库能力作为独立能力源存在

3. 执行流程逻辑

完整调用链如下:

  1. 用户输入对话内容
  2. 意图识别模块匹配对应场景
  3. 在该场景绑定的插件组范围内搜索可用能力
  4. 在插件下定位具体接口
  5. 执行接口并返回结果

实现方式偏向策略模式驱动:

  • 通过场景确定能力范围
  • 再通过插件映射接口
  • 最终执行固定映射关系的 API

属于规则驱动 + LLM 辅助的执行模型。


4. 架构特点

  • 强约束模型:先限定场景,再限定插件范围
  • 插件为领域能力封装
  • 接口为最小执行单元
  • 知识检索与接口调用并行存在
  • 无统一协议层(如 MCP)
  • 无自主规划能力(无动态 workflow 生成)

本质上属于规则驱动型半自动 Agent 原型。


四、关键难点

1. 架构抽象难度大于编码难度

实际编码复杂度并不高,核心难点在于:

  • 如何抽象“场景”的粒度
  • 如何定义“插件”的边界
  • 如何控制能力范围避免失控
  • 如何平衡规则与模型能力

当时企业 Agent 体系尚未成熟,缺乏成熟架构参考。


2. LLM 能力不稳定

  • 意图识别准确率存在波动
  • Prompt 设计经验有限
  • 多轮对话状态管理能力弱
  • 无成熟工具选择策略

因此整体设计偏向“规则兜底”。


3. 跨团队协作挑战

  • 组织文化团队主导业务逻辑
  • HR 技术团队负责技术实现
  • 需求边界与场景定义多次调整

需要在不完全确定的业务模型下做能力抽象。


五、风险与应对策略

风险应对策略
意图识别误判强场景约束 + 插件范围限制
能力失控场景绑定插件组
接口误调用固定接口映射关系
模型输出不可控提高规则比例
多轮状态混乱简化 workflow 设计

整体思路为:

用规则控制边界,用模型提升体验。


六、技术定位与能力认知

从今天的视角回看,该项目可以映射为:

  • 接口 = Tool
  • 插件 = Toolset / 领域能力模块
  • 场景 = 受限 Skill
  • 整体执行流程 = 固定 Workflow
  • 无协议层(无 MCP 抽象)

属于“强约束型企业 Agent 雏形”。

与现代 Agent 差异在于:

  • 无 Planner 层
  • 无动态能力编排
  • 无标准化能力接入协议
  • 工作流为预定义结构

七、个人角色与贡献

  • 参与后端能力模型设计
  • 设计场景-插件-接口三层抽象模型
  • 实现策略模式驱动的接口调度逻辑
  • 参与接口映射与能力边界划分
  • 支撑业务场景落地

时间周期约两个月。


八、过程反思

  1. 项目难点在抽象层,而非编码层。
  2. 能力分层模型本质接近现代 Agent 架构。
  3. 插件结构与 Toolset 概念高度相似。
  4. 强约束设计在早期阶段是合理选择。
  5. 若引入 Planner + 协议层(如 MCP),可升级为现代企业 Agent 平台。

九、QA 总结

Q1:你在项目中的定位是什么?
A:P5 后端工程师,负责能力模型实现与接口调度逻辑落地。

Q2:技术难点在哪里?
A:能力抽象与边界控制,而非接口开发本身。

Q3:这个项目算 Agent 吗?
A:属于规则驱动型早期企业 Agent 原型。

Q4:与现代 Agent 的差距?
A:缺少 Planner、自主编排与协议层抽象。