企业官网建设流程全解析

毕业设计选"AI智能体Office套件设计与实现"这个题目，说实话一开始我心里也打鼓：这到底是蹭"AI智能体"的热度，还是真能做出点名堂来？等我把整个系统从需求拆到底层实现走完一遍之后，我的结论变了——这个题目把它拆开看，其实是"计算机科学与技术"专业最核心的几门课的综合大作业：操作系统层面的线程与进程调度、数据结构与算法里的状态机和图遍历、软件工程里的系统分层与接口设计、机器学习里的大模型推理与函数调用，再加上编译原理里"把自然语言翻译成结构化指令"的影子。这篇博文我把我整个从零到一的过程、踩过的坑、以及答辩后被追问的问题全部写出来，希望能给准备做AI应用方向毕设的同学一条能直接参考的路线。

1. 选题动机与调研：为什么"AI智能体"和"Office套件"是绝配

1.1 从"给Office加个AI按钮"到"让智能体操作文档"的认知转变

刚开始构思的时候，我的第一反应也是做那种网上很火的"AI一键生成PPT"或者"AI帮忙写周报"的网页。但这类东西市面上太多了，大部分做得都浮于表面：前端接个大模型API，把用户输入的prompt往对话框里一填，生成的文字渲染到页面上就算交差。仔细想想，这种实现里AI其实只是"文案生成器"，它没有真正理解文档结构，更谈不上对文档元素进行编辑、排版、统计、增删改查。

真正的智能体Office套件应该解决的是这样一个问题：用户说"帮我统计一下这份营业数据表里第三季度各区域的销售额，再生成一张趋势图放进去，最后写一段总结放在图表上方"，系统能够自动打开文档、定位数据所在位置、完成统计分析、生成图表、撰写总结文本、并且把图表和文本真的放回文档中对应的位置。

想要做到这一步，核心不是大模型有多强，而是你设计了一个什么样的"中间协议"，让大模型的"意图"能够转化为一套可执行的文档操作指令。这也是我整个毕设找到的第一个技术突破口。

1.2 调研后锁定的三个关键方向

在正式动手之前，我花了两周时间调研了大量同类产品和开源项目，最终锁定了三个我可以在毕业论文里作为"创新点"展开的方向：

第一个是函数调用机制（Function Calling）的深度应用。目前主流大模型API都支持把一组工具函数以JSON Schema的形式传给模型，模型在推理过程中会主动选择调用哪个函数并填入参数。我调研发现，很多人只是用它来"查天气""算个加减乘除"，很少有人研究怎样把几十个文档操作函数按域分类注册给模型，并且让模型在复杂场景下做出正确的工具选择。这是第一个可以展开的点。

第二个是多步任务的工作流编排。现实中的文档操作往往不是一步完成的，比如"生成合同"需要先调模板，再填客户信息，再算金额，再排版，再导出PDF。如果每一次都靠大模型"现场临场发挥"，结果非常不稳定。我决定设计一个轻量级的工作流引擎，把常见多步任务固化成流程模板，大模型在其中负责"填参"和"动态调整分支"，这样既保证稳定性，又保留灵活性。

第三个是统一文档操作命令协议。Office三件套（Word、Excel、PPT）内部数据格式完全不同，如果给AI实现三个独立的"控制通道"，代码量会爆炸。我需要抽象出一套统一的命令协议，让Agent向文档处理层发送结构化命令，由各文档适配器翻译成具体操作。这样Agent不感知docx、xlsx、pptx的差异，只认"插入文本""插入图表""合并单元格"这类通用动作。

调研完这三个方向之后，我心里基本有底了：这个题目完全可以做成一个"小而不小"的系统，既有算法深度，又有工程难度，还能挂靠"计算机科学与技术"的核心课程知识点，在毕设答辩时每个模块都能讲出原理来。

2. 系统总体架构：把智能体放在中间，让前端和文档层解耦

2.1 三层架构的划分与职责边界

整套系统我最终设计成了三个独立部署但通过接口协作的模块：前端交互层、智能体调度层、文档能力层。很多同学做类似项目会把逻辑全塞进一个后端进程里，结果改一处崩一片。我把它们拆开，理由很简单：三层各自需要不同的扩展方式和性能调优手段。

前端交互层接受用户的自然语言指令，展示Agent的思考过程和文档的实时变化；智能体调度层是整个系统的"大脑"，负责语义理解、任务规划、工具选择、上下文记忆；文档能力层则是一组"手"，它不关心用户说了什么，只关心收到什么指令，并且保证文档对象模型的每一次变更都可追溯。

