最新资讯
dev.to 银行 77 意图分类最便宜 LLM:GPT-6.1 Terra 每次成功任务 $0.000727 theinformation.com Chesky的副业:Airbnb向CEO新设AI实验室出售IP theverge.com OpenAI 宣布数据中心项目不再与公职人员签署保密协议 dev.to NVIDIA 发布四个开放 Cosmos 3 仿真模型 dev.to 真实 MCP 客户端击穿我们服务器的五种方式 theverge.com Airbnb 正在开发 AI 旅行 agent,计划 2027 年上半年推出 wechat 这可能是美国AI最魔幻的一天。 nytimes.com 美众议院共和党领袖要求 Nvidia 黄仁勋闭门简报 pub.towardsai.net 忘掉我:为记忆而设计的系统中的删除难题 marktechpost.com Google 发布 Gemini Omni 1.2 Flash:15 秒视频,每秒 0.07 美元 unite.ai Airbnb 计划推出覆盖规划、预订与客服的 AI 旅行 agent techcrunch.com Airbnb 称将于 2027 年上半年推出 AI 旅行代理
多元动态
登录 注册
智能体 news.ycombinator.com ·

Launch HN:Vespper(YC F24)推出 SOTA Docx MCP

原文 我的收藏

Vespper 团队发布 Docx MCP,让 AI Agent 以类似编辑 HTML 的方式编辑 Word 文档,由微调模型驱动。团队称其比最接近的替代方案快 3 倍、便宜 2 倍且更准确。背景是 OOXML 规范下 Word 文档为冗长 XML 的 zip 包,小改动也需处理 numbering.xml、run 拆分等机制,导致 Agent 消耗大量 token 与时间;现有方案(python-docx 等底层库、SuperDoc/Office CLI 等 MCP、pandoc/mammoth.js 转换)分别存在上下文浪费或保真度损失问题。团队此前为药企构建 AI 文档编辑器,生成单份 CSR 约需 50 分钟且结果不佳,Harvey.ai 也有类似结论。性能数据为团队自述,尚无独立验证。

AI推荐理由 YC F24 团队发布的 Vespper Docx MCP,针对 AI Agent 编辑 Word 文档的痛点提出方案:将 OOXML 的复杂机制(numbering.xml、run 拆分等)封装,让 Agent 以类似编辑 HTML 的方式操作文档。文中给出具体背景(此前为药企做 AI 文档编辑器、CSR 生成约 50 分钟且结果不佳)并引用 Harvey.ai 的类似结论,问题定义清晰。但 3× 更快、2× 更便宜、更准确等性能声明均为团队自述,未提供基准测试或可验证证据,需谨慎看待。

72

正文

