文章核心观点 - 在构建企业级智能文档分析Agent时，完全依赖LLM（大语言模型）进行代码生成和执行的“全托管”模式存在稳定性、安全性和可控性方面的重大隐患[4][5] - 公司摒弃了激进的“纯Skills”路线，转而采用一种混合架构，核心思想是收回LLM的底层操作权，只保留其逻辑调度权[7] - 该架构结合了Java（负责确定性ETL与安全控制）、LLM（负责意图理解与逻辑调度）、封装式Python DSL Skills（负责受控计算）以及Java实时渲染，旨在保留LLM灵活性的同时确保工业级稳定性[8][28] 架构演进背景与挑战 - 基础文档问答（RAG）功能已成熟，但用户需求升级至复杂生成任务，例如对比多份报表数据并生成Excel和PDF报告[3] - 此类需求特征包括需要精确的逻辑计算（LLM弱项）和物理文件IO（LLM无法直接做到），最初看似只能通过引入LLM调用Python代码（Skills）来解决[3][4] “纯Skills”路线的失败经验 - 最初采用完全的Code Interpreter模式，赋予LLM联网和直接调用requests、pandas、reportlab等库的权限，让其自行编写代码解决问题[4] - 该模式在生产环境中暴露出三大问题：1）输入端对非结构化数据（如无后缀URL、加密PDF）处理脆弱，易陷入报错死循环；2）输出端让LLM从零生成PDF/Word等文件常导致中文乱码、表格错位、API使用错误等问题；3）安全黑洞，数据流在沙箱内闭环，主程序失去对敏感或违规内容的控制权[5] 混合架构设计与分工 - 新架构明确分层分工：ETL层（Java）负责确定性的数据下载、MIME识别、OCR和敏感词检测，确保输入LLM的数据干净、安全、标准化[8][10] - Brain层（LLM）负责阅读纯文本、进行逻辑推理并生成调用代码[8] - Skills层（Python沙箱）提供高度封装的DSL（领域特定语言）SDK，而非直接开放底层库权限[8][11] - Delivery层（Java）负责将Markdown/HTML实时渲染为PDF/Word等格式文件[8][16] Skills层的DSL封装策略 - 禁止LLM直接使用import pandas等底层操作，强制其调用预置的封装函数[11][14] - 例如，生成Excel时，LLM需准备字典列表形式的数据，并调用如excel_tool.create_excel(data, filename='analysis.xlsx')的封装函数，由工具自动处理样式和列宽等工程细节[15][21] - 通过Prompt中的“接口契约”和“核心决策树”约束LLM行为：针对统计数据/表格必须生成Excel并写Python代码调用封装函数；针对分析报告/文档必须生成Word/PDF且禁止写代码，需走渲染路径[13][14][22] 输出侧渲染与交付分离 - 对于Word/PDF等富文本生成，LLM只输出高质量的Markdown内容，并在末尾附加特定标签（如<<<ACTION:CONVERT|pdf>>>）[16] - Java后端拦截该标签，利用OpenHTMLtoPDF或Pandoc等工具将Markdown实时转换为格式精美的PDF/Word文件，从而避免LLM直接处理复杂排版[16] 关键技术实现要点 - 实现了动态技能注入管理器（SkillManager），支持按需加载技能，并设计了Session级“防抖机制”缓存脚本，避免重复IO以提升性能[18][19] - 业务调度处理器（Handler）串联Java ETL、LLM推理和最终交付分流，确保流程可控[20][23] - 在Tool执行层设置最后一道防线，对沙箱中命令执行的输出内容进行二次安检，确保安全[26] - 整体架构总结为：输入标准化与安全由Java负责，推理由LLM负责，计算通过Python DSL执行，输出渲染与交付由Java负责[29]