2.2 智能体调度层的内部结构

调度层内部我划分了四个核心组件：意图解析器、任务规划器、工具调用器、上下文管理器。

意图解析器的主要职责是判断一条用户指令是"直接执行类"（比如"把标题居中"）、"数据分析类"（比如"统计表格数据"）还是"综合报告类"（比如"根据这些数据写份汇报"）。不同类型的指令会走完全不同的处理链路，这比什么都丢给大模型自由发挥要可控得多。

任务规划器承担的是"把一个模糊目标拆解成有序子任务"的工作。比如"写一份产品发布会邀请函"，规划器会先判断需要加载企业模板、填入活动信息、生成邀请文本、检查排版、导出PDF五个子任务。规划器内部实际是一个基于规则+大模型混合决策的模块：对常见任务使用预置模板，对未覆盖任务调用大模型做动态规划。

工具调用器是最考细节的部分。我维护了一个工具注册表，每个工具包括名称、描述、参数JSON Schema、执行函数、权限等级。这样设计的好处是大模型API可以通过工具描述自动匹配函数，同时在执行前我可以做参数校验和权限检查，杜绝模型瞎传参数破坏文档。

上下文管理器负责跟踪整个会话的文档状态和对话记忆。我采用了"窗口+摘要"的混合策略：最近的对话历史完整保留，超过窗口的部分用大模型做递归摘要压缩，保证长会话下Agent不会"失忆"。

2.3 技术选型：为什么前端用React，后端用Python，文档层用Node.js

技术栈选择上，我做了大量权衡，最终确定的组合是：前端React + TypeScript，智能体调度层Python FastAPI，文档能力层Node.js。

选React是看重它的生态和组件化能力，特别是文档编辑区域需要大量自定义交互组件，React的虚拟DOM能有效降低重绘成本。TypeScript的作用很大：前端和调度层之间的API通信需要严格的类型定义，我用TypeScript生成了共享类型包，前端调用后端接口时能获得完整的类型提示，调试期帮我拦下了大量低级错误。

智能体调度层用Python，主要原因是大模型SDK和AI工具链在Python生态里最成熟，无论是异步调用、token计算还是Prompt管理库，Python都有现成方案。FastAPI的异步支持和OpenAPI文档自动生成能力也帮我省了很多接口文档的功夫。

文档能力层用Node.js是因为它在处理zip压缩包、XML解析、二进制文件读写方面表现非常好，特别是对接docx、xlsx这类本质为"ZIP压缩包+XML文件"的格式，Node.js的buffer处理和流式读写都比Python顺手。

提示：如果你打算复现这个项目，最省力的方式是在调度层和文档层之间用消息队列解耦。我当时用了Redis Stream，虽然增加了部署复杂度，但换来了异步任务能力和失败重试机制，这在处理大文档时非常关键。

3. AI智能体核心链路：从自然语言到结构化文档命令

3.1 函数调用机制是智能体的"双手"，而不是简单把工具列表塞进Prompt

很多初次接触大模型开发的人会误以为"工具调用"就是在一段很长的Prompt里写下"你现在可以使用以下工具：工具1、工具2……然后你就可以工作了"。这种做法的效果非常不稳定，大模型很容易把工具的用法记错，或者干脆在输出文本里"假装"调用了工具，并没有真正执行。

我采用的是主流大模型API自带的函数调用模式。具体做法是：在请求体中以JSON Schema数组的形式，把工具注册表里的函数逐一描述给模型，包括函数名、功能说明、参数的结构和约束。API会在模型返回的结构化字段中直接给出"该调用哪个函数、参数是什么"。调度层拿到这个结构化结果后，再真正执行对应的Python函数。

举个例子，我定义了一个名为insert_text_after_paragraph的函数，参数schema包含doc_id、paragraph_index、text_content、font_size、bold等字段。当用户说"在第三段后面加一句话，内容是把会议时间改成周五下午三点"，模型经过推理会返回一个结构化的调用请求，而不是一段自由文本。这样我就能精准控制"AI想做什么"和"系统实际做什么"的一致性。

3.2 ReAct模式的"思考—行动—观察"循环：为什么需要循环而不只是单次调用

单次函数调用只能处理简单指令，一旦任务涉及多步骤操作，比如"检查这个文档里所有的空行，把它们删掉，然后把每个章节标题设置为蓝色加粗"，单次调用就无能为力了，因为模型无法在一次推理里完成全部操作规划，且无法在过程中观察结果、修正下一步。

