尧图网站建设 
深入解析 AxiomOffice基于 MAF DeepSeek Three.js Pinia 虚拟办公室对接鼎捷 TIPTOP摘要本文完整记录了一个「数字人虚拟办公室」从业务规划到技术落地的全过程。针对制造业销售客服中心「接单 → 跟单 → 排产 → 发货」四条业务链作者将跟单员、PMC、物流客服、客服经理四个岗位做成 AI 数字人基于微软官方 Agent 框架MAF编排多智能体协作用 Three.js 构建 3D 可视化办公室让协作过程「看得见」并真实打通鼎捷 TIPTOP 生产 ERP。方案重点解决了「自然语言 → 系统编码」的实体解析难题通过配置化能力层实现对接新系统只改配置不改代码同时以读写分离、本地私有部署守住数据安全底线。全文附真实可跑的 .NET 10 Vue3 代码为制造业数字化、多智能体与 ERP 的 AI 化落地提供了一套可复用的完整参考。目录业务背景与痛点方案核心设计整体架构项目结构关键实现5.1 数字人可视化让协作「看得见」5.2 角色化多智能体用 MAF 而非自造5.3 跨岗位协作流程5.4 ERP 实体解析落地最关键的一环5.5 配置化能力层安全与合规考量复盘与总结一、业务背景与痛点制造业的销售客服中心核心业务就四条链接单 → 跟单 → 排产 → 发货对应跟单员、PMC、物流客服、客服经理四个岗位。传统的运转方式依赖微信群和 Excel 流转我在梳理需求时发现了三个典型问题1.信息割裂订单在 ERP 里、进度靠打电话、交期靠经验缺乏一个统一的「现在到哪一步了」的视图。2.重复劳动大量「帮我查一下订单进度」「客户编码是多少」这类高频低价值的重复查询。3.落地门槛AI 要真正帮上忙就必须和 ERP 打通——而「用户说客户名系统要客户编码」这层转换是很多人没想清楚、也最容易翻车的地方。基于这三点我设计的解决方案是把四个岗位做成数字人多智能体让它们在一个可视化办公室里自动协作并真实对接生产 ERP。—二、方案核心设计方案里有几个我认为最关键的设计决策设计解决什么问题 数字人可视化多智能体协作「看得见」谁在干活一目了然而不是干巴巴的对话 用微软官方 Agent 框架站在 MAFMicrosoft.Agents.AI上不重复造 agent 轮子 真实 ERP 打通读真实主档、解析真实编码验证方案在真实业务里跑得通 实体解析自然语言 → 系统编码AI 落地 ERP 的关键一环 配置化能力层对接不同业务系统只改配置不改代码 读写分离生产库只读写操作走受控接口守住数据安全底线三、整体架构技术栈层技术AI 编排Microsoft Agent FrameworkMAFMicrosoft.Agents.AI1.6.1大模型DeepSeekOpenAI 兼容IChatClient抽象可替换后端.NET 10 Web API SignalR前端Vue3 Vite Pinia Three.jsERP鼎捷 TIPTOPOracle交互层 Vue3 Three.js 数字人办公室SignalR 实时↓编排层 MAF ChatClientAgent ×4 编排器路由/流程/状态机↓能力层 配置化 HTTP 接口 只读 SQL 查询↓数据层 鼎捷 TIPTOPOracle**设计考量**分层实现彻底解耦——Ai/ 只管模型与 AgentCore/ 管编排与业务前端只管呈现。这样方案里的编排层将来可以直接复用进中台/ESB不会和具体业务绑定死。 csharp axiom-office/ ├── backend/PixelOffice.Api/ # .NET 10 Web API │ ├── Program.cs # DI SignalR 配置加载 │ ├── agents.config.json # 团队 / 流程 / 技能 / 快捷模板 │ ├── tools.config.json # 能力接口 / 只读 SQL / 数据库连接 │ ├── Controllers/ # Task / Agent / Business / Skill / Tool │ ├── Hubs/OfficeHub.cs # SignalR 实时推送 │ ├── Ai/ │ │ ├── MafChatClient.cs # IChatClient ChatClientAgent 工厂 │ │ └── MafAgentRunner.cs # 角色化 agent 流式执行 │ ├── Core/ │ │ ├── AgentOrchestrator.cs # 编排器 数字人状态机 协作流程 │ │ ├── ToolRegistry.cs # 配置化能力层动态构建 AIFunction │ │ ├── BusinessConfig.cs # 业务配置解析 写回 │ │ └── BusinessDataService.cs # 业务数据 实体解析 │ └── Models/ └── frontend/ ├── src/components/ # Office3D / PixelOffice / ChatPanel / ConfigModal... ├── src/store/office.ts # Pinia 全局状态 └── src/api/client.ts # REST SignalR 客户端五、关键实现5.1 数字人可视化让协作「看得见」设计考量市面上大多数多智能体系统只有一堆对话气泡用户根本看不到「现在谁在干活、干到哪一步了」。我在方案里加入了一个 3D 办公室让协作过程可视化——这是让非技术用户也能直观理解「多智能体在协作」的关键。实现每个数字人有一套行为状态机由后端编排器驱动、前端 Three.js 插值动画呈现publicenumAgentStatus{Idle0,// 坐工位待命Walking1,// 走动Thinking2,// 思考Working3,// 工作打字Overloaded4,// 过载Break5// 休息站立}数字人默认坐工位并会定时起身去休息区活动再回来。状态机由后端驱动、前端呈现业务编排和呈现彻底解耦——这是能持续扩展更多数字人的基础。5.2 角色化多智能体用 MAF 而非自造设计考量与其自己实现 agent 循环、工具调用、多轮对话不如站在微软官方的 Agent 框架上。MAF 的ChatClientAgent把「角色 指令 工具 agentic loop」都封装好了模型还能通过IChatClient抽象热替换。实现模型层用IChatClient隔离publicstaticIChatClientCreateDeepSeekChatClient(IConfigurationconfiguration){varsectionconfiguration.GetSection(DeepSeek);varopenAiClientnewOpenAIClient(newApiKeyCredential(section[ApiKey]),newOpenAIClientOptions{EndpointnewUri(section[BaseUrl])});returnopenAiClient.GetChatClient(section[Model]).AsIChatClient();// OpenAI SDK → IChatClient}角色化 Agent 流式varagent_chatClient.AsAIAgent(newChatClientAgentOptions{NameagentName,// 如「跟单员」DescriptionagentName,ChatOptionsnewChatOptions{InstructionssystemPrompt,// 岗位职责提示词Toolstools.Select(t(AITool)t).ToList()// 该岗位的能力集}});varsbnewStringBuilder();awaitforeach(varupdateinagent.RunStreamingAsync(messages,null,null,ct))if(update.Textis{Length:0}delta){sb.Append(delta);onDelta(delta);}// 打字机ChatClientAgent内部自动完成「模型 → 工具调用 → 模型 → …」的 agentic loop不用手写。5.3 跨岗位协作流程设计考量客服中心的业务是「链式」的——接单后要排产排产后要发货。我把这些链做成可配置的流程命中触发词即启动上一步结果自动作为下一步上下文。订单交付全流程跟单员接单 → PMC 排产下达 → 物流装车交付 交期催办 跟单员核实进度 → PMC 确认产线进度 交期答复 跟单员接询问 → PMC 确认进度与交期 → 跟单员回复客户实现——上一步的产出自动拼成下一步的上下文privateasyncTaskAdvanceFlowAsync(TaskItemcompleted){if(string.IsNullOrEmpty(completed.FlowId))return;varflow_flows.FirstOrDefault(ff.Idcompleted.FlowId);varnextIndexcompleted.StepIndex!.Value1;if(nextIndexflow.Steps.Count)return;varstepflow.Steps[nextIndex];// 交接上下文 前面所有已完成步骤的结果拼接varhandoffstring.Join(\n\n,flowTasks.Where(tt.StepIndexnextIndext.StatusDone).OrderBy(tt.StepIndex).Select(t$【{t.AssigneeName}】{t.Result}));Enqueue(newTaskItem{StepIndexnextIndex,PromptFillPrompt(step.Prompt,request,handoff)},step.AgentId);}一个取舍这里保留手写流程而不是用 MAF 的AgentWorkflowBuilder黑盒执行——因为这层流程同时承担「数字人动画驱动」的职责黑盒化会丢掉逐步骤的动画控制。5.4 ERP 实体解析落地最关键的一环设计考量这是「AI 落地 ERP」里最容易被忽略、也最关键的问题——用户说「恒源顺科技」ERP 建单要的是客户编码。大模型不能「猜」编码必须查主档。我用了三层漏斗三层漏斗自然语言「恒源顺科技」 ↓ ① 召回调 query_customer 模糊查主档 候选 [1601113005 恒源顺科技-田继中, A51040007 攀枝花市恒源顺科技] ↓ ② 精排大模型读候选选最匹配歧义则列出 ↓ ③ 确认回显给用户确认再拿编码建单实现——能力由配置动态构建成 MAF 的AIFunctionMEAI 的AIFunctionFactory不支持自定义 JSON Schema故自实现AIFunction子类privatesealedclassConfigTool:AIFunction{privatereadonlyFuncIReadOnlyDictionarystring,object?,CancellationToken,Taskobject?_invoke;publicConfigTool(stringname,string?description,JsonElementjsonSchema,FuncIReadOnlyDictionarystring,object?,CancellationToken,Taskobject?invoke){Namename;Descriptiondescription??;JsonSchemajsonSchema;_invokeinvoke;}publicoverridestringName{get;}publicoverridestringDescription{get;}publicoverrideJsonElementJsonSchema{get;}protectedoverrideasyncValueTaskobject?InvokeCoreAsync(AIFunctionArgumentsarguments,CancellationTokencancellationTokendefault){vardictnewDictionarystring,object?();foreach(varkvinarguments)dict[kv.Key]ToScalar(kv.Value);returnawait_invoke(dict,cancellationToken);// 执行 HTTP / SQL}}读写分离读走只读 SQL生产库默认只读写走受控 WebAPI避免裸写生产库。{dbQueries:[{name:query_customer,description:按客户名称模糊查找客户编码,sql:SELECT occ01 AS customer_code, occ02 AS customer_name FROM occ_file WHERE occ02 LIKE %||:keyword||%,roles:[order-clerk],parameters:[{name:keyword,type:string,required:true}]}]}实测问「恒源顺科技」返回两条真实客户并让用户确认1601113005 xxx科技-田田中、A51040007 攀枝花市xxx科技。5.5 配置化能力层设计考量一个方案能不能复用、能不能对接更多业务系统取决于「改配置」还是「改代码」。我把对接能力做成了配置化——对接新系统只加配置不改代码这是从「一次性项目」到「可复用方案」的分水岭。配置项说明团队管理岗位名/职责/提示词/图标/颜色/工位坐标可增删岗位流程管理流程名/触发词/步骤链可增删流程和步骤可运行测试AI 技能管理技能名/图标/所属岗位/描述/启停能力中心HTTP 接口 只读 SQL 查询 数据库连接虚拟团队管理数字人团队 快捷派单模板—六、安全与合规考量做企业级方案安全是不能省的底线本地私有部署整套系统部署在本地/内网不依赖公有云。数据不上传业务数据全程本地流转不上传任何第三方 AI 平台。️ERP 只读生产库默认只读写操作走受控接口。模型可替换大模型通过IChatClient抽象接入可换私有化模型。七、复盘与总结这套方案走下来有三点我认为1.用成熟框架不重复造轮子MAF 的IChatClientChatClientAgent 流式 配置化工具覆盖了多智能体 90% 的需求。2.把「业务编排」和「可视化呈现」解耦数字人状态机独立驱动动画两边各自演进、互不拖累。3.AI 落地 ERP先解决「实体解析」自然语言到系统编码这层转换不解决后面所有「自动建单」都是空中楼阁。都是空中楼阁。这套方案从需求分析、方案设计到技术实现和 ERP 落地完整跑通了一条链路。如果你也在做制造业数字化、多智能体或 ERP 的 AI 化欢迎一起交流思路。建议标签Microsoft Agent FrameworkMAF.NETDeepSeek多智能体数字人大模型OracleERPChatClientAgent 深入解析 AxiomOffice：基于 MAF + DeepSeek + Three.js +Pinia 虚拟办公室对接鼎捷 TIPTOP
深入解析 AxiomOffice基于 MAF DeepSeek Three.js Pinia 虚拟办公室对接鼎捷 TIPTOP摘要本文完整记录了一个「数字人虚拟办公室」从业务规划到技术落地的全过程。针对制造业销售客服中心「接单 → 跟单 → 排产 → 发货」四条业务链作者将跟单员、PMC、物流客服、客服经理四个岗位做成 AI 数字人基于微软官方 Agent 框架MAF编排多智能体协作用 Three.js 构建 3D 可视化办公室让协作过程「看得见」并真实打通鼎捷 TIPTOP 生产 ERP。方案重点解决了「自然语言 → 系统编码」的实体解析难题通过配置化能力层实现对接新系统只改配置不改代码同时以读写分离、本地私有部署守住数据安全底线。全文附真实可跑的 .NET 10 Vue3 代码为制造业数字化、多智能体与 ERP 的 AI 化落地提供了一套可复用的完整参考。目录业务背景与痛点方案核心设计整体架构项目结构关键实现5.1 数字人可视化让协作「看得见」5.2 角色化多智能体用 MAF 而非自造5.3 跨岗位协作流程5.4 ERP 实体解析落地最关键的一环5.5 配置化能力层安全与合规考量复盘与总结一、业务背景与痛点制造业的销售客服中心核心业务就四条链接单 → 跟单 → 排产 → 发货对应跟单员、PMC、物流客服、客服经理四个岗位。传统的运转方式依赖微信群和 Excel 流转我在梳理需求时发现了三个典型问题1.信息割裂订单在 ERP 里、进度靠打电话、交期靠经验缺乏一个统一的「现在到哪一步了」的视图。2.重复劳动大量「帮我查一下订单进度」「客户编码是多少」这类高频低价值的重复查询。3.落地门槛AI 要真正帮上忙就必须和 ERP 打通——而「用户说客户名系统要客户编码」这层转换是很多人没想清楚、也最容易翻车的地方。基于这三点我设计的解决方案是把四个岗位做成数字人多智能体让它们在一个可视化办公室里自动协作并真实对接生产 ERP。—二、方案核心设计方案里有几个我认为最关键的设计决策设计解决什么问题 数字人可视化多智能体协作「看得见」谁在干活一目了然而不是干巴巴的对话 用微软官方 Agent 框架站在 MAFMicrosoft.Agents.AI上不重复造 agent 轮子 真实 ERP 打通读真实主档、解析真实编码验证方案在真实业务里跑得通 实体解析自然语言 → 系统编码AI 落地 ERP 的关键一环 配置化能力层对接不同业务系统只改配置不改代码 读写分离生产库只读写操作走受控接口守住数据安全底线三、整体架构技术栈层技术AI 编排Microsoft Agent FrameworkMAFMicrosoft.Agents.AI1.6.1大模型DeepSeekOpenAI 兼容IChatClient抽象可替换后端.NET 10 Web API SignalR前端Vue3 Vite Pinia Three.jsERP鼎捷 TIPTOPOracle交互层 Vue3 Three.js 数字人办公室SignalR 实时↓编排层 MAF ChatClientAgent ×4 编排器路由/流程/状态机↓能力层 配置化 HTTP 接口 只读 SQL 查询↓数据层 鼎捷 TIPTOPOracle**设计考量**分层实现彻底解耦——Ai/ 只管模型与 AgentCore/ 管编排与业务前端只管呈现。这样方案里的编排层将来可以直接复用进中台/ESB不会和具体业务绑定死。 csharp axiom-office/ ├── backend/PixelOffice.Api/ # .NET 10 Web API │ ├── Program.cs # DI SignalR 配置加载 │ ├── agents.config.json # 团队 / 流程 / 技能 / 快捷模板 │ ├── tools.config.json # 能力接口 / 只读 SQL / 数据库连接 │ ├── Controllers/ # Task / Agent / Business / Skill / Tool │ ├── Hubs/OfficeHub.cs # SignalR 实时推送 │ ├── Ai/ │ │ ├── MafChatClient.cs # IChatClient ChatClientAgent 工厂 │ │ └── MafAgentRunner.cs # 角色化 agent 流式执行 │ ├── Core/ │ │ ├── AgentOrchestrator.cs # 编排器 数字人状态机 协作流程 │ │ ├── ToolRegistry.cs # 配置化能力层动态构建 AIFunction │ │ ├── BusinessConfig.cs # 业务配置解析 写回 │ │ └── BusinessDataService.cs # 业务数据 实体解析 │ └── Models/ └── frontend/ ├── src/components/ # Office3D / PixelOffice / ChatPanel / ConfigModal... ├── src/store/office.ts # Pinia 全局状态 └── src/api/client.ts # REST SignalR 客户端五、关键实现5.1 数字人可视化让协作「看得见」设计考量市面上大多数多智能体系统只有一堆对话气泡用户根本看不到「现在谁在干活、干到哪一步了」。我在方案里加入了一个 3D 办公室让协作过程可视化——这是让非技术用户也能直观理解「多智能体在协作」的关键。实现每个数字人有一套行为状态机由后端编排器驱动、前端 Three.js 插值动画呈现publicenumAgentStatus{Idle0,// 坐工位待命Walking1,// 走动Thinking2,// 思考Working3,// 工作打字Overloaded4,// 过载Break5// 休息站立}数字人默认坐工位并会定时起身去休息区活动再回来。状态机由后端驱动、前端呈现业务编排和呈现彻底解耦——这是能持续扩展更多数字人的基础。5.2 角色化多智能体用 MAF 而非自造设计考量与其自己实现 agent 循环、工具调用、多轮对话不如站在微软官方的 Agent 框架上。MAF 的ChatClientAgent把「角色 指令 工具 agentic loop」都封装好了模型还能通过IChatClient抽象热替换。实现模型层用IChatClient隔离publicstaticIChatClientCreateDeepSeekChatClient(IConfigurationconfiguration){varsectionconfiguration.GetSection(DeepSeek);varopenAiClientnewOpenAIClient(newApiKeyCredential(section[ApiKey]),newOpenAIClientOptions{EndpointnewUri(section[BaseUrl])});returnopenAiClient.GetChatClient(section[Model]).AsIChatClient();// OpenAI SDK → IChatClient}角色化 Agent 流式varagent_chatClient.AsAIAgent(newChatClientAgentOptions{NameagentName,// 如「跟单员」DescriptionagentName,ChatOptionsnewChatOptions{InstructionssystemPrompt,// 岗位职责提示词Toolstools.Select(t(AITool)t).ToList()// 该岗位的能力集}});varsbnewStringBuilder();awaitforeach(varupdateinagent.RunStreamingAsync(messages,null,null,ct))if(update.Textis{Length:0}delta){sb.Append(delta);onDelta(delta);}// 打字机ChatClientAgent内部自动完成「模型 → 工具调用 → 模型 → …」的 agentic loop不用手写。5.3 跨岗位协作流程设计考量客服中心的业务是「链式」的——接单后要排产排产后要发货。我把这些链做成可配置的流程命中触发词即启动上一步结果自动作为下一步上下文。订单交付全流程跟单员接单 → PMC 排产下达 → 物流装车交付 交期催办 跟单员核实进度 → PMC 确认产线进度 交期答复 跟单员接询问 → PMC 确认进度与交期 → 跟单员回复客户实现——上一步的产出自动拼成下一步的上下文privateasyncTaskAdvanceFlowAsync(TaskItemcompleted){if(string.IsNullOrEmpty(completed.FlowId))return;varflow_flows.FirstOrDefault(ff.Idcompleted.FlowId);varnextIndexcompleted.StepIndex!.Value1;if(nextIndexflow.Steps.Count)return;varstepflow.Steps[nextIndex];// 交接上下文 前面所有已完成步骤的结果拼接varhandoffstring.Join(\n\n,flowTasks.Where(tt.StepIndexnextIndext.StatusDone).OrderBy(tt.StepIndex).Select(t$【{t.AssigneeName}】{t.Result}));Enqueue(newTaskItem{StepIndexnextIndex,PromptFillPrompt(step.Prompt,request,handoff)},step.AgentId);}一个取舍这里保留手写流程而不是用 MAF 的AgentWorkflowBuilder黑盒执行——因为这层流程同时承担「数字人动画驱动」的职责黑盒化会丢掉逐步骤的动画控制。5.4 ERP 实体解析落地最关键的一环设计考量这是「AI 落地 ERP」里最容易被忽略、也最关键的问题——用户说「恒源顺科技」ERP 建单要的是客户编码。大模型不能「猜」编码必须查主档。我用了三层漏斗三层漏斗自然语言「恒源顺科技」 ↓ ① 召回调 query_customer 模糊查主档 候选 [1601113005 恒源顺科技-田继中, A51040007 攀枝花市恒源顺科技] ↓ ② 精排大模型读候选选最匹配歧义则列出 ↓ ③ 确认回显给用户确认再拿编码建单实现——能力由配置动态构建成 MAF 的AIFunctionMEAI 的AIFunctionFactory不支持自定义 JSON Schema故自实现AIFunction子类privatesealedclassConfigTool:AIFunction{privatereadonlyFuncIReadOnlyDictionarystring,object?,CancellationToken,Taskobject?_invoke;publicConfigTool(stringname,string?description,JsonElementjsonSchema,FuncIReadOnlyDictionarystring,object?,CancellationToken,Taskobject?invoke){Namename;Descriptiondescription??;JsonSchemajsonSchema;_invokeinvoke;}publicoverridestringName{get;}publicoverridestringDescription{get;}publicoverrideJsonElementJsonSchema{get;}protectedoverrideasyncValueTaskobject?InvokeCoreAsync(AIFunctionArgumentsarguments,CancellationTokencancellationTokendefault){vardictnewDictionarystring,object?();foreach(varkvinarguments)dict[kv.Key]ToScalar(kv.Value);returnawait_invoke(dict,cancellationToken);// 执行 HTTP / SQL}}读写分离读走只读 SQL生产库默认只读写走受控 WebAPI避免裸写生产库。{dbQueries:[{name:query_customer,description:按客户名称模糊查找客户编码,sql:SELECT occ01 AS customer_code, occ02 AS customer_name FROM occ_file WHERE occ02 LIKE %||:keyword||%,roles:[order-clerk],parameters:[{name:keyword,type:string,required:true}]}]}实测问「恒源顺科技」返回两条真实客户并让用户确认1601113005 xxx科技-田田中、A51040007 攀枝花市xxx科技。5.5 配置化能力层设计考量一个方案能不能复用、能不能对接更多业务系统取决于「改配置」还是「改代码」。我把对接能力做成了配置化——对接新系统只加配置不改代码这是从「一次性项目」到「可复用方案」的分水岭。配置项说明团队管理岗位名/职责/提示词/图标/颜色/工位坐标可增删岗位流程管理流程名/触发词/步骤链可增删流程和步骤可运行测试AI 技能管理技能名/图标/所属岗位/描述/启停能力中心HTTP 接口 只读 SQL 查询 数据库连接虚拟团队管理数字人团队 快捷派单模板—六、安全与合规考量做企业级方案安全是不能省的底线本地私有部署整套系统部署在本地/内网不依赖公有云。数据不上传业务数据全程本地流转不上传任何第三方 AI 平台。️ERP 只读生产库默认只读写操作走受控接口。模型可替换大模型通过IChatClient抽象接入可换私有化模型。七、复盘与总结这套方案走下来有三点我认为1.用成熟框架不重复造轮子MAF 的IChatClientChatClientAgent 流式 配置化工具覆盖了多智能体 90% 的需求。2.把「业务编排」和「可视化呈现」解耦数字人状态机独立驱动动画两边各自演进、互不拖累。3.AI 落地 ERP先解决「实体解析」自然语言到系统编码这层转换不解决后面所有「自动建单」都是空中楼阁。都是空中楼阁。这套方案从需求分析、方案设计到技术实现和 ERP 落地完整跑通了一条链路。如果你也在做制造业数字化、多智能体或 ERP 的 AI 化欢迎一起交流思路。建议标签Microsoft Agent FrameworkMAF.NETDeepSeek多智能体数字人大模型OracleERPChatClientAgent