Office 里的 AI 插件，最容易做成一个漂亮的右侧聊天框。人问一句“帮我整理这张表”，它回一段建议；人说“把这几段改成正式报告风格”，它再给一段改写。看起来有 AI 味了，但文件本身没有真正被理解，也没有真正被改好。

真正烦人的场景更具体。Excel 里选中了 A1:B100，AI 还追问“你要分析哪张表”；Word 里明明选中了几段编号混乱的文字，它还让人复制全文；PPT 里选中了一个文本框，AI 却只给出抽象的排版建议。这样的助手不算懒，但离“办公智能体”还差一层动作能力。

it235/office-ai-agent 把这个问题推得更深。它不是只给 Word、Excel、PowerPoint 各放一个聊天入口，而是在尝试让 AI 先观察当前 Office 文件，再规划操作、调用工具、执行改动、观察结果，必要时再修复。它的重点不是“能聊”，而是把聊天框往可执行的 Office Agent 推。

这也是这个仓库最值得看的地方：它把 Office 的真实对象模型放回了 AI 流程里。

右侧栏只是入口，现场信息才是起点

README 里写得很直接：这个项目基于 Visual Basic.NET、VSTO、.NET Framework 4.7.2 和 WebView2，为 Excel、Word、PowerPoint 提供 AI 辅助能力。表面上看，它有聊天式任务窗格、模型配置、MCP、Skills、翻译、排版、校对这些常见功能；但真正把它撑起来的，是各个宿主对当前文件的上下文读取。

ExcelContextProvider 会读当前工作簿、工作表、使用区域、选中 Range、表头、列类型、公式和错误单元格，还会给出推荐默认工作范围和输出位置。PowerPointContextProvider 会读当前演示文稿页数、当前页、选中形状数量、文本框字号、字体、加粗斜体和内容预览。Word 侧也有 WordContextProvider、WordActionHarness、WordNumberingAgent、WordFormattingAgent 这些面向段落、编号、排版和校对的入口。

这些细节决定了它不是泛泛地“接入大模型”。AI 如果不知道当前文件的状态，就只能猜；知道选区、表头、段落、样式和幻灯片对象以后，才有可能把“帮我算提成”“重构序号和标题”“优化选中幻灯片表达”变成可执行任务。

三端各管现场，ShareRibbon 管中枢

仓库结构也能看出它的取舍。ExcelAi、WordAi、PowerPointAi 分别处理自己的对象模型，不互相越界；ShareRibbon 则放共享的 Chat 控件、配置、Prompt、API Key、MCP、记忆、工具注册、Agent Kernel 和通用 UI。这种拆法不花哨，但对 Office 插件很重要。

原因很简单：Excel 的世界是 Workbook、Worksheet、Range、公式和图表；Word 的世界是 Document、Paragraph、Range、Selection 和样式；PowerPoint 的世界是 Presentation、Slide、Shape 和文本框。共享层如果直接伸手改三端对象，很快会变成一团难查的 COM 调用。这个仓库把通用能力留在 ShareRibbon，把具体执行交回各自宿主，路线更稳。

它把“执行过了”改成“执行后再看一眼”

ShareRibbon/Agent/AgentKernel.vb 里，AgentKernel 把 PromptManager、ToolRegistry、SkillRegistry、AgentMemory 和 LoopEngine 放在一起。这个组合说明仓库的想法不是一次性把自然语言丢给模型，而是让模型在工具、技能、记忆和当前 Office 上下文之间来回走。

SelfCheckLoopController.vb 的流程也很有代表性：先做 Planning，再进入 Generating 和 Validating，通过后执行，接着 Verifying。校验失败时还有 Correction Loop。它不把“AI 生成了一段指令”当成终点，而是把规划、生成、校验、执行、验证拆开，让失败有机会被修正。

ToolRegistry 里的 ToolResult 也在往这个方向走。它不只返回 Success 和 Message，还带 Observation、UndoPointId、Artifacts、ErrorCode、UserMessage、DebugDetail、Recoverable。对办公场景来说，这些字段很实在：改动有没有发生，目标对象是哪一个，失败能不能重试，是否有撤销点，都比一句“已完成”更可靠。

长尾 Office 操作，不能靠无限加按钮解决

docs/design/office-object-operation-integration.md 里有一条判断很关键：不要为 SmartArt、艺术字、时间线、组合形状这类长尾需求不断新增专用 Tool。它计划保留两个稳定入口，一个是 DiscoverOfficeCapability，用来动态发现当前宿主能做什么；另一个是 OfficeObjectOperation，用声明式 OperationBatch 执行具体对象操作。

这背后有个现实问题：Office 能力太长了。每个新需求都写一个意图枚举和专用工具，插件迟早会被关键词和分支拖垮。把对象引用、操作批次、风险等级、Observation 和宿主执行入口先统一起来，后续再覆盖更多对象，才有机会让 Agent 真正处理长尾办公任务。

文档也反复强调不能新建第二套 Harness、Planner、Loop 或 SafetyGate，必须复用 BaseChatControl 到 Office COM 的现有主链。这个约束看起来像工程洁癖，其实是在防止系统分裂。一个 Office Agent 最怕的不是能力少，而是同一个操作在两套状态机里有两种结果。

难点不在愿景，而在每次改文件都要可解释

office-ai-agent 的目标很大：Excel 数据分析、Word 排版校对、PowerPoint 生成审阅、文档级翻译、MCP/Skills 扩展、短期会话和长期记忆都想接进去。这样的项目很容易写成口号，但它的代码和文档里已经出现了不少落地痕迹：上下文采集、预览优先、执行解释、观察结果、修复循环、声明式操作。

它当然也会更难维护。VB.NET、VSTO、WebView2、Office COM、WPS 兼容、安装包 vdproj、不同模型配置、MCP 连接和安全门都混在一个真实桌面插件里，每一层都可能出小问题。仓库里的 AGENTS.md 和 CLAUDE.md 写了很多工程避坑，也说明这个项目已经不是简单 demo。

但它的方向是清楚的：办公 AI 不该停在“我建议你这样改”，而应该知道当前文件在哪里、准备改什么、实际改了什么、改完是否达到目标。把这几步串起来，office-ai-agent 才从 Office 聊天助手，开始接近真正能干活的办公智能体。