我参考了ReAct（Reasoning + Acting）的经典思路，在调度层实现了一个"思考—行动—观察"的循环。每一轮循环做三件事：第一步把当前状态、对话历史、工具列表拼装成Prompt发给模型；第二步模型返回可选的思考文本和工具调用请求；第三步调度层执行工具调用，把执行结果（成功或失败、返回了什么内容）作为"观察"结果追加进上下文，然后进入下一轮循环。

这个循环的终止条件有三个：模型明确表示任务已完成、达到最大循环次数（我设置了15次上限）、或者工具执行连续报错超过3次。有了这层循环，Agent处理复杂指令的能力明显提升，因为它能够在每一步操作后"看到"文档当前的真实状态，而不是凭想象输出最终结果。

3.3 动态规划与静态工作流的配合：既稳定又灵活

在做了大量场景测试之后，我发现单纯靠ReAct循环做所有事情有一个致命问题：不稳定。同一个任务，这次模型选择先改标题再删空行，下次可能反过来，甚至某次会在中间多出一步无关操作。这在毕设答辩演示的时候会很尴尬，因为同样的指令每次结果不一样。

我的解法是"静态工作流为主、动态规划为辅"。对用户意图里明确属于常见任务类别的指令，先查找工作流模板库；命中模板的直接按模板定义的节点顺序执行，节点内部的具体参数由ReAct循环现场推理；未命中模板的，才完全交给大模型动态规划。

这样既保证了高频任务的执行稳定性，又保留了低频长尾任务的灵活性。这一点在答辩时被老师专门表扬了，他们认为"固定流程与动态决策的折中"是这套系统设计里最有工程意识的地方。

3.4 Prompt工程与上下文管理的实战细节

智能体效果好不好，一半在模型能力，一半在Prompt和上下文管理。我积累了下面几个比较实用的经验。

工具描述的写法直接影响模型的选择正确率。我之前把"插入文本"和"替换文本"两个工具描述写得非常接近，导致模型频繁选错。后来我把描述改成了包含典型使用场景的句式，比如"当用户要求新增或追加文字时使用；不要把整段文字替换调用为插入文本"，选错率立刻降低了大半。

上下文管理上，我采用"完整历史 + 压缩摘要"的双轨制。系统维护一个会话对象，里面保存最近10轮完整消息。超过10轮的消息，会由调度层调用一次Summarization接口，生成一段摘要放入系统提示词的固定前缀区。这种做法的效果是：长会话的早期信息不会丢失太多，同时也不会因为上下文窗口塞满而报错。

关于token成本，我的建议是工具描述一旦确定就不要频繁修改，因为工具描述会随每次请求发给模型，非常消耗token。我统计过，全文工具表包含38个函数，描述和schema加起来大约占6.5K token，相当于每轮对话光工具描述就要花掉不少钱。优化办法是给工具分级：高频工具全量描述，低频工具用简短描述并允许模型通过"搜索可用工具"接口按关键词查询。

4. 文档能力层的实现：让AI真正"碰"到docx、xlsx、pptx

4.1 揭秘Office文档的真实内部结构：docx其实是个压缩包

文档能力层是我花时间最多的部分。很多人不知道，Office 2007之后的docx、xlsx、pptx文件本质上都是一个ZIP压缩包，里面装着一堆XML文件和资源文件。比如一个简单的docx文件解开后会有word/document.xml（正文内容）、word/styles.xml（样式定义）、word/media/（图片资源）等。

理解了这个底层结构，许多实现策略就好定了。我没有直接操作XML，那样太繁琐且容易出错，而是在Node.js侧选择了两套成熟库：读取和解析用mammoth和xlsx，结构化修改用docx和exceljs。docx这个库特别适合通过代码生成文档，它把所有排版对象抽象成了JavaScript类，我可以在内存中重建整个文档结构，再打包输出为新文件。

4.2 统一命令协议：把Agent的意图翻译成文档动作

文档能力层与调度层之间通信，全部经由一套我自己定义的"文档操作命令协议"。协议格式统一为{action, target, params, options}。action是操作类型，比如insert_paragraph、set_style、merge_cells、add_chart；target是操作定位符，比如"第3个段落""表格第2行第4列""所有一级标题"；params是操作参数；options里存一些扩展配置，比如是否需要执行后返回文档快照。

