月末，财务同事拿到一个文件夹：30 张发票 PDF。要求汇总每张发票的发票号、开票日期、销售方、价税合计，再按供应商和月份分组统计，最后输出一张明细表。
在 V1.1，AetherPDF 的 AI 已经能很好地处理“一份文档”：提取文本、回答问题、编辑内容、操作表单。但面对这个任务，它无能为力。用户只能把同一段提示词重复 30 遍、开 30 次对话，再把 30 段结果自己抄进表格。
这不是个别需求。整理一批合同、审阅一组标书、给一套扫描件批量盖章——“多个文档、一个目标”，才是真实工作里的常态。
把这类任务拆开，会看到四个反复出现的痛点：
- 批量任务没法做：AI 一次只能看到一个文档；
- 复杂任务没有分工：所有步骤挤在一个对话里，上下文越来越长，又慢又容易出错；
- 可重复的流程每次重新教：同样的汇总步骤，下个月还得从头描述一遍；
- 关键信息每次重新输入：“我们是一般纳税人，税率 6%”这句话，用户已经说过无数遍。
V1.2.0 的核心工作，就是对这四个痛点的系统回答：多文档 AI 会话、多 Agent 协作、技能系统、记忆系统。这次更新包含 24 个提交、80 个文件、约 19000 行新增代码，其中最大的增量是一套全新的 C++ 多智能体引擎。
下面从使用视角逐个展开。
多文档 AI 会话：批量任务的第一块拼图
V1.2.0 新增了多文档 AI 会话：把整个文件夹拖进工作区，然后像和同事说话一样下任务——“把这批发票按供应商汇总金额”。
听起来简单，背后要解决两个工程问题。
第一，上下文里放什么？ 30 个文档的文本不可能全塞进对话——几千页内容会瞬间击穿模型的上下文窗口，而且绝大多数和当前任务无关。
我们采用渐进披露：文件列表始终完整可见、可检索，但注入给模型的只有清单本身；当任务需要某个文档时，才把它的内容交给对应的处理单元。上下文永远只装“正在用的那一份”。
第二，大文件夹怎么撑住？ 有用户的工作区是上万文件的目录。一次性扫描再渲染列表，主线程直接卡死。V1.2.0 把目录扫描整体后台化——扫描结果通过“收件箱 + 排水泵”的节奏分批回流到界面，用 generation 计数让过期批次自动作废；列表本身也换成了视图回收机制，滚动不再随文件数量恶化。结果是：万级目录打开即响应，扫描在后台悄悄完成。
另外，长会话不必霸占前台。多文档会话可以切到后台继续跑，用户回到正常编辑工作，随时切回查看进度——AI 任务和人的工作真正并行了。
多 Agent 分工：复杂任务的效率引擎
有了多文档入口，下一个问题是：30 张发票的汇总任务，到底谁来干？
如果只靠一个“超级对话”顺序处理 30 个文档，上下文会越滚越大，速度越来越慢，中途任何一步出错都会污染后面所有步骤。
V1.2.0 的答案是分工：采用 Master–Sub Agent 两层架构——
- 主智能体（Master Agent）：不直接碰文档，负责理解目标、拆解任务、派出子代理、汇总结果；
- 子代理（Sub Agent）：每个子代理绑定一个文档，拥有专属的文档工具集（提取、检索、编辑），工具面互相隔离——A 文档的子代理碰不到 B 文档。
对用户来说，分工过程完全透明：界面上能看到每个子代理的实时状态与产出，谁在提取第几张发票、谁已经完成，一目了然。
并发的克制。 主智能体可以按需派出子代理，但同时活跃的子代理数上限是 3。这不是产品限制，而是对后端服务承载的诚实评估。超限时，派生请求会收到一个结构化错误：
{ "error": "max concurrent sub agents reached (3)" }关键在于这个错误是还给模型的：主智能体会自行决定排队等前面的子代理完成，还是向用户说明情况——而不是静默失败。引擎侧保留了并发上限的设置接口，后端扩容后，放开只需要改一个数字。
长任务的记性与去处。 30 个文档的任务动辄几分钟，中间断了怎么办？我们提供了两个机制：
- 任务账本（task scratch）：子代理每完成一张发票，就把进度写入共享账本；主智能体随时核对“已完成张数与总张数是否一致”，中断后也能从账本续跑，而不是从零开始；
- 产物目录：汇总表输出到哪里？AI 会主动询问；用户选定后通过安全书签（security-scoped bookmark）持久化授权，下次会话依然有效——在沙箱环境里，这是“AI 能持续往同一个文件夹写结果”的前提。
Skills：把教过的流程变成可复用资产
多文档和分工解决了“这一次怎么做”，但下个月再来一批发票呢？用户还得把汇总规则重新描述一遍。
V1.2.0 的技能（Skills）系统，就是让“教过 AI 的流程”沉淀下来。一个技能的本质很朴素：一份自然语言的操作手册 + 一份参数协议：
{
"id": "invoice_amount_summary",
"name": "发票金额统计汇总",
"description": "从多张发票 PDF 提取金额、日期、供应商，汇总为结构化统计表",
"instructions": "1. 用 pdf_get_page_text 提取全文；2. 定位发票号、开票日期、销售方、价税合计；3. 以 JSON 输出……",
"inputs": [
{ "name": "date_range", "type": "string", "description": "可选：按日期范围过滤" }
]
}instructions 不是代码，是写给 AI 看的步骤；inputs 是参数协议——同一技能既能处理“上个月所有发票”，也能处理“2025 年 Q1 的”，差别只在调用参数。技能创建后，用户下次只需要说：“用发票汇总技能处理这个文件夹。”
渐进披露：省 token 的三级设计。 技能可能有几十个，把全文都塞进系统提示词既贵又吵。我们采用三级披露：
- 系统提示词里只注入清单（名称 + 一句话描述）——AI 知道“有什么”；
- 需要了解细节时，调用
skill_get读全文； - 确认匹配后，
skill_execute取回步骤并逐步用常规工具执行。
大部分对话停留在第一级，只在真正使用时才付出全文的成本。
技能也是可以被管理的。 V1.2.0 提供完整的技能管理窗口：独立编辑弹层（参数协议以 JSON 编辑、实时校验）、导入/导出（导入时做内容去重——完全相同的跳过，有差异的自动换新 id 保存，不会覆盖你的资产）、启用/禁用（禁用的技能既不注入提示词，也无法被执行，从所有渠道“消失”）。甚至 AI 自己在对话中就能创建和修订技能——用户口述流程，AI 落成技能，下次直接复用。
记忆：关键信息只说一次
“我们是一般纳税人，税率 6%，发票抬头是 XX 信息技术有限公司。”——这句话不该有第二遍。
V1.2.0 的记忆系统把“该记住的信息”分成三类，边界写死：
| 记忆类型 | 内容特征 | 生效范围 |
|---|---|---|
| 全局用户记忆 | 税率、公司抬头、输出偏好 | 所有会话，每轮注入 |
| 会话记忆 | 当前这单任务的上下文约定 | 仅本会话 |
| AI 工作笔记 | AI 在长任务中自己记的中间结论 | 随任务生命周期 |
边界写死意味着：AI 的临时工作笔记绝不会污染你的全局偏好；会话里聊的临时约定，也不会泄露到下一个客户的任务里。
记忆同样有管理窗口：逐条启停、随时编辑。禁用一条记忆和禁用一个技能语义一致——从所有注入渠道消失。控制和透明，是记忆系统的设计底线：AI 记住了什么、为什么记住、什么时候用，用户全程可见、可改、可撤销。
场景串联：四个能力如何一起工作
单独看每个能力都是一个点，合在一起才是 V1.2.0 想交付的完整体验。
案例 A｜财务批量汇总（30 张发票）
文件夹拖入 → 技能清单里出现「发票金额统计汇总」→ 一句话触发。主智能体派出子代理分批提取，每个子代理只读自己那几张；每完成一张就写任务账本；全部完成后汇总校验“账本张数 = 实际张数”，输出到用户指定的产物目录。整个过程用户只需要开始，和等待。
案例 B｜合同审阅（一批标书）
把公司的红线条款存进全局记忆（“违约金上限 20%”“必须约定仲裁地”）；把审阅套路固化成「合同审阅清单」技能。之后每来一批合同：选技能 → 子代理逐份并行审阅 → 输出风险点清单。规则更新时只改记忆，流程更新时只改技能。
案例 C｜长报告后台跑
200 页行业报告的深度分析，不必守着进度条。切到后台，继续编辑手头的文档；分析结果落在产物目录，标题栏里会话名早已由 AI 自动总结好，回来看一眼就知道哪份是哪份。
数字与展望
回过头看，V1.2.0 之前，AetherPDF 的 AI 是“一个很会聊天的单文档助手”；V1.2.0 之后，它是一个能同时看多份文档、会分工、记得住事、把流程沉淀为资产的工作台。
这次更新的支撑工程同样值得记录：长会话的两层历史治理（工具结果压实 + 工作笔记出上下文）解决了超长任务的请求超限；气泡懒加载与后台解析让万条消息的会话依然流畅；此外还修复了 XRef Stream 解析偏移、CID 字体渲染乱码、解析器无限递归等多个底层引擎问题。
往前看，我们正在对工具面做系统性的合理性与充分性评估，让 AI 使用工具的每一步更稳、更准；后端扩容后，子代理并发上限会随一个数字放开；技能的导入/导出格式已经就绪——把好流程分享给同事，是下一步自然会发生的事。
30 张发票只是开始。真正的目标是：凡是重复的，都该有技能；凡是重要的，都该被记住；凡是批量的，都值得同时进行。
AetherPDF V1.2.0 已发布，欢迎升级体验。
附：关于 agent 架构的必要性
如果你读完想问：“为什么这些功能是必须的？”——这里有一份简短的回答。
一个能处理真实工作流的 agent，需要具备四个基础能力。它们不是可选的功能，而是架构上的必要条件：
| 能力 | 解决的问题 | 没有它会怎样 |
|---|---|---|
| 多文档会话 | 任务涉及的输入不止一个文档 | agent 只能在单文档内工作，批量任务无法启动 |
| 多 Agent 分工 | 长任务的上下文和成本会失控 | 单会话串行处理，越跑越慢，中途出错全盘污染 |
| 技能系统 | 重复流程需要可复用 | 每次任务都要重新描述，用户负担不会降低 |
| 记忆系统 | 关键信息需要跨会话持久 | 同一个偏好说一百遍，agent 始终是“第一次见你” |
把这四个能力组合起来，agent 才从一个“对话界面”变成一个“工作系统”。
AetherPDF V1.2.0 做的，就是把这四个基础能力补齐。