2.1 开发环境搭建#

由于公司内部研发环境主要依托 VDI 虚拟机设备，因此今天首先完成了开发环境相关配置。

已完成内容包括：

• 完成 VDI 虚拟机开发环境接入与基础配置；
• 完成 Java 开发环境安装；
• 初步具备后续进行项目代码阅读、开发和调试的基础条件。

这一部分虽然属于基础准备工作，但对后续正式参与项目开发非常重要。只有先保证开发环境可用，后续才能进一步开展代码阅读、接口联调和功能开发。

2.2 参加项目规划介绍#

在完成环境配置后，领导对当前项目的整体规划进行了介绍。通过这部分沟通，我初步了解到团队当前主要围绕内部业务提效展开工作，目标是通过系统化、自动化的方式减少人工重复操作，提高跨系统流程流转效率。

2.3 参加团队业务会议#

晚上团队负责人组织了会议，向参与项目的成员进一步介绍了项目思想和任务方向。通过这次会议，我对个人后续工作内容有了更明确的认识，尤其是对财务、供应链、ERP、Web 自动化和 Agent 智能客服之间的关系有了初步理解。

3.1 团队定位#

我所在的小组主要是一个提效类团队，整体上类似于中台提效方向。团队的工作重点不是开发某一个孤立功能，而是围绕公司内部业务流程，减少人工操作成本，打通不同系统之间的流程壁垒。

从部门性质来看，我目前参与的是职能岗相关研发工作，主要服务于公司内部业务系统的流程优化和自动化建设。

3.2 当前项目背景#

当前项目涉及财务和供应链等业务模块之间的流程衔接。供应链模块的上游可能会与财务模块产生连接，因此需要解决财务侧数据、表单和流程如何顺畅传递到供应链侧的问题。

过去财务模块和供应链模块之间相对分散，不同平台、不同模块之间的代码结构和业务流程差异较大，导致数据流转和流程处理不够统一。

因此，项目希望通过统一的流程规范和系统设计，将财务到供应链之间的业务链路打通。

4.1 当前存在的问题#

根据今天的沟通，我理解当前业务中主要存在以下问题：

• 财务模块和供应链模块之间流程较分散；
• 两个模块可能分别维护不同的代码逻辑和平台能力；
• 财务侧表单数据流向供应链侧时，缺少统一标准；
• 部分操作依赖人工在 ERP 或其他系统中完成，效率较低；
• 跨系统链路不够顺畅，容易形成流程壁垒。

4.2 项目希望解决的目标#

项目的核心目标并不是简单做一个页面或接口，而是希望把财务和供应链之间原本割裂的流程统一起来。

例如，财务侧完成某类表单处理后，表单输出的数据可以按照统一规范直接传递到供应链侧平台或代码模块中，减少中间人工操作和系统差异带来的阻碍。

我的理解是，这项工作的本质是：

将财务侧的表单处理、数据输出和供应链侧的业务流程进行统一编排，使两个模块能够按照同一个流程框架完成衔接。

5.1 方向一：Web 端流程自动化#

5.2 方向二：企业微信工作台智能客服 Agent#

6.1 核心任务理解#

结合 Leader 的介绍，我理解自己后续主要负责的是企业微信工作台智能客服 Agent 相关方向。

我的任务重点不是直接开发所有底层业务流程，而是利用 Agent 技术完成用户意图识别、参数提取和流程分发。

简单来说，我负责的是：

把用户的自然语言需求，转化成系统能够理解、能够匹配、能够调用的业务流程指令。

6.2 Agent 在链路中的作用#

在整个业务链路中，Agent 更像是用户和后端自动化流程之间的中间层。

它需要完成以下工作：

1. 理解用户输入内容；
2. 判断用户真实意图；
3. 提取用户表达中的关键参数；
4. 判断用户想走哪一条业务链路；
5. 将识别结果映射到对应的后端流程分支；
6. 调用同事在 Web 端或后端实现的自动化服务链路；
7. 在关键节点引入用户确认或人工确认。

6.3 整体流程理解#

我目前理解的整体流程如下：

1
用户在企业微信工作台输入需求
2
        ↓
3
Agent 识别用户意图
4
        ↓
5
Agent 提取关键参数
6
        ↓
7
匹配对应业务流程分支
8
        ↓
9
调用 Web 端或后端自动化链路
10
        ↓
11
必要时进行人工确认
12
        ↓
13
确认无误后继续执行业务流程

6.4 个人角色定位#

从个人职责来看，我更像是在做“自然语言入口到业务自动化链路之间的连接层”。