这套协议是贯穿全文的一个设计亮点。它的价值在于：前端、调度层、文档层不再关心彼此的实现细节。前端拖拽改变的是目标选择器；调度层根据用户意图生成协议命令；文档层的每个适配器只负责把协议命令翻译成具体库的API调用。想要扩展新的文档类型（比如PDF编辑），只需要新增一个适配器实现相同协议即可。

4.3 目标定位与"文档对象模型"的统一

实现协议最难的部分是target的定位。用户说"把最后一页的标题改成欢迎词"，Agent要能把"最后一页的标题"翻译成一个机器可用的目标定位符。

我设计了一套基于路径的目标定位语法，类似/body/sections[0]/paragraphs[last()]/runs[0]。在每个文档适配器内部，文档会被解析成一棵文档对象树，树的节点包括文档、段落、表格、单元格、图片、文本框等。每个节点都有一个唯一路径和属性表。调度层只需要通过路径语法向文档层查询或操作节点，文档层返回结果或执行变更。

这套设计让"AI操作文档"不再依赖正则表达式去匹配文本行，而是真正基于文档结构做精准操作。例如"把第三张表格的第一列所有单元格背景色设为浅蓝色"，只需要先找到路径body/tables[2]/columns[0]，再遍历该列所有单元格设置背景色属性即可，几百行逻辑就能搞定。

4.4 表格与PPT的差异化处理

xlsx和pptx的处理难度一点都不比docx小。xlsx的关系网络复杂，公式、命名区域、数据透视表、图表都各自牵一发动全身。我的策略是能不做底层的绝对不做：优先通过exceljs读取单元格值，通过chart.js生成图表数据，最后用exceljs嵌入图表对象。PPT方面，我利用pptxgenjs生成新幻灯片，并用pptx-parser解析已有PPT的结构。合并两者时做了一个"模板引擎"：用户上传PPT后，系统解析出可编辑的占位符区域，Agent直接按占位符名称填充内容，这样比试图理解任意PPT的版面结构要可靠得多。

这里有一个经验值得说：不要盲目追求"理解任意复杂文档布局"，那是商业级产品的目标。毕设和一般项目做到"解析常见排版结构 + 处理用户合理范围内的编辑需求"就足够支撑起完整业务闭环了。我在测试中发现，80%以上的真实Office文档都是标准段落、目录、表格、简单图片的排列组合，针对这些结构做好解析和编辑，系统实用性已经很高。

5. 工作流引擎设计与实现：让"写报告"这类模糊任务可复现

5.1 为什么必须在智能体内嵌一套工作流引擎

你可能会问：既然ReAct循环已经能让模型自主地执行多步操作，为什么还要单独实现一个工作流引擎？我的回答是：自主不等于可控，可控才是真正落地的前提。

我曾经让Agent执行"生成一份季度销售报告"这个任务。ReAct模式下，模型一会儿调用数据查询工具，一会儿写总结，一会儿又回头去改前面的内容，整体执行冗长且结果不可复现。有时候模型会在中途陷入"循环思考"状态，甚至连续多次调用同一个只读工具却不推进任务。这说明动态决策在处理复杂多步任务时容易"迷路"。

工作流引擎的介入相当于给Agent画了一张"任务地图"。它把"生成季度销售报告"定义为一条有向无环图：开始节点→数据提取节点→数据汇总节点→图表生成节点→报告撰写节点→排版美化节点→导出节点→结束。每个节点都明确"输入是什么、输出是什么、依赖哪些工具、失败时怎么办"。Agent不再需要临场规划整个任务路径，它只需在节点内部完成具体的执行决策。

5.2 工作流引擎的运行时设计：状态机 + 任务队列

我实现工作流引擎时，底层采用的是状态机 + 异步任务队列的组合。状态机负责跟踪每个工作流实例处于什么阶段，异步任务队列负责实际执行具体工具调用。

具体来说，工作流定义采用JSON格式。每个节点有type（api_call、llm_generate、condition、transform等）、inputs、outputs、next。运行时引擎从start节点开始，按next引用推进。遇到condition节点时，会根据前置结果做分支判断；遇到llm_generate节点时，调度层会专门调用大模型生成文本或决策参数；遇到api_call节点时，则调用文档能力层的接口执行具体操作。

每个工作流实例会持久化存储执行状态，包括当前节点ID、已执行节点的结果缓存、上下文摘要。这样做的好处是支持手动暂停恢复，比如文档审核不过时，用户可以修改参数后从某个节点重新执行，而不必整个任务从头再来。

