1. 项目概述当办公软件内核成为 Agent 的“肌肉系统”最近在技术社区里刷到一句特别带感的话“DeepSeek 把 LibreOffice 塞进了 Harness文档 Agent 开始补齐最后一公里”。初看像句营销口号细琢磨却戳中了当前智能体Agent落地最硬的那块骨头——它能想、能规划、能调用工具但就是写不出一份像样的 Word 报告、算不准 Excel 里的跨表引用、改不了 PPT 里第 7 张幻灯片的标题字体大小。这根本不是模型能力问题而是“最后一公里”缺失了真实办公环境的执行肌理。我盯这个方向快两年了从早期用 Python 调python-docx写报告到后来用openpyxl拼 Excel 公式再到上个月实测 DeepSeek-Harness LibreOffice Runtime 的组合才真正体会到什么叫“Agent 长出了手和脚”。这里的 LibreOffice 不是那个你双击打开的桌面程序而是被深度裁剪、无界面、可编程、能嵌入进程的LibreOffice Office Runtime简称 LO-OR——它本质上是一个轻量级办公文档引擎就像 Chromium Embedded FrameworkCEF之于浏览器LO-OR 就是 LibreOffice 的“嵌入式内核”。Harness 则是 DeepSeek 推出的 Agent 编排与运行时框架它的核心价值不在于替代 LLM而在于把 LLM 的“大脑”和各种“器官”数据库、API、文件系统、现在还包括办公引擎缝合成一个可调度、可回溯、可审计的整体。当 LO-OR 被塞进 Harness意味着 Agent 不再需要把“生成表格”翻译成一堆 JSON 再让前端渲染而是直接调用.uno:InsertTable命令在真实的.ods文件里插入一个带边框、自动列宽、含公式计算的表格——所有行为都符合 ISO/IEC 26300ODF 标准连 Excel 打开都不会报错。这个组合解决的不是“能不能做”而是“做得对不对、稳不稳、合不合规范”。比如财务部门要自动生成月度分析报告LLM 规划出“取销售数据→按区域汇总→生成趋势图→插入到模板第3页→导出为 PDF”Harness 负责拆解任务流并分发而 LibreOffice Runtime 就是那个蹲在后台默默执行“插入图表”、“设置坐标轴刻度”、“导出高分辨率 PDF”的工程师。它不靠猜测不靠渲染模拟它用的就是和你双击打开 LibreOffice Calc 一模一样的计算引擎和排版逻辑。适合谁看如果你正卡在这些场景里这篇就是为你写的做企业知识管理想让 Agent 自动从几十份 Word 合同里提取关键条款并生成摘要报告做 BI 工具集成希望用户说“把上季度华东区销售额做成柱状图插到周报模板里”Agent 就真能操作做低代码平台需要让非技术人员拖拽组件就能生成带格式的投标书、验收单、会议纪要或者你只是个技术负责人天天被业务方问“你们的 AI 能不能直接改 Word不是生成文字是改格式、加批注、删页眉”别再用“我们用的是大模型”搪塞了。最后一公里得用真实的办公引擎来跑。2. 核心架构拆解为什么是 LibreOffice Runtime而不是自己造轮子很多人第一反应是“不就是读写 Office 文档吗Python 有docxtpl、openpyxl、python-pptx够用了啊。”这话没错但只对“静态文档生成”成立。一旦进入“动态交互”和“真实环境兼容”阶段第三方库就露怯了。我拿一个真实案例说明某制造企业要求 Agent 自动生成设备巡检报告其中一项是“将传感器实时读数插入表格并根据阈值自动标红异常行”。用openpyxl实现看似简单from openpyxl import load_workbook from openpyxl.styles import Font, PatternFill wb load_workbook(template.xlsx) ws wb[巡检数据] for row in ws.iter_rows(min_row2, max_rowws.max_row): if row[3].value 85: # 温度列 for cell in row: cell.font Font(colorFF0000) cell.fill PatternFill(solid, fgColorFFFFCC) wb.save(report.xlsx)但问题来了这份 Excel 里有大量使用INDIRECT()和OFFSET()的动态公式openpyxl无法重算保存后公式结果还是旧的表格设置了“打印区域”和“页眉页脚”openpyxl会清空或错位最致命的是客户用的是 WPS Office而 WPS 对openpyxl生成的.xlsx兼容性极差经常报“文件损坏已尝试修复”修复后图表全丢。这就是纯库方案的天花板它在“数据层”工作但 Office 文档真正的灵魂在“表现层”和“计算层”——字体渲染、分页逻辑、公式引擎、宏执行、OLE 对象嵌入……这些只有原生引擎能搞定。LibreOffice RuntimeLO-OR正是为此而生。它不是完整版 LibreOffice 的阉割版而是从源码层面剥离 UI、网络、打印服务后保留核心文档引擎Writer、Calc、Impress、UNO APIUniversal Network Objects、Script Provider支持 Basic、JavaScript、Python 宏的精简运行时。它的体积控制在 80–120MBLinux x64内存占用峰值约 300MB启动时间 1.2 秒SSD 环境完全满足嵌入式调用需求。提示LO-OR 和桌面版 LibreOffice 共享同一套核心引擎这意味着你在 LO-OR 里执行的ThisComponent.Sheets(0).getCellByPosition(0,0).Value 123和你在桌面版里按 AltF11 打开宏编辑器写的代码调用的是完全相同的底层函数。这不是模拟是复用。Harness 选择集成 LO-OR而非自己实现一套文档引擎背后有三重硬逻辑第一合规性压倒一切。国企、金融、政务系统对文档格式有强制标准如 GB/T 20916-2007《电子公文格式规范》要求必须使用符合 ODF 或 OOXML 标准的原生引擎生成。自己造的库哪怕功能再强也过不了等保测评的“格式一致性”这一关。LO-OR 是 OASIS 认证的 ODF 参考实现天然合规。第二生态不可替代。全球有超过 2000 万开发者熟悉 LibreOffice Basic企业内部积压着海量历史宏.odt模板里的Standard模块、WikiEditor插件里的自定义函数。Harness 不需要你重写只要把.odb数据库、.odt模板、.bas宏文件扔进指定目录LO-OR 就能原样加载执行。我实测过某银行遗留的 17 年前的LoanCalc.bas在 LO-OR 里跑起来零报错。第三扩展性留足余地。LO-OR 支持 UNO 组件热插拔。你可以编译一个 C 组件比如对接 SAP RFC 的桥接器注册进 LO-OR然后在 Agent 的 Python Skill 里直接调用ctx.getServiceManager().createInstance(com.example.SAPBridge)。这种深度集成能力是任何 Python 库望尘莫及的。所以“把 LibreOffice 塞进 Harness”不是技术炫技而是面向生产环境的务实选择用最成熟、最标准、最开放的办公引擎去补足 Agent 最脆弱的执行环节。它不追求“最先进”但确保“最可靠”。3. 技术实现详解从 Harness 插件到 LibreOffice Runtime 的全链路打通要让 Harness 真正“驾驭” LibreOffice Runtime不是简单地subprocess.Popen()起个进程就完事。整个链路涉及四个关键层Harness 插件层、进程通信层、LO-OR 初始化层、UNO API 调用层。下面我以一个真实场景——“Agent 自动填充合同模板并签署数字签名”为例逐层拆解实操细节。3.1 Harness 插件开发定义文档操作 SkillHarness 的 Skill 是原子化能力单元每个 Skill 对应一个明确的文档操作。我们创建doc-fillerSkill其核心逻辑是接收 JSON 输入合同变量、签名位置、证书路径返回处理后的.docx或.odt文件路径。# 在 Harness 项目根目录下 harness skill create --name doc-filler --type python生成的skills/doc-filler/skill.py骨架如下from harness.skill import Skill from harness.logger import get_logger import os import json from pathlib import Path logger get_logger(__name__) class DocFillerSkill(Skill): def __init__(self, config): super().__init__(config) # 从配置中读取 LO-OR 路径和端口 self.lo_or_path config.get(lo_or_path, /opt/libreoffice/runtime) self.lo_or_port config.get(lo_or_port, 2002) def execute(self, input_data: dict) - dict: try: # 1. 解析输入 template_path input_data[template_path] variables input_data[variables] signature_info input_data.get(signature, {}) # 2. 调用 LO-OR 服务关键见下节 output_path self._fill_template( template_path, variables, signature_info ) return { status: success, output_path: str(output_path), file_size: output_path.stat().st_size } except Exception as e: logger.error(fDocFiller failed: {e}) raise def _fill_template(self, template_path, variables, sig_info): # 此处调用外部 LO-OR 服务暂留空 pass注意lo_or_path和lo_or_port必须在harness.yaml中显式配置因为 LO-OR 是独立进程Harness 不负责启动它。这是设计上的主动解耦——LO-OR 可以由 systemd 管理保证高可用Harness 只管调用失败时可重试或降级。3.2 进程通信层Socket JSON-RPC 的轻量协议Harness 和 LO-OR 之间不走 HTTP太重也不用 D-Bus跨平台兼容性差而是采用TCP Socket 自定义 JSON-RPC 协议。原因很实在Socket 启动快、连接开销小适合高频短请求如每秒 50 次文档操作JSON-RPC 结构清晰易调试Python/Java/C 都有成熟库避免引入额外依赖如 gRPC 需要 Protocol Buffers 编译。LO-OR 启动时监听localhost:2002等待 Harness 发送请求。一个典型的“填充模板”请求 JSON 如下{ jsonrpc: 2.0, method: fill_template, params: { template_path: /var/harness/templates/contract.odt, variables: { client_name: 北京智算科技有限公司, amount: ¥1,280,000.00, date: 2024-06-15 }, signature: { cert_path: /etc/certs/company.p12, password: ******, position: Page1;X120;Y85;W180;H60 } }, id: 12345 }LO-OR 的 Python 服务端lo-or-server.py用asyncio实现import asyncio import json import uno from com.sun.star.uno import XComponentContext from com.sun.star.lang import XMultiComponentFactory class LOORServer: def __init__(self, lo_path): self.lo_path lo_path self.context None self.factory None async def start(self): # 1. 启动 LibreOffice Runtime关键初始化 await self._start_lo_or() # 2. 创建 UNO 组件上下文 self.context uno.getComponentContext() self.factory self.context.getServiceManager() async def _start_lo_or(self): # 使用 soffice.bin 启动无界面 LO-OR # --headless: 无界面 # --acceptsocket,host127.0.0.1,port2002;urp;: 开放 UNO 连接 # --nologo --nodefault --nofirststartwizard: 加速启动 cmd [ f{self.lo_path}/program/soffice.bin, --headless, --acceptsocket,host127.0.0.1,port2002;urp;, --nologo, --nodefault, --nofirststartwizard ] self.lo_proc await asyncio.create_subprocess_exec( *cmd, stdoutasyncio.subprocess.DEVNULL, stderrasyncio.subprocess.DEVNULL ) # 等待 LO-OR 监听端口就绪 await self._wait_for_port(2002) async def _wait_for_port(self, port, timeout10): for _ in range(timeout * 10): try: reader, writer await asyncio.open_connection(127.0.0.1, port) writer.close() await writer.wait_closed() return except (ConnectionRefusedError, OSError): await asyncio.sleep(0.1) raise TimeoutError(fLO-OR failed to bind port {port}) async def handle_request(self, reader, writer): data await reader.read(8192) if not data: return try: req json.loads(data.decode()) result await self._process_rpc(req) resp {jsonrpc: 2.0, result: result, id: req[id]} except Exception as e: resp {jsonrpc: 2.0, error: {code: -32603, message: str(e)}, id: req.get(id, 0)} writer.write(json.dumps(resp).encode()) await writer.drain() writer.close() await writer.wait_closed() async def _process_rpc(self, req): method req[method] params req[params] if method fill_template: return await self._fill_template_impl(params) elif method sign_pdf: return await self._sign_pdf_impl(params) else: raise NotImplementedError(fUnknown method: {method}) async def _fill_template_impl(self, params): # 2. 核心用 UNO API 操作文档见下节 template_path params[template_path] variables params[variables] # ... 实现填充逻辑 return {output_path: /tmp/filled_contract.odt}实操心得LO-OR 的--accept参数必须精确匹配。常见错误是写成--acceptsocket,hostlocalhost,port2002;urp;但localhost在某些 Docker 网络下解析为 IPv6 地址导致 Harness 连不上。务必用127.0.0.1。另外soffice.bin的路径在不同发行版下可能不同Ubuntu 是/usr/lib/libreoffice/program/soffice.binCentOS 是/opt/libreoffice6.4/program/soffice.bin建议在harness.yaml中统一配置。3.3 LO-OR 初始化绕过 GUI 陷阱的 7 个关键参数启动 LO-OR 看似一行命令但生产环境必须精细控制。我踩过无数坑总结出必须设置的 7 个参数缺一不可参数必填作用我的实测值坑点说明--headless✅禁用 GUI否则进程会卡住等待 X11 显示-不加此参数LO-OR 在无桌面环境会无限挂起--acceptsocket,host127.0.0.1,port2002;urp;✅开放 UNO 远程连接见上文host必须是127.0.0.1port与 Harness 配置一致--nologo✅禁止启动画面-减少启动时间约 300ms--nodefault✅跳过默认配置加载-避免读取用户家目录下的~/.config/libreoffice防止权限问题--nofirststartwizard✅跳过首次向导-否则会弹出配置窗口阻塞进程--nocrashreport✅禁用崩溃报告-防止生成临时文件和网络请求--norestore✅禁用恢复上次会话-避免加载未关闭的文档导致状态混乱此外还有两个隐藏但至关重要的环境变量# 必须设置否则 LO-OR 无法定位资源文件词典、模板等 export LIBREOFFICE_HOME/opt/libreoffice/runtime # 设置临时目录避免 /tmp 权限问题尤其在容器中 export TMPDIR/var/tmp/lo-or注意LIBREOFFICE_HOME不是安装路径而是 LO-OR 的运行时根目录。它必须包含program/、share/、basis-images/等子目录。官方提供预编译的 LO-OR 包如libreoffice-runtime-7.6.4-x86_64.tar.gz解压后直接可用。千万别用apt install libreoffice安装的包那是桌面版缺少--headless优化和精简资源。3.4 UNO API 实战用 Python 操控文档的 5 个黄金模式LO-OR 的灵魂是 UNO API它提供了对 Writer、Calc、Impress 的完整控制。Harness 的 Skill 最终都要落到 UNO 调用上。以下是我在合同填充场景中提炼出的 5 个最常用、最稳定的模式模式 1文本替换安全版——不用SearchReplace用TextCursordef replace_text_unsafe(doc, search, replace): # ❌ 危险SearchReplace 会破坏样式、段落属性 find doc.createSearchDescriptor() find.SearchString search found doc.findAll(find) for i in range(found.getCount()): found.getByIndex(i).String replace def replace_text_safe(doc, search, replace): # ✅ 安全保持原有格式 text doc.getText() cursor text.createTextCursor() while cursor.findFirst(search): # 获取光标位置的原有属性 old_props cursor.getPropertyValues((CharFontName, CharHeight, CharColor)) cursor.String replace # 恢复属性 cursor.setPropertyValues(old_props)模式 2表格填充——用CellRange批量写入避免逐单元格循环def fill_table_fast(sheet, data, start_row, start_col): # ✅ 高效一次写入整个二维数组 cell_range sheet.getCellRangeByPosition( start_col, start_row, start_col len(data[0]) - 1, start_row len(data) - 1 ) cell_range.setDataArray(data) # data 是 list[list[]] # 示例填充销售数据 sales_data [ [华东, 125000, 0.15], [华南, 98000, 0.12], [华北, 142000, 0.18] ] fill_table_fast(calc_sheet, sales_data, 1, 0) # 从 B2 开始模式 3宏调用——执行.odt内置的Standard模块def run_macro(doc, module_name, macro_name): # ✅ 调用文档内宏如 Standard.MyCalculation script_provider doc.getScriptProvider() script_uri fvnd.sun.star.script:{module_name}.{macro_name}?languageBasiclocationdocument script script_provider.getScript(script_uri) script.invoke((), (), ()) # 调用合同模板里的 Standard.CalculateTotal 宏 run_macro(writer_doc, Standard, CalculateTotal)模式 4数字签名——用com.sun.star.security.XCertificate接口def add_digital_signature(doc, cert_path, password, position): # ✅ 原生签名符合 PKCS#12 标准 signing_service doc.getContext().getServiceManager().createInstance( com.sun.star.security.CertificateContainer ) cert signing_service.importCertificateFromFile(cert_path, password) # 位置解析Page1;X120;Y85;W180;H60 → 第1页坐标(120,85)宽180高60 signer doc.getSigner() signer.addSignatureField(position, cert)模式 5导出 PDF——用ExportFilter精确控制质量def export_to_pdf(doc, output_path): # ✅ 高质量导出支持 CMYK、嵌入字体 props ( PropertyValue(FilterName, 0, writer_pdf_Export, 0), PropertyValue(SelectPdfVersion, 0, 17, 0), # PDF/A-1b PropertyValue(ExportFormFields, 0, True, 0), PropertyValue(EmbedFonts, 0, True, 0), PropertyValue(UseLosslessCompression, 0, True, 0), PropertyValue(ReduceImageResolution, 0, False, 0), ) doc.storeToURL(ffile://{output_path}, props)实操心得UNO API 的PropertyValue结构容易写错。我封装了一个make_prop(name, value)辅助函数避免手写元组。另外所有doc对象操作完必须调用doc.close(True)否则 LO-OR 进程会累积文档句柄导致内存泄漏。我在__del__方法里加了强制清理但更推荐用try...finally保证。4. 实战部署与避坑指南从本地测试到内网服务器的全流程把 Demo 跑通和在生产环境稳定运行是两回事。我花了三个月在客户现场部署这套方案整理出从开发机到内网服务器的完整 checklist全是血泪经验。4.1 本地开发环境搭建Mac/LinuxStep 1安装 Harness CLI 和 LO-OR# Harness CLI官方源 curl -fsSL https://get.harness.io | sh # LO-OR下载预编译包非 apt wget https://download.documentfoundation.org/libreoffice/stable/7.6.4/rpm/x86_64/LibreOffice_7.6.4_Linux_x86-64_rpm.tar.gz tar -xzf LibreOffice_7.6.4_Linux_x86-64_rpm.tar.gz sudo cp -r LibreOffice_7.6.4_Linux_x86-64_rpm/LibreOffice_7.6.4.2_Linux_x86-64_rpm/ /opt/libreoffice/runtimeStep 2配置 Harness在harness.yaml中添加skills: doc-filler: type: python path: ./skills/doc-filler config: lo_or_path: /opt/libreoffice/runtime lo_or_port: 2002 services: lo-or-server: command: python3 /path/to/lo-or-server.py --lo-path /opt/libreoffice/runtime restart: alwaysStep 3启动并测试# 启动 Harness harness start # 启动 LO-OR 服务另开终端 python3 lo-or-server.py --lo-path /opt/libreoffice/runtime # 发送测试请求 curl -X POST http://localhost:8000/api/skill/doc-filler \ -H Content-Type: application/json \ -d { template_path: /path/to/template.odt, variables: {client_name: 测试公司} }常见问题Mac 上soffice.bin报dyld: Library not loaded: rpath/libuno_sal.dylib。解决方案install_name_tool -add_rpath /opt/libreoffice/runtime/program/ /opt/libreoffice/runtime/program/soffice.bin。这是 Mac 的 RPATH 机制问题Linux 不会出现。4.2 内网服务器部署CentOS 7/8内网环境没有公网、没有 Docker、不能装新包是最考验方案鲁棒性的场景。我的部署策略是静态二进制 systemd 最小权限。1. 构建静态 LO-OR 包# 在干净的 CentOS 7 Docker 容器中构建 docker run -it --rm -v $(pwd):/work centos:7 yum install -y gcc-c make rpm-build # 下载 LibreOffice 源码打 patch 移除所有动态链接如 libpng、libjpeg全部静态编译 # 输出/opt/libreoffice/static/soffice.bin大小 120MB无外部依赖2. systemd 服务文件/etc/systemd/system/lo-or.service[Unit] DescriptionLibreOffice Runtime Service Afternetwork.target [Service] Typesimple Userharbor Groupharbor WorkingDirectory/var/lib/lo-or ExecStart/opt/libreoffice/static/soffice.bin \ --headless \ --acceptsocket,host127.0.0.1,port2002;urp; \ --nologo --nodefault --nofirststartwizard --nocrashreport --norestore Restartalways RestartSec10 EnvironmentLIBREOFFICE_HOME/opt/libreoffice/static EnvironmentTMPDIR/var/tmp/lo-or [Install] WantedBymulti-user.target3. 权限加固# 创建专用用户 useradd -r -s /sbin/nologin harbor # 设置目录权限 chown -R harbor:harbor /opt/libreoffice/static chown -R harbor:harbor /var/tmp/lo-or chmod 755 /opt/libreoffice/static/program4. Harness 配置适配# harness.yaml services: lo-or-server: # 不再用 python 启动改用 systemd 管理 command: systemctl start lo-or.service # Harness 只负责调用不管理生命周期关键经验内网服务器常禁用SELinux但setenforce 0不够必须sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config并重启否则soffice.bin会被拦截。另外/var/tmp/lo-or目录必须存在且harbor用户可写否则 LO-OR 启动失败但日志无提示。4.3 性能调优与监控生产环境每分钟处理 200 文档必须监控和调优。内存优化LO-OR 默认最大堆内存 512MB对复杂文档不够。在soffice.bin启动参数加-J-Xmx1024m启用--convert-to pdf模式时PDF 导出内存峰值可达 1.5GB需预留足够 swap我用psutil写了个监控脚本当 LO-OR 进程 RSS 800MB 时自动重启。并发控制Harness 的 Skill 默认并发数为 10但 LO-OR 是单进程同一时间只能处理一个文档。必须在 Skill 中加锁import threading lo_or_lock threading.Lock() def _fill_template(self, template_path, variables, sig_info): with lo_or_lock: # 确保串行调用 # 调用 LO-OR 服务 ...健康检查在 Harness 的healthcheck端点里加入 LO-OR 连通性检测# 在 harness/health.py 中 import socket def check_lo_or(): try: sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(2) sock.connect((127.0.0.1, 2002)) sock.close() return True, LO-OR OK except Exception as e: return False, fLO-OR DOWN: {e}实测数据单台 8C16G 服务器LO-OR Harness 组合平均处理一个 10 页 Word 合同耗时 1.8 秒含模板加载、变量替换、签名、PDF 导出。CPU 利用率峰值 65%内存稳定在 1.2GB。瓶颈在磁盘 I/O模板读取和 PDF 写入升级 NVMe 后性能提升 40%。5. 常见问题排查与独家技巧那些文档 Agent 不会告诉你的事即使按上述步骤部署仍会遇到一些“只在此山中云深不知处”的问题。我把过去半年收集的 12 个典型问题按发生频率排序并给出 root cause 和独家解法。5.1 高频问题速查表问题现象根本原因解决方案我的独家技巧Harness 调用 LO-OR 超时Connection refusedLO-OR 进程未启动或--accept端口被防火墙拦截netstat -tuln | grep 2002检查端口systemctl status lo-or查日志在lo-or.service的ExecStart后加 sleep 2确保端口监听就绪再返回文档打开后显示“内容已被修改是否保存”LO-OR 修改了文档元数据如 CreationDate触发脏标记在 UNO 调用后手动重置元数据doc.DocumentProperties.ModificationDate doc.DocumentProperties.CreationDate封装一个clean_metadata(doc)函数所有 Skill 执行完必调用Excel 公式不重算显示#VALUE!openpyxl等库生成的.xlsx用 LO-OR 打开时公式引擎未激活启动 LO-OR 时加--calc参数强制 Calc 模式或用 UNO 调用doc.calculateAll()在_fill_template_impl结尾加doc.calculateAll()比--calc更精准中文乱码显示为方框LO-OR 未加载中文字体或LANG环境变量未设export LANGzh_CN.UTF-8复制NotoSansCJKsc-Regular.ttf到/opt/libreoffice/runtime/share/fonts/truetype/用fc-list | grep -i sim检查字体LO-OR 只认fonts/truetype/下的字体宏执行报错BASIC runtime error. Object variable not set宏中引用了ThisComponent但文档未激活在宏开头加If Not ThisComponent.IsLoaded Then Exit Sub在 Harness Skill 中用doc.getCurrentController().attach()激活文档控制器PDF 导出后图片模糊默认导出 DPI 96印刷级需 300在export_to_pdf的props中加PropertyValue(ExportQuality, 0, 300, 0)用pdfinfo output.pdf验证实际 DPI避免参数无效5.2 那些“文档 Agent”不会告诉你的事1.Standard和WikiEditor的本质区别很多开发者困惑“我的宏下面有Standard和WikiEditor两者有什么不同”答案很直白Standard是文档内置的宏模块随.odt文件一起保存每个文档独立WikiEditor是一个扩展Extension安装后全局生效它的宏存放在/opt/libreoffice/runtime/basis-link/program/下所有文档都能调用。我的技巧把通用函数如日期格式化、金额转大写写在WikiEditor里把业务逻辑如合同编号生成规则写在Standard里。这样既复用又隔离。2. Harness 的agent和harness不是同义词搜索热词里有harness and agent difference其实这是概念混淆。Agent是智能体范式