我的工作价值在于：

• 降低用户理解系统菜单的成本；
• 提高用户触发业务流程的效率；
• 帮助系统准确判断用户要办理的事项；
• 将用户需求分发到正确的业务链路；
• 为财务与供应链流程自动化提供更自然的交互入口。

7.1 为什么不能完全交给 Agent#

Leader 今天也提到，这类业务不能简单地把所有权限都交给 Agent 自主决策和执行。

原因是当前场景涉及财务、供应链、ERP 等企业内部业务系统，很多操作可能影响数据准确性、审批责任和业务结果。如果完全由 Agent 自动执行，风险会比较高。

7.2 Human-in-the-loop 的必要性#

因此，项目后续很可能需要引入 Human-in-the-loop 机制，也就是在关键节点加入人工确认或人机交互。

Agent 可以先完成意图识别和参数提取，但在真正调用关键流程之前，需要让用户或相关人员确认识别结果是否正确。

例如：

• 确认用户想办理的流程类型；
• 确认表单编号是否正确；
• 确认供应链流程分支是否正确；
• 确认财务报表或业务参数是否准确；
• 确认是否允许继续调用后端流程。

7.3 我的理解#

我认为 Human-in-the-loop 是企业级 Agent 场景中非常重要的一环。

它不是降低 Agent 的价值，而是让 Agent 的能力在可控范围内发挥作用。这样既能提升效率，又能降低因模型识别错误带来的业务风险。

8.1 为什么需要知识库增强#

如果 Agent 只依赖大模型自身能力，可能会出现理解不准确、回答不稳定、依据不足等问题。

在企业内部业务场景中，Agent 需要参考明确的业务规则、流程说明、表单规范和系统操作要求。因此，后续可能需要引入知识库增强能力，让 Agent 的判断更加有依据。

8.2 可放入知识库的内容#

后续知识库中可能需要包含以下内容：

• 财务流程说明；
• 供应链业务流程规范；
• ERP 操作文档；
• 表单字段说明；
• 常见问题与处理规则；
• 不同流程对应的触发条件；
• 各类业务链路的参数要求；
• 人工确认和审批规则。

8.3 RAG 在项目中的作用#

这部分与 RAG 思路比较接近，即先从知识库中检索相关内容，再让 Agent 基于检索结果进行判断、回复或流程匹配。

这样可以提升 Agent 在业务场景中的：

• 准确性；
• 可解释性；
• 稳定性；
• 可追溯性；
• 业务依据可靠性。

9.1 对业务的收获#

今天我对当前项目的业务目标有了比较清晰的认识。

项目核心不是单纯开发一个功能，而是围绕公司内部流程提效，尤其是打通财务与供应链之间原本分散的系统链路，使表单、数据和流程能够在统一规范下流转。

9.2 对技术方向的收获#

从技术角度看，该项目涉及的不只是传统 Web 开发，还包括：

• 流程自动化；
• 业务链路编排；
• Agent 意图识别；
• 参数提取；
• 后端服务调用；
• Human-in-the-loop；
• 知识库增强；
• 企业微信工作台集成。

9.3 对个人任务的收获#

我对自己后续任务的理解更加明确：需要围绕企业微信工作台中的智能客服 Agent 场景，完成用户意图识别、参数提取和业务流程分发，将用户自然语言需求连接到后端自动化链路中。

10.1 业务流程层面#

• 财务到供应链之间具体有哪些核心业务流程需要打通；
• 每条业务流程的起点、终点和中间节点是什么；
• 哪些流程当前依赖人工操作；
• 哪些流程适合优先自动化。

10.2 Web 自动化链路层面#

• Web 端自动化链路目前已经实现到什么程度；
• 后端服务是否已经有稳定接口；
• 每个流程分支需要哪些输入参数；
• 调用失败或参数异常时如何处理。

10.3 Agent 能力层面#

• Agent 需要支持哪些典型用户意图；
• 每类意图需要提取哪些关键参数；
• 意图识别错误时如何兜底；
• 多轮对话中如何补充缺失参数；
• 哪些场景需要转人工。

10.4 企业微信集成层面#

• 企业微信工作台入口形式如何设计；
• 用户输入是文本为主还是语音转文字为主；
• 权限控制如何处理；
• 不同岗位用户是否看到不同能力；
• 操作日志和流程记录如何留存。

10.5 知识库建设层面#

• 知识库需要纳入哪些业务文档；
• 文档如何切分和更新；
• 如何保证检索结果准确；
• 如何避免 Agent 编造业务规则；
• 如何让回答和流程调用具备可追溯依据。