https://www.vespper.com/blog/launching-vespper-docx-mcp Launch HN: Vespper (YC F24) – SOTA Docx MCP (vespper.com ) Hey HN! We're Dudu and Topaz from Vespper ( https://vespper.com https://vespper.com ). Vespper is an MCP that lets AI agents efficiently edit Word documents, powered by our fine-tuned model. It's currently 3× faster, 2× cheaper and more accurate than the closest alternative. Check out an overview of how the product works here: https://youtu.be/odKxsgPjzzw https://youtu.be/odKxsgPjzzw We came to work on this problem after spending a year building an AI document editor for pharma companies. Before that, Topaz(myself) was a senior SWE at Snyk, working on distributed systems, and Dudu was a deep learning engineer at Viz.ai, building computer vision models for stroke detection. Our editor helped pharma companies generate regulatory documents (e.g. CSRs) to speed up their submissions. Initially, the output was Markdown, displayed in a WYSIWYG editor. However, users preferred working with their own Word templates. That's when the problems began.AI agents aren't great at editing Word documents. A Word document is a zip file of verbose XML files following the OOXML spec. Even "small" changes require backflips, for example: adding a numbered list requires creating an entry in numbering.xml with a fresh ID and linking it back in document.xml, bolding a sentence requires splitting it into 3+ run elements. The list goes on.This makes editing the zip directly (unzip + grep + sed) a bad idea for agents because they burn a lot of time + tokens on these mechanics. In practice, today's tooling falls into roughly three categories. You can let the agent write code against low-level libraries like python-docx or the Open XML SDK, you can give it an MCP with opinionated editing tools (SuperDoc, Office CLI, Adeu, etc), or you can round-trip the file through Markdown/HTML with something like pandoc/mammoth.js. None of them really work. The first two categories still burn the agent's context on Word mechanics instead of the task at hand (MCPs also introduce a new DSL to learn), and the third is very lossy (pandoc/mammoth.js/etc don't preserve enough fidelity).From firsthand experience, these problems hurt performance in downstream tasks.When we tried having our agent fill large documents, things broke quickly. The context window was already packed with customer data (files, user context, global rules, etc.), and the agent burned tokens + time on exploring the document and debugging failed edits. Filling a single CSR (clinical study report) took ~50 minutes, and the result was bad (missed fields/sections, broken styling, etc.). Harvey.ai's team reached similar conclusions: https://www.harvey.ai/blog/building-an-agent-for-complex-document-drafting-and-editing https://www.harvey.ai/blog/building-an-agent-for-complex-doc... That's when we shifted our focus. We designed an MCP that lets agents edit Word docs as if they were editing HTML. The agent receives HTML, makes find-and-replace edits, and we reconcile those edits back into the original .docx file. We picked HTML over Markdown because it's structurally much closer to OOXML and because CSS associates styles with elements roughly the way OOXML does. We had to write our own DOCX→HTML converter, since pandoc and mammoth.js didn't preserve enough fidelity. To be clear, our DOCX → HTML conversion is lossy too. That's fine though, because we never convert the HTML back to DOCX. The HTML is just a projection for the agent, so it only needs enough fidelity for the agent to understand the structure and styling of what it's editing. The original file stays the source of truth, and we mutate it in place.This also means the agent doesn't need to learn a new DSL. Editing a Word document feels just like editing an HTML file on the file system, something agents are already great at. A lot of DOCX MCPs hand agents dozens or even hundreds of tools to figure out on the fly. Our MCP exposes just three tools (read, search, edit). The Word document is completely abstracted.After an agent sends us an edit request (an "old_html" and "new_html" pair), we reconcile it to the original .docx file. The reconciliation is powered by our fine-tuned model, a 3-8B base with a LoRA adapter. It takes the HTML diff as input along with the original localized OOXML block and emits the new OOXML. The "localization" is done deterministically: we take the anchors the agent specifies and we try to find their XML twins, so the reconciler model has a single responsibility. On this narrow task a small model reaches the level of a frontier, well prompt-tuned model, while being small and fast enough to sit in the hot path.This project turned into months of work, but we're happy to release our v1. Our internal benchmark shows it's more accurate than the DOCX skill and raw python-docx while being ~2x cheaper and ~3x faster, mostly because it takes 3 tool calls (p50) per task whereas the DOCX skill takes 10 and Office CLI takes 13.Things aren't perfect yet. For example, we don't support manipulating images or comments at the moment. That said, we're already seeing people use our MCP in various ways:- Legal tech companies powering their live-editing flow in Office.js.- AI startup optimizing people’s resumes and applying on their behalf.- Govtech who need to draft policy memos.- A life sciences startup using long-running agents to complete regulatory forms.A note on privacy: our MCP runs in the cloud, so users send us their .docx files. We don't train on user data, and teams can opt for ZDR or self-hosting.There's a free tier with 500 edits a month, and we’d love you all to try. We want to bump that later, but we're a small team and running a fine-tuned model isn't cheap :(We'd love to hear your ideas and comments about docx editing in general! We'll be in the comments for the next few hours to respond help david1542 1 hour ago | next [–] Btw we open sourced a Word add-in project that shows how to build a Word add-in with Vespper MCP: https://github.com/vespperhq/examples/tree/main/word-add-in https://github.com/vespperhq/examples/tree/main/word-add-in reply topaztee 1 hour ago | prev [–] sign up for free to try: https://app.vespper.com/ https://app.vespper.com/ reply Guidelines | FAQ | Lists | https://github.com/HackerNews/API API | Security | https://www.ycombinator.com/legal/ Legal | https://www.ycombinator.com/apply/ Apply to YC | Contact Search:

来源报道 · 1 篇 · 以下链接均前往原始媒体

newsnow::hackernews Launch HN:Vespper(YC F24)推出 SOTA Docx MCP 09-29 · 原文发布
← 返回精选动态 原文

更多内容