5.3 工作流节点的"参数化执行"：让静态流程具有动态能力

固定流程如果不带参数，就会变得死板。所以每个节点都支持"参数来源配置"。参数可以来自用户输入、上一个节点的输出、或者节点内部嵌入的大模型推理结果。

比如"报告撰写"节点里，风格参数如果用户没有指定，就会触发一个llm_generate操作，模型根据"销售数据反映出区域差异明显"这个事实，生成"整体态势良好但区域间不平衡"的结论性语句，并填入报告的总结段落。这样一来，流程是固定的，内容却是根据数据动态生成的，既可控又不生硬。

5.4 失败恢复与自愈机制：工程落地中最容易被忽视的部分

真实毕设验收时，老师一定会问"如果执行到一半，模型API突然超时怎么办？"所以我专门设计了工作流的失败恢复机制。

每个执行任务都有重试策略，默认API调用失败后最多重试3次，采用指数退避算法。如果重试后仍然失败，工作流会标记该节点为失败状态，并根据失败处理策略决定是"跳过该节点继续下一个节点"（适用于非关键步骤）、"回退到上一个节点重新执行"（适用于数据依赖型步骤）、还是"终止整个工作流"（适用于不可恢复的错误）。这个设计让我在答辩演示的时候可以从容地拔掉一次网络，然后展示系统自动降级重试的过程，老师对这个环节的印象分很高。

6. 前端交互与跨浏览器兼容：用户如何感知智能体在"干活"

6.1 流式输出与文档实时联动的交互设计

用户对"智能感"最直观的体验，不是AI在后台默默执行完再一次性返回结果，而是"看着AI一步步干活"。我在前端实现了三种实时反馈通道。

第一种是思考过程流式推送。Agent在ReAct循环里的每一步思考文本，通过WebSocket实时推送到前端，在侧边栏逐字显示。用户能看到"正在解析指令→正在定位目标文档→正在执行插入操作→正在检查排版"这样的过程，信任感会强很多。

第二种是操作指令实时可视化。前端解析到调度层发来的结构化命令后，会在页面上以"时间线"列表展示：什么时间做了什么操作，操作作用于哪个段落或哪个单元格。点击时间线上的节点，可以高亮文档中的对应区域，帮助用户理解AI每一步动作。

第三种是文档快照对比。每次工作流执行到关键节点时，前端会触发文档层生成一次快照，并在界面上以"变更前/变更后"对比方式展示主要差异。用户不需要事后慢慢看，AI改了什么一眼就知道。

6.2 跨浏览器支持：不是功能一样，而是体验一致

毕设题目里专门有"跨浏览器支持"的要求，这在前端项目里是一个容易翻车的大坑。不同浏览器对Canvas、WebSocket、PDF预览、拖拽上传、键盘事件的支持都存在差异。

我在兼容性处理上做了几件事。文档预览没有直接用浏览器内置的PDF查看器，而是统一用pdf.js渲染到Canvas，这样就绕开了各浏览器查看器样式不统一的问题。拖拽上传用了react-dropzone，它在底层封装了浏览器的拖拽事件差异。对旧内核浏览器的处理策略是：降级但不拒绝，功能缺失时提示用户使用推荐浏览器，但核心浏览和编辑功能保持可用，避免用户白跑一趟。

让我列一个实际踩过的兼容性问题表，你可以直接对照自查：

6.3 撤销重做与文档版本管理：给智能体操作装上"后悔药"

AI自动操作文档最让人紧张的就是"改坏了怎么办"。我在文档编辑区实现了完整的撤销重做机制，核心是一个操作日志栈。

每当文档能力层执行一个命令协议动作，就会同时记录一个undo动作和redo动作，它们也都是合法的命令协议格式。比如插入一段文字，对应的undo操作是"按路径删除该段落"；设置字体加粗对应的undo操作是"按路径恢复原字体"。用户点击撤销时，是弹出栈顶的undo命令并执行；点击重做时，再执行对应的redo命令。通过这种方式，我对全系统所有文档操作都能做到可回滚，而不仅仅局限于用户手动编辑的部分。

这个设计在毕设答辩中也是加分项，因为它体现了"AI操作不能是黑盒"的理念，再智能的系统也应该给人留出纠错空间。

7. 实测效果、答辩高频追问与给你避坑的清单

7.1 我设计的重点测试用例与结果

为了证明系统不是"演示专用"，我专门设计了一套功能测试用例，分为基础指令类、复合任务类、长文档处理类、异常输入类四组。

