在计算机科学与技术的毕业设计里，AI智能体是最不缺热度、也最不缺同质化的方向。但"AI智能体+Office套件"这个组合，恰好把虚的智能体落到实的办公场景上——既沾了大模型和Agent的热点，又有完整的工程链路可以展开，从模型调用、工具设计到文档结构化处理，每一步都有技术含量，做出来也容易演示、容易讲清楚。我以这个课题为框架，把整个设计和实现过程完整梳理一遍，从需求拆解讲到架构选型，再到关键代码怎么组织、踩过哪些坑，一次性讲透。
1. 项目整体设计与需求拆解
1.1 这个项目到底要做什么
先说清楚这个项目的边界。Office套件在题目里不是指微软Office全家桶的完整替代品，而是聚焦在办公场景里最高频的几类文档处理需求：Word文档的生成和排版、Excel数据的读取与分析、PPT的自动创建，以及PDF内容的提取和转换。AI智能体则是以大模型为核心，通过意图识别、任务拆解、工具调用三步完成"人用自然语言描述需求，系统自动操作Office文档"的完整闭环。
举个例子，用户输入"帮我根据这个季度的销售数据，生成一份周报，包含数据趋势图和下阶段建议"，系统要先理解这句话里有三个子任务：读数据、做图、写报告。然后智能体把任务拆解成"调用Excel读取组件统计销售额环比"、"调用图表生成组件绘制柱状图"、"调用Word组件生成报告并插入图表"，最后输出一份可直接保存的docx文件。
从毕设的角度看，这类项目最大的优势在于：它不依赖某个特定领域的知识，而是提供了一个通用框架——把大模型的语义理解能力和传统程序的结构化处理能力通过"工具调用"这个机制缝合起来。无论模型本身能力如何，工具层的输出是确定的、可验证的，这就保证了整个系统的下限。
1.2 功能边界的划分方法
做这类项目最忌讳的就是"什么都想塞进去"。我见过很多同学把功能列表写成"智能写作、智能分析、智能排版、智能翻译、智能问答……"，最后每个功能都只做到demo级别，答辩时被问两句就露怯。正确的做法是按文档生命周期来切功能，保证每个模块都是完整可用的闭环。
我最终圈定的边界是四个核心模块：文档生成、数据洞察、演示文稿创建、文档理解转换。文档生成覆盖从Markdown文本到Word标准文档的转换，支持标题层级、表格、代码块、页眉页脚；数据洞察聚焦Excel数据的读取、聚合统计、趋势分析与图表生成；演示文稿创建实现从大纲文本到PPT的自动制作，每页对应一个主题块；文档理解转换支持PDF和Word的内容提取、摘要生成与格式互换。
每个模块再向下拆两级，就能得到具体的功能点列表，这些功能点就是后面编写"工具函数"的目录。一个工具函数对应一个可执行操作，这是Agent系统中"工具层"的最小单位，后面会详细讲。
1.3 为什么不能只用提示词硬编
很多初学者会觉得，既然大模型已经这么强了，是不是把需求直接丢给它，让它生成docx或pptx的代码就行？这个思路实践过就会发现非常不可控。原因有三个：第一，大模型生成的代码在复杂排版场景下会有概率性错误，要么缺样式定义，要么用了不存在的API；第二，模型上下文有限，处理大文件时经常截断，生成一半就断了；第三，大模型不擅长精确控制，比如"第2章从新一页开始"这种排版要求，语言模型经常理解不到位。
所以这个项目必须走"智能体+工具链"的路线：大模型只负责理解用户意图、拆解计划、决定下一步调用哪个工具，而真正操作文档的每一个动作都落在预先封装好的工具函数里。这样模型的错误就被限制在"规划层"，执行层是确定性代码，即使规划有偏差，工具层也会通过参数校验和数据验证把错误拦截下来。
这个设计的本质是把"AI生成"降级为"AI规划+程序执行"。规划允许有偏差，执行必须精确，两者结合才能得到既有智能感、又有稳定性的系统。这也是目前主流AI Agent产品的通用架构逻辑。
2. 核心架构设计与技术选型
2.1 系统整体架构分层
整个系统可以清晰地分成四层：交互层、智能体核心层、工具执行层、基础设施层。交互层负责接收用户输入和展示结果，我采用的是一个轻量级的Web界面，支持文本输入、文件上传和结果预览下载。智能体核心层是大脑，包含意图识别模块、任务规划模块、记忆管理模块和工具调度模块。这一层的核心维护一个"对话-计划-执行-观察"的循环：每次用户输入后，先判断意图，再生成一个包含多个步骤的计划，然后逐步执行，每次执行完一个工具，把返回的观察结果塞回上下文，再决定下一步做什么。
工具执行层是手臂，每一个工具函数独立封装，输入输出都有明确的JSON Schema定义。基础设施层包括文档处理库、大模型API客户端、向量存储和文件缓存。
这个分层对应到一个关键技术点：智能体循环中的"状态维护"。因为多个工具调用之间是有依赖关系的，比如先生成图表，再把图表路径传给Word工具，如果没有一个结构化的状态容器来保存中间产物，系统根本无法串联。我采用了一个简单的任务上下文对象来维护状态，这在后面的代码里会细化。
2.2 大模型选型：通用接口与备用策略
大模型选型是毕设里最现实的决策之一。如果只依赖某一家模型的服务，答辩演示时服务一旦不稳定，整个项目就瘫痪了。我的做法是抽象一层模型接口，最底层是OpenAI兼容的ChatCompletion格式，这样市面上主流模型只要改base_url和api_key就可以无缝切换。DeepSeek、通义千问、智谱、Kimi等国产模型都提供了兼容接口，成本和稳定性各有优势。
实际测试下来，我推荐把默认模型设置为DeepSeek-V3或V2.5这类性价比高的模型，原因有两个：一是上下文长度足够，跑Agent的完整链路（系统提示词+用户需求+工具描述+执行历史）一般会占到6k到12k token，容量小了直接崩；二是工具调用的输出格式稳定性好。在任务规划这种非创作型任务里，模型的指令遵循能力比文采重要得多。
这里有个经验之谈：必须实现一个模型降级逻辑。当主模型返回的不是可解析JSON时，自动切换备用模型重新请求一次。实测中大约2%-5%的请求会出现非JSON输出，自动重试加降级后，失败率可以降到千分之五以下。
2.3 文档操作引擎的底层封装
文档操作是本项目的技术底座，底层选型直接影响开发效率和产物质量。Word处理我用的是python-docx，它虽然不支持读取旧版doc格式，但所有生成类操作都非常稳定，而且样式控制相对直观。Excel处理用openpyxl，支持xlsx读写，特别适合做数据写入和图表插入。PPT用python-pptx，结构模型清晰：一个Presentation包含多页Slide，每页Slide通过layout和placeholder来安装内容。PDF解析用pdfplumber和PyMuPDF，前者负责表格抽取，后者负责文本块和坐标定位。
这一层最容易忽略的是样式设计。直接用默认样式生成的Word文档，看起来跟白纸加黑字一样，答辩展示时很吃亏。我提前定义了一套样式常量：正文用宋体小四、1.5倍行距；一级标题黑体三号加粗，段前段后各12磅；代码块用等宽字体加浅灰底纹。把这些样式封装成函数，调用时传样式枚举值即可。
这里有个细节值得展开：python-docx设置中文字体时，必须同时设置font.name和rFonts的eastAsia属性，否则中文字体不生效，出来的文档里中文仍然是默认宋体，而要求是黑体的标题就做不到。这个坑在项目推进时至少浪费了我半小时排查。
3. 智能体核心机制与工作流搭建
3.1 Agent循环：规划、执行、验证三步走
智能体核心是循环机制。我采用的框架是"Plan-Execute-Verify"，相比直接"生成-执行"，多了验证这一步。每轮循环里，模型先根据当前用户需求和处理进度生成一份JSON格式的计划，计划里包含并行的或者串行的工具调用序列。然后工具调度器逐个执行计划中的调用，执行完毕后收集每个调用返回的观察结果。最后把观察结果汇总进上下文，让模型判断任务是否已经完成，如果是就生成最终答复，否则修订计划继续循环。
这套机制里，Plan是关键。我在系统提示词中要求模型"一次只生成当前阶段需要的3-5个具体步骤，不要一口气规划全部"，因为实际运行中，前一步的结果往往会改变后续的处理策略。比如提取PDF时发现整页都是扫描图片，那就得切换到OCR工具，如果一开始就规划好调用文本抽取，就浪费了一轮。
Workflow的设计上，我借鉴了扣子（Coze）和Dify里的Agent工作流思路，把所有工具描述拼装进一个tools list，随每次请求一并发给模型。模型的回复中如果包含tool_calls字段，就说明它决定调用工具；如果包含的是普通文本，就说明它在向用户询问澄清信息或输出最终结果。这个判断逻辑看似简单，却是一切Agent系统的基础。
3.2 工具注册机制与函数调用的工程实现
工具层有一个核心设计模式：装饰器注册。每个工具函数通过@agent_tool.register装饰器把自己注册进一个全局注册表，装饰器内部把name、description、parameters_json_schema记录下来。这样新增一个工具只需要写一个函数加一个装饰器，工具注册表会自动更新。
每个工具函数都严格遵循"一个函数只做一类事"的原则。比如generate_chart接收data_series、chart_type、title三个参数，返回图表的本地文件路径。参数校验放在函数入口：数据类型检查、枚举值检查、数值范围检查，不合法直接抛出带明确错误信息的ToolExecutionError。这样即使模型传了错误的参数，工具层也能捕获，而不是把异常一路炸到前端。
函数调用的工程实现上，我维护了一个工具schema列表，每一项包含name、description和parameters。parameters遵循JSON Schema标准，描述每个参数的type、description、required、enum。发送模型请求时，这个列表被序列化进messages，模型才能知道有哪些工具可用。这些schema描述是整个Agent系统里"模型看到的世界"，它们的质量直接决定了模型使用工具的准确性。给参数写描述要坚持一个原则：写清楚参数的单位、边界、可选值，比如paragraph_count写成"段落数量，整数，范围1-20"，而不是简单写"段落数量"。
3.3 记忆管理与多轮交互
多轮交互场景下，最基础也是最有效的记忆管理是滑动窗口。设置一个MAX_HISTORY_TOKENS阈值，把历史消息按时间倒序累积，超过阈值就把最旧的对话裁掉。因为工具调用的中间产物体积较大，我额外维护了一个临时目录，所有生成的文件都放在这个目录下，并在会话结束时自动清理。
对于更复杂的跨会话需求，比如用户说"参考上次的周报格式"，就需要持久化的会话级记忆。我实现了一个简易方案：每次会话结束时，把用户需求、执行计划、关键参数和产物文件列表序列化成JSON，存到本地记忆库中。下次会话启动时，把所有历史会话的摘要和自动生成的标签一起注入上下文。大模型看到摘要后，就能回忆起"上次格式"的大致特征。
这个记忆方案不依赖向量数据库，在有几十个会话级别下效果已经够用。如果想做得更完善，可以把摘要文本做embedding存入向量库，按相似度召回最优的TOP3历史会话。但那是加分项，不是必需项，优先保证核心链路稳定更重要。
4. 核心模块的实操过程与实现细节
4.1 Word文档生成模块的完整实现路径
Word生成模块的用户输入一般是一段Markdown格式的内容，系统要做的是把Markdown结构化文本转换为带样式的docx文档。整体流程分五步：解析、骨架创建、内容写入、样式应用、保存输出。
解析阶段我使用了markdown-it派生的markdown_to_docx工具函数，它遍历Markdown的AST节点，按照节点类型分发到不同写入函数。遇到heading节点就调用add_heading并传递对应级别；遇到table节点就创建docx表格并逐行填充；遇到fence代码块节点就生成带底纹样式的段落块。
这里有一个值得分享的细节：图片的处理一定不能遗漏。很多同学生成Word时只处理文本，一碰到Markdown里的图片标记就跳过，最终文档里图片位置全是空白。我的工具函数支持两类图片来源：本地路径和URL。本地路径直接通过add_picture插入，URL则先用requests库下载到临时目录，再做一次格式校验（只允许jpg/png/gif），然后再插入。
为了满足"生成一份包含标题页、目录、正文的完整报告"这种复杂需求，我扩展了一个create_full_report工具，它接收标题、作者、日期、正文块列表四个参数。标题页通过添加空段落+大字号标题+居中对齐实现；目录则分为两种情况：如果有python-docx新版本支持的首段书签字段则自动插入域代码，否则就提示用户"按F9刷新目录"。这个边界说明在项目文档里要写清楚，否则演示时点击打开文档直接看到空目录，场面会很尴尬。
4.2 Excel数据分析与图表自动化生成的参数逻辑
Excel模块是整个项目中"确定性最强"的部分，也是最容易展示效果的部分。我实现了五个工具：读取表格区域、数据透视聚合、统计计算、趋势预测、图表生成。
读取表格区域使用openpyxl的load_workbook和Worksheet.iter_rows，返回的是List[Dict]类型，key是表头，value是单元格值。空值与异常值统一处理：空值填充为None，以便后续统计函数自行决定丢弃或补零。这里有一个好习惯：在工具描述里明确写"如果列中包含非数值内容，请先清理后再做统计"，引导模型在规划时主动调用数据清洗函数。
趋势预测我用的是简单线性回归和移动平均两种方法。移动平均直接pandasrolling(window=3).mean()就可以；线性回归手动实现y = ax + b，计算a和b的公式用最小二乘法。为什么要自己实现而不是调现成库？因为毕设项目里需要展示"我理解这个算法"，手写30行以内的最小二乘法完全在可控范围内，而且答辩时被问到原理能讲得很清楚。
图表生成我用matplotlib，所有图表统一设置plt.rcParams['font.sans-serif'] = ['SimHei', 'Microsoft YaHei']，这一步不做的话中文标签全是方框。图表配色用了一套固定的色板，避免每次模型自由发挥导致风格混乱。生成的文件统一保存为PNG格式，dpi设为150，插入Word里清晰度足够。
4.3 PPT自动生成：从大纲到成品的转换流程
PPT模块我设定了一个相对窄但足够实用的场景：根据用户提供的大纲，自动生成一套结构清晰、样式统一的演示文稿。用户输入可以是"我需要一个产品发布会的PPT，包含背景介绍、产品特性、市场分析、用户反馈、未来规划五个部分"。
实现上，工具函数generate_ppt接收大纲列表，每个大纲项包含title和content两个字段。函数内部先创建Presentation对象，选择一款简洁的模板布局，然后对每个大纲项创建一页slide，标题写入占位符，内容按bullet级别写入正文本占位符。
这里我踩过一个大坑：python-pptx的占位符结构在不同模板里差异极大，直接按索引slide.placeholders[1]写入正文，经常出现文本溢出或错位。稳妥的做法是先遍历slide.placeholders检查每个占位符的placeholder_format.type，再选择与PP_PLACEHOLDER.BODY对应的占位符写入正文，如果找不到BODY类型，就动态创建一个文本框兜底。
为了让PPT更"智能"一点，我还接入了一个封面自动生成逻辑：当用户没说想要什么风格的封面时，系统从标题文本中提取关键词，在预设的封面模板库中选择最匹配的一款。核心代码如下所示：
# 简单关键词打分的封面选择逻辑 cover_score = [] for template in cover_templates: score = 0 for word in template['keywords']: if word in user_title: score += 1 cover_score.append(score) best_index = cover_score.index(max(cover_score))这个逻辑非常简单，但效果很直观。演示的时候跟评委说"系统会根据标题语义自动匹配封面模板"，既有智能感又不过分依赖模型。
4.4 PDF解析与文档理解模块的细节处理
PDF模块分为两条链路：文本型PDF走pdfplumber的extract_text和extract_table，扫描型PDF走OCR链路。判断逻辑也很简单：抽取出的文本长度低于20个字符，就判定为扫描型，自动调用OCR工具链。
OCR我用了PaddleOCR，它对中文的支持是目前开源方案里最好的之一。但要注意，PaddleOCR首次运行会下载模型文件，网络环境不好的时候很闹心，建议在部署文档里明确写预下载步骤。OCR完成后的输出是带坐标的文本块，我会按(page, top, left)排序后重组为自然段落顺序，再送入摘要生成模块。
文档理解层对接的是大模型的文本摘要和结构化抽取能力。注意，PDF内容往往超过模型上下文窗口，需要分块处理。我的分块策略是按段落边界切分，每块控制在2000字符以内，块间重叠100字符以保证语义连贯。每块生成摘要后，再对摘要做二次摘要，得到整篇文档的核心摘要。两层摘要的结构化程度比单次摘要高很多，体验过就会发现差距。
5. 前后端联调与系统集成
5.1 Web界面与交互设计要点
系统前端我用的是一个轻量化的单页Web应用。页面布局非常直接：左侧是对话和任务面板，右侧是结果预览区。用户可以通过文本框输入需求，也可以拖拽上传Excel或PDF文件，上传的文件自动关联到当次会话，智能体可以使用这些文件作为处理对象。
这里有一个交互设计上的关键细节：所有工具调用过程必须实时可见。也就是说，当模型正在调用"生成图表"工具时，前端要能够一条一条地展示执行日志，比如"正在调用工具：generate_chart"、"工具执行结果：图表已生成，路径为/tmp/xxx.png"。这样做的好处有三个：用户知道系统没有卡死；执行过程可以被打断和纠偏；整个Agent的运行逻辑透明可信，而不是一个神秘黑盒。
为了实现实时执行日志，我用的是WebSocket长连接。后端每次工具调用完成，就推送一条事件到前端，前端事件对应更新面板。HTTP轮询也能做，但实时性和连接开销都不如WebSocket，就实际开发体验来说，WebSocket也不复杂，一个路由加上事件分发器就够了。
5.2 异步任务管理与超时控制
Agent执行链路可能长达几十秒甚至几分钟，如果前端一直同步等待，用户体验会很差。我的方案是任务异步化：用户提交需求后，后端立即返回一个task_id，任务在后台线程池中执行，前端通过WebSocket订阅这个task_id对应的事件流。
超时控制是所有Agent系统的隐藏难点。我设置了三级超时：单次模型请求默认30秒，单个工具执行默认20秒，整个任务链路默认180秒。超过时间后对应环节返回超时错误，任务状态更新为failed，前端提示用户"任务处理超时，请简化需求或重试"。超时时间要结合工具实际耗时来定，不是拍脑袋。实测下来，生成图表工具0.5秒内返回，大模型规划请求平均8秒，Word文档生成整份docx一般不超过3秒——这些数据都要通过日志系统统计出来，答辩时随口就能报出性能指标。
5.3 并发安全与资源管理
由于Web应用会同时服务多个用户，资源竞争问题必须提前考虑。最典型的是文件命名冲突：如果两个用户同时上传了data.xlsx，都存储为/tmp/uploads/data.xlsx，后写入的用户会覆盖先写入的用户文件。解决办法是使用UUID作为文件名主体，保存时顺便记录原始文件名用于展示。
全局临时目录的清理策略同样重要。我在会话结束后统一进行会话级清理，同时设置一个后台定时任务，每小时扫描一次临时目录，删除超过2小时且未在任务表中的文件。这套机制确保哪怕有会话异常中断，临时文件也不会无限累积占用磁盘空间。
关于线程池调度，我用了一个固定大小为8的线程池Executor。每个任务的工具调用链不会并行执行大量工具（一般同时2-3个），8个线程足够支撑同时处理4-5个任务的并发量。超过这个量时采用排队策略，而不是无限地创建新线程，否则机器跑不动。
6. 常见问题与排查技巧
6.1 模型乱调用工具怎么办：从约束到兜底
AI智能体项目中最折磨人的问题就是模型"自作主张"。比如用户只说"帮我写个通知"，模型却先去调用了巡检工具，又去搜索天气，最后才写通知。这种情况的根源是系统提示词里的边界约束不够，模型自由发挥空间太大。
我在系统提示词里加入了非常明确的三条规则：不得在用户明确指定工具前自行调用非必要工具；工具调用必须服务于当前正在执行的任务；一旦上下文包含工具执行结果，下一步必须基于结果继续处理，不得重复调用同一个工具。模型要真想遵守这些约束，效果比单纯靠概率"撞对"好很多。实测中，加了这组硬规则后，无意义工具调用率大约下降了一半。
还要在工具调度器里加一层白名单机制。某些工具只允许在特定场景下被调用，比如删除文件工具只有在会话生命周期内生成的临时文件才有权限删除。这样即使模型规划错了，调度器也会以"非法调用"打回。
6.2 中文编码与系统语言环境的坑
跨平台部署时的中文乱码问题，我遇到过两次。第一次是生成Word文档里的中文乱码——原因如前面所说是eastAsia字体属性没设置。第二次是Excel单元格里的中文在Linux环境下读取时变成乱码，排查到最后发现是openpyxl读取正常，但数据在传入模型API层时被某种编码转换函数给破坏了。
专门写一个ensure_utf8函数，所有进入系统的字符串统一走这个函数做编码归一化。流程是：先判断字符串类型，bytes就decode('utf-8')，str就检查是否包含\ufffd替换字符，如果包含就尝试用gb18030重新decode原始bytes。这个归一层虽然简单，却省掉了无数个"莫名其妙中文乱码"的深夜。
适配Windows和Linux之间的文档路径差异时同样不能掉以轻心。Windows下用反斜杠，Linux下用正斜杠，我统一使用pathlib的Path对象，所有路径拼接都用/运算符而不是字符串拼接，就彻底消除了这类问题。
6.3 上下文爆炸与内容截断优化
Agent循环天然会累积大量上下文，尤其在"读了一个大Excel文件"后，工具返回的数据可能达到数万token，直接把模型上下文窗口撑爆。这个问题我是通过两个工具级机制解决的：限制工具返回体大小和摘要前置化。
限制工具返回体大小比较好理解：read_excel工具最多返回500行数据；read_pdf工具最多返回前3000字符的文本。如果数据超过阈值，工具返回提示语"数据已截断，如需更多数据请使用分页参数读取"。摘要前置化是指，只要工具返回体超过800字符，先调用一次轻量模型压缩为不超过300字符的摘要，再注入上下文。工具原始结果仍保留在会话记忆中，用户可以在前端点击"查看完整数据处理过程"时调取。
这个策略实施后，一个复杂的"数据报告生成"任务，整条Agent链路的token消耗从约50k降到了约15k，成本和时间都大幅下降，效果显著。这是在所有Agent系统里都通用的优化方向。
6.4 前端下载与产物稳定性改造
最后说一个经常被忽略的环节：前端下载。如果后端直接把文件作为HTTP响应返回，一旦文件生成时间超过几秒，浏览器就可能因超时而终止下载。我的做法是先生成文件到本地，记录进会话的工作目录，再返回一个下载链接，前端点击后由后端的静态文件服务负责传输。传输速度慢？加一个Range请求支持就够了，这块我在Nginx层面配置了静态文件缓存，大文件下载体验非常好。
额外的稳定性措施是产物校验。文件生成后统一读取文件头部几个字节，校验是否为对应格式的Magic Number，比如docx文件必须为PK开头（ZIP格式），PNG图片必须为\x89PNG开头。校验失败的产物直接标记为错误，并在前端提示下载失败。这块逻辑只有十行代码，但能避免用户辛苦等几分钟后下载到损坏文件的糟糕体验。
7. 成果验证与扩展方向
7.1 多场景实测与效果评估
项目做完后的验收测试，我覆盖了这些场景：从零生成一份带图表和表格的调研报告；导入一份50MB以内的Excel销售数据，自动完成月度统计并绘制趋势图；基于产品关键词生成10页以内的产品介绍PPT；上传一份扫描版PDF合同，自动提取关键条款并生成摘要Word。这四个场景正好对应四个核心模块，任何一个跑通，系统的主干链路就验证了。
我在测试中还安排了"模糊需求"场景，输入的是"帮我整个汇报的东西"，这种问题根本没有明确指令，系统会返回澄清问题，让用户补充"需要什么主题、面向什么对象、希望什么形式"。这比强行猜测用户意图要稳妥得多，这个行为是由工具规划层的"但需求不明确时主动询问"规则实现的。
评估指标方面，我定义了任务完成率、平均工具调用次数、用户纠正率三个指标。实测下来，明确指令场景下的任务完成率在92%以上，平均链路调用工具4.8次，用户纠正率在15%以内。这个数据水平在毕设和演示场景里足够说明问题。如果你希望把指标做得更亮眼，最常见的改进方向是引入人工反馈强化，根据用户的"更正操作"反向调整规划权重，让模型学会"这类需求第一次就该怎么做"。
7.2 后续功能扩展方向
如果继续把这个项目往下做，我建议优先做三件事：一是加多模态支持，让智能体能识别图片里的表格和文字，并直接转为可编辑的Excel或Word内容；二是做任务队列和定时调度，让智能体可以"每天早上9点自动生成昨日销售日报"；三是引入检索增强（RAG），把企业内部的文档知识库接入上下文，让智能体在生成报告时可以引用历史文件的规范格式和结论数据。
这些扩展方向本质上都复用现有架构，只需要在工具注册表里添加新工具、在记忆管理里增加向量存储、在调度层加一个定时触发器，核心Agent循环不用大改。这也是当初把架构按"工具+规划器"模式设计带来的红利，前期多花的时间，在后期扩展时一定会补回来。
7.3 给同类项目开发者的三点建议
回头总结整个开发过程，有三点建议想送给打算做同类项目的同学。
第一，先跑通最小闭环再做功能堆叠。第一个里程碑就只做"用户输入文字-模型规划-调用一个工具生成Word文件"这条链路，哪怕粗糙也没关系，先把架构跑通。功能扩展是在这个闭环上不断加工具、加模块，而不是推翻重来。
第二，工具层的质量直接决定Agent的上限。与其花时间调教模型的"花活能力"，不如把每个工具的参数定义、错误处理和返回结构打磨到工业级。模型是流动的，工具是钉在地上的钉子，钉子牢靠，换什么模型这套系统都能稳住。
第三，为答辩和演示专门准备"最有说服力的一条链路"。比如从上传Excel到生成带图带表的完整Word报告，这中间展示了文件上传、数据解析、模型规划、图表生成、文档合成、Web下载六个环节，评委能直观感受到"AI干活"的全过程。与其展示阉割版的全能，不如把一条链路做深做透。
我在实际开发中最大的体会是：AI智能体这类项目，真正难的不是模型调用，而是如何把大模型的开放性与工程系统的确定性缝合在一起。Office套件恰好是这样一个天然的试验场——文档格式是高度结构化的，而用户需求是高度自由化的，两者之间那条"翻译通道"，就是这个项目的灵魂。你把这个通道做顺了，不光是毕设有亮点，未来很多自动化智能体产品，底层逻辑也都是这一套。