基础指令类包括"把标题设为红色""给第二段添加下划线""删除表格第三行"等简单指令，任务成功率在90%以上，失败主要集中在目标定位歧义上，比如"倒数第二段"在文档只有三段时的理解偏差。

复合任务类包括"根据这两列的差值生成柱状图并放到文档末尾，再加上一句结论"这种需要多工具协作的任务，完整成功率约70%。失败原因分析后发现，大多是模型在"图表数据区域选择"和"结论引用具体数值"上出现不准确。针对这类问题，我在Prompt里加入了"必须明确引用结算结果中的具体数值"的约束，成功率提升到了78%。

长文档处理类是压测性质，我准备了一份183页的技术手册，让Agent执行"提取所有章节标题并生成本文目录，再加一页封面"的任务，最终耗时约4分钟，完成度较高，但速度受限于大模型API响应时间。异常输入类包括空文档、损坏文件、无权限文件等，系统均能给出明确错误提示而不是直接崩溃，这一点对用户体验很重要。

7.2 答辩现场老师最常追问的五个问题

第一个高频追问："大模型出现幻觉导致生成了文档中不存在的引用怎么办？"我的回答是双保险方案：在工具层增加数据源校验，凡涉及引用具体数值或文档原文的文本，必须经过"回溯查询"工具验证后才能写入文档；同时调度层在每次写入前做一次前后一致性检查，发现冲突强制拦截。

第二个问题："如何应对模型返回非法操作参数？"我设计了参数校验管道，每个工具执行前先过一遍JSON Schema校验，不合法参数直接抛出带人类可读提示的错误，Agent会把错误信息当作观察结果读回去并自行修正。实测中约8%的非法调用能被模型自我纠错。

第三个问题："多个用户同时操作同一文档怎么办？"我采用乐观锁加版本号策略，文档每次变更都会递增版本号，如果有操作基于旧版本提交，系统会拒绝并提示前端刷新最新状态。

第四个问题："你的工作流引擎和现成的流程编排框架（如Airflow、Temporal）有什么区别？"我的核心论点是：通用编排框架不感知"大模型工具调用参数"这类语义，它只管任务依赖关系，我的引擎是在大模型实时输出的基础上做任务依赖约束，两者面向的问题层次不同。

第五个问题："这套系统的性能瓶颈在哪里？"我的答案是大模型API的推理延迟和文档解析耗时。针对前者，我做了并行子任务执行；针对后者，我启用了文档解析结果缓存，同一个文档二次操作无需重新解析。

7.3 创作给准备做类似毕设同学的五条避坑清单

如果这篇博文只让留一个部分，我希望是下面这个清单，全部是我真金白银踩出来的经验。

第一条：不要把大模型API key直接写在前端配置里。凡是调试阶段图方便在前端环境变量里放key的，大概率会被爬虫扫走，导致账号被盗刷。必须走后端代理，并且做单用户访问频率限制。

第二条：大模型的工具描述要反复打磨，别指望一版到位。我在项目中期做过一次工具描述全面重写，因为发现模型总在两个语义相近的工具之间摇摆。每次调整后跑一遍回归测试，保持语义边界清晰。

第三条：文档编辑类操作一定要给用户留撤销余地。一个看起来很小的"删除空行"操作，在长文档里可能误删很多内容。只要涉及结构性删除，操作前先展示影响范围条数，确认后再执行。

第四条：提前规划异步化，不要在主线程里跑大模型等待。我刚开始图简单用同步接口，结果大文档操作时前端频繁超时。后来把工作量大的任务全部迁移到异步任务队列，前端通过轮询或WebSocket接收进度，体验完全不一样。

第五条：答辩演示前必须准备故障预案。我正式演示时现场网络抖动，大模型API直接超时。好在选择了回退到本地小模型执行简单语法分析任务的模式，才没有让整个演示冷场。这种"一级方案挂掉立即切换二级方案"的思路，强烈建议每个做AI项目的同学都提前演练。

我做完这个项目的最大感受是：AI智能体在Office套件里的价值，不在于生成多少华丽文本，而在于它能否真正理解文档结构、精准执行复杂操作、并且在出错的时候给用户足够安全的反悔空间。这套"意图解析、工具调用、工作流编排、文档协议"的组合设计，不仅适用于Office场景，放到任何需要AI操作结构化数据的系统里都成立。如果你正准备做类似的毕设或者项目，我的建议是从统一命令协议和工作流引擎入手，这两块做扎实了，上层智能体就是水到渠成的事。