本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想要一个答案：2026 年 8 月 3 日这天，办公类 Agent 的竞争重心正式从"能不能生成"挪到了"能不能接进公司"。阿里把 QoderWork、MuleRun、悟空三款产品整合成「千问办公」（QwenWork）并开启公测，同日发布旗舰模型 Qwen3.8-Max（总参数 2.4 万亿、单 token 激活约 950 亿、上下文约 100 万 tokens）。这两件事叠在一起的意义是：模型侧解决了"长程任务不掉链子"，产品侧解决了"产物能落地、上下文能进组织"。对个人用户来说，最直接的变化是一句话需求可以直接换回一个可访问的网址、一份可编辑的 PPT、一段可分发的短片；对企业来说，最值钱的变化是把一位资深员工的工作方法固化成「组织级 Skill」，让新人第一天就能调用。

再补三个关键数字，方便你快速判断要不要投入时间：其一，千问办公个人版走积分制，免费版注册赠 2000 积分（90 天有效），个人标准版连续包月约 78 元/月含 2000 基础积分，个人高级版约 158 元/月含 4000 基础积分；其二，平台把模型分成经济、基础、高级、Qwen3.8-Max 四档，积分消耗倍率分别约为 0.1、0.25、1 和 1.1 倍；其三，第三方公开实测里，三到四个中等复杂度任务大约消耗 500 到 1000 积分。

我自己把这套东西从注册到跑通完整流程折腾了一遍，踩过的坑、算过的账、能用和不能用的边界，全部写在下面。想看完整拆解，往下翻。

一、先把事实对齐：2026 年 8 月 3 日这天到底发生了什么

写这类文章最怕的就是信息串台。网上关于千问办公的说法混得很厉害，有人说它七月就上线了，有人说八月才发布；有人说模型叫 Qwen3.8，有人说叫 Qwen3.8-Max，还有人管它叫 Preview 版。我先把时间线捋清楚，后面所有讨论都建立在这条线上。

1.1 两条并行的时间线

一条是模型线。2026 年 7 月 19 日，通义千问先放出了 Qwen3.8-Max-Preview，当时对外披露的信息很克制：2.4T 总参数、约 100 万 tokens 上下文、多模态，官方连完整的评测报告都没发，社区里跑分栏一片空白。它的分发渠道也不是常规 API，而是挂在阿里云百炼的 Token Plan、Qoder 编码工具和 QoderWork 办公端上，属于"先给一部分人用起来"的状态。

半个多月后，也就是 2026 年 8 月 3 日，预览版转正，正式版 Qwen3.8-Max 发布。这一版把规格说清楚了：稀疏 MoE 架构，总参数 2.4 万亿，单 token 激活约 950 亿，支持图像与视频输入，上下文窗口在官方云平台元数据里显示为 983,616 tokens（口径上称约 1M），最大输出长度 131,072 tokens。同时官方还宣布了一件在 Qwen 历史上算头一遭的事：Max 级别旗舰模型计划开放权重，配套的稠密模型 Qwen3.8-27B 也在开源计划里。

另一条是产品线。同样在 8 月 3 日，阿里旗下企业级 Agent 产品 千问办公（QwenWork） 开启公测。个人和企业用户都能通过官网 qwenwork.cn 体验，网页版和独立 PC 客户端已经开放，钉钉 PC 端和手机端的内置入口在陆续开放中。这个产品不是从零做的，它是 QoderWork、MuleRun、悟空 三款已有产品整合升级的结果，官方给的定位是"业内首款同时支持桌面端 Agent、云端 Agent、企业协同 Agent 的产品"。

所以准确的说法应该是：模型和产品是同一天官宣的两个东西，模型正式版进了产品的模型列表，产品又给模型提供了真实的落地场景。 素材里把它们混着讲，很容易让人以为是一个东西。

1.2 一张表把关键事实钉死

为了避免后面反复翻找，我把散落在各处的公开信息整理成一张速查表。这里说明一下，凡是标注"官方口径"的，都是发布会或官方文档的说法；标注"第三方"的，是媒体实测或社区整理，量级参考即可，不构成承诺。

这张表里我最想让你注意两行：一是 "思考档位不可关闭"。Qwen3.8-Max 是纯推理模型，没有"关掉思考走快车道"这个选项，默认还是最高的 xhigh 档，对应约 131,072 tokens 的思考预算。这意味着它天然更适合复杂任务，拿它去做"帮我改个错别字"这种活，成本效率是不划算的。二是 数据存储在境内。这一条对国内企业选型的权重，往往比跑分高得多。很多公司卡在 AI 落地上，卡的不是能力，是合规评审过不去。

1.3 素材里那些需要修正的说法

我在整理资料的时候，发现坊间流传的几个描述其实不太准确，这里顺手纠一下，免得你被带偏。

第一，"上下文原生 128K，无损扩展到 100 万"这个说法，在正式版的官方口径里并没有出现。官方直接标注的就是约 1M 上下文窗口，128K 对应的是最大输出长度和默认思考预算，两者是不同维度的参数，别混为一谈。

第二，关于模型档位，早期版本确实只有"基础、高级、经济"三档，但正式版发布后，模型列表里多了 Qwen3.8-Max 这一档，变成四档。倍率也随之明确了下来。

第三，关于产品能力，"扩展中心里已有 70 多个技能"这个数字是内测期间的快照，公测后技能市场是持续扩充的，不同时间点看到的数量不一样。看这类数字的正确姿势是看趋势和结构，而不是记住某个具体值。

第四，网上流传的一些演示网址（比如以 .qwenwork.host 结尾的临时域名）大多是实测者自己部署的样例站点，随着积分到期或者手动下线，随时可能访问不了。我这篇文章里不会引用这类临时链接，你要验证效果，直接去官网自己跑一个更靠谱。

二、Agent 的"最后一公里"：为什么"生成出来"不等于"能用"

2.1 先把 Agent 这个词讲清楚

术语先解释。Agent（智能体） 和聊天机器人的区别，不在于谁更会说话，而在于谁能自己动手。聊天机器人的输出终点是一段文字；Agent 的输出终点是一个"状态被改变了的世界"——文件被创建了、网页被部署了、待办被建好了、消息被发到群里了。

用一句更土的话说：聊天机器人交的是作业，Agent 交的是活儿。

这个区别听着简单，实现起来的难度差了一个数量级。因为交作业只需要一次生成，交活儿需要一长串动作：读文件、查数据、调工具、生成内容、自己验收、发现不对再改。每一步都可能失败，而失败会累积。

我用一个粗糙的模型来说明这件事有多难。假设一个任务需要连续调用 (n) 次工具，每次调用的成功率是 (p)，在不做任何容错的前提下，整条链路一次跑通的概率是：

[

P_{\text{success}} = p^{n}

]

代入数字你就明白了。假如单步成功率是 98%，听起来已经相当高了，但当 (n = 100) 时：

[

P_{\text{success}} = 0.98^{100} \approx 0.133

]

也就是说，单步 98% 的可靠性，在一百步的长程任务里只剩下不到 14% 的一次通过率。 这就是为什么过去一年那么多 Agent 演示看着惊艳、实际用起来处处卡壳。真正的工程解法不是把 (p) 无限逼近 1（做不到），而是引入自我校验和错误恢复，让失败的那一步能被发现、被重试、被绕过。这也是为什么各家都在强调"长程 Agent 能力"——它考的不是单点智商，是链路韧性。

2.2 横在真实工作流前面的三道坎

聊完技术层面，回到实际使用。我把办公 Agent 落地时最常见的障碍归成三类。

第一道坎：产物断链。

这是最容易被忽略、也最让人抓狂的一道。AI 给你生成了一个网页，一堆 HTML、CSS、JavaScript 代码整整齐齐躺在对话框里。然后呢？代码放哪儿？域名去哪儿买、怎么解析？后端服务谁来起？用户填了表单，数据存哪儿？页面挂了找谁修？

对一个前端工程师来说，这些都是十分钟能搞定的常规操作。对一个市场专员、一个律师、一个老师来说，这是一堵墙。结果就是，绝大多数所谓的"AI 生成网页"从来没有真正上过线，它们作为一段没有生命力的代码，永远躺在某段聊天记录里。

第二道坎：工具割裂。

做一份新品推广方案，正常流程是：在文档工具里写文案，去图片工具里生成配图，打开视频工具做素材，最后把所有东西搬进 PPT。流程本身不复杂，麻烦在于每换一个工具，你都要重新解释一遍背景、重新上传一遍资料、重新调一遍格式。

人在这个过程里扮演的角色，说难听点就是一个负责搬运上下文的快递员，在几个 AI 产品之间来回跑腿。效率工具真正该解决的，恰恰是"在一个地方把事情做完"。

第三道坎，也是最难的一道：组织上下文缺失。

这道坎决定了 Agent 的天花板。再强的通用模型，它也不知道你们公司谁向谁汇报，不知道上周项目群里那场争论最后达成了什么结论，不知道那个报销审批卡在了哪个环节，更不知道知识库里哪份模板是可以直接复用的。

它认识你，但它不认识你背后的那家公司。

所以绝大多数 Agent 的能力上限就停在"个人助理"这一层：它能让一个人跑得更快，却很难让整个组织转得更快。

2.3 数据不会说谎：热闹的另一面

上面三道坎不是我拍脑袋总结的，行业数据早就把这件事摆在台面上了。

Gartner 在 2025 年 6 月给过一个流传很广的预测：到 2027 年底，超过 40% 的 Agentic AI 项目会被取消，原因是成本失控、业务价值说不清楚、风险控制不到位。这份预测在 2026 年被反复引用，说明问题不但没缓解，还在持续发酵。Gartner 同时点出了一个更扎心的现象——大量厂商在做"agent washing"（智能体贴牌），把原本的助手和聊天机器人重新包装成 Agent，但并没有真正的智能体能力。按他们的估算，数千家宣称做 Agentic AI 的厂商里，真正名副其实的只有大约 130 家。

另一组数据来自 MIT NANDA 在 2025 年的一份报告。它指出，尽管企业在 AI 上砸了数百亿美元，但大多数收益仍然停留在个人提效层面，真正嵌入企业工作流的比例只有大约 5%。

这两组数据指向同一个结论：行业的瓶颈早就不在模型能力上了，而在"最后一公里"的工程和组织适配上。

2.4 用一张图看清楚差距在哪

我把"普通 Agent"和"企业 Agent"的执行链路画出来对比一下，差别一目了然。

flowchart TD
    A[用户提出需求] --> B[理解意图]
    B --> C[生成内容]
    C --> D{链路到这里结束了吗}
    D -->|普通 Agent| E[输出一段文字或代码<br/>剩下的交给人类]
    E --> F[人类手动部署<br/>手动搬运<br/>手动同步]
    D -->|企业 Agent| G[自动部署上线]
    G --> H[读取组织上下文<br/>群聊 文档 审批 日程]
    H --> I[结果回流到协作系统]
    I --> J[留下可追踪的执行记录]

    style E fill:#ffe0e0
    style F fill:#ffe0e0
    style G fill:#e0f0e0
    style H fill:#e0f0e0
    style I fill:#e0f0e0
    style J fill:#e0f0e0

红色那条路径就是绝大多数 Agent 目前的状态：九仞之山已经堆好了，就差最后一筐土，而这筐土还得人自己搬。 绿色那条才是真正把事情做完的样子。

千问办公这次瞄准的，正是把红色路径改造成绿色路径这件事。接下来我一层层拆它是怎么做的。

三、交付层：从"给你一段代码"到"给你一个网址"

3.1 全栈交付链路，是这次最实在的变化

我个人认为，千问办公在能力层面最值得说的一点，就是它把"HTML + 域名 + 数据库"这条链路收进了产品内部。

以前的流程是这样的：你描述需求，AI 吐代码，你复制代码，你找地方部署，你买域名，你配后端。中间那四步，被所有产品默认交给了用户。现在的流程是：你描述需求，AI 生成页面、接入数据库、完成部署，然后直接把一个可访问、可分享、能收集数据的线上链接交到你手里。

这一段的有无，对有技术背景的人可能只是省了十几分钟，但对没有技术背景的岗位来说，直接决定了 Agent 的产出是"素材"还是"成品"。

我自己拿一个真实场景验证过。任务是给一款虚构的智能保温杯做上市落地页，要求包含产品文案、场景配图、早鸟预约表单和一套完整的推广结构。整个过程我只提了需求，剩下的它自己安排工序：先写文案，再去生成视觉素材，然后把内容像搭积木一样拼成页面，最后在云端完成部署。几轮调整之后，交回来的是一个实实在在的网址。

这里有几个细节值得单独说。

表单数据是真能存下来的。 免费版不支持数据库存储，个人标准版及以上才开放这个能力，同时还支持给发布的网页设置访问密码。如果你打算用它做真实的信息收集，这一条是硬门槛。

发布数量有配额。 免费版可发布 5 个网页，个人标准版 10 个，个人高级版 50 个。做几个测试页够用，要批量铺落地页就得先算配额。

速度是短板。 第三方实测里出现过一个复杂电商演示站耗时超过一小时的情况。别指望它十分钟出一个完整站点，复杂交付就是慢，这是当前阶段的客观现实。

3.2 多模态一站生成：不用中途换工具

第二个变化是文档、图片、视频、音频的生成能力被放进了同一个任务上下文里。

这个设计的价值不在于"我也能生成视频"，而在于上下文不用重新交代。你给出一个目标之后，Agent 沿着已有的理解继续往下走，不需要每换一种内容形态就重新开一个对话、重新上传一遍资料。

举个通用化的例子。假设要给一款燕麦冷萃咖啡新品做上市传播，过去需要一个内容团队分工协作若干天：文案组写传播方案和预热稿，设计组出主视觉海报和配图，视频组剪宣传片，最后统一汇总。现在这些工序可以在一次任务里跑完——传播方案、预热文章、主视觉海报、多张传播配图、一条三十秒短片，一起交付。

我实际跑下来，感受最深的是它对平台差异的处理。生成的文案文档里，微信、微博、小红书三个平台的稿子是分开写的，语气、长度、话题标签的用法都不一样，不是同一份内容换个标题就完事。这说明它对"分发场景"是有认知的，而不是单纯地堆字数。

当然也别神化。AI 生成的视觉素材在"好看"和"可用"之间还有距离，尤其涉及品牌规范、字体授权、竞品避让这类细节，仍然需要人来把关。我的做法是把它当成高质量初稿生成器，出稿速度换来的时间，正好用在打磨上。

3.3 Office 产物：这可能是最高频的刚需

第三块能力是 PPT、Word、Excel、PDF 的直接生成与编辑。

这块听起来最不性感，却恰恰是使用频率最高的。第三方实测里，千问办公在财报 PPT 生成任务上完成度相当高，生成了多个可视化图表，数据准确、内容完整，耗时在七分钟左右。同一批测试里，网页生成任务耗时长得多。

这个反差其实很好理解：PPT 生成是结构化程度很高的任务，模板、版式、图表类型都有成熟范式；而网页生成涉及前端交互设计、部署、数据库连接，链路长得多，自然更慢。

我的经验是，Office 类任务放心用基础档模型跑，性价比最高；网页和复杂前端才值得上高级档或者 Qwen3.8-Max。这个策略在第九章算账的时候会展开。

顺便提醒一句，实测中出现过文档在跨工具转换时排版错乱、个别字符显示异常的情况。交付给客户或者领导之前，一定要自己打开确认一遍，别直接转发。

3.4 一个可复用的交付链路图

把上面三块能力串起来，实际的执行链路大概是这样：

flowchart LR
    A[一句话需求] --> B[任务拆解]
    B --> C1[文案生成]
    B --> C2[素材生成<br/>图片 视频 音频]
    B --> C3[数据处理<br/>清洗 分析 图表]
    C1 --> D[产物组装]
    C2 --> D
    C3 --> D
    D --> E1[Office 文件<br/>PPT Word Excel PDF]
    D --> E2[网页部署<br/>域名 数据库 密码]
    D --> E3[推送到协作系统]
    E1 --> F[可直接使用的交付物]
    E2 --> F
    E3 --> F

这张图和上一章那张对比着看，关键差别就在最右边：链路的终点不是"输出"，而是"交付物"。

四、底座拆解：Qwen3.8-Max 强在哪，又弱在哪

产品形态之下，最核心的一层永远是模型。这一章我把 Qwen3.8-Max 的公开信息拆开讲，同时说清楚哪些是官方口径、哪些还没被独立验证。

4.1 架构：2.4 万亿参数不是重点

先说一个容易被误读的数字。Qwen3.8-Max 总参数 2.4 万亿，这个数字很唬人，但它不是重点。

重点是单 token 激活约 950 亿参数。

这里要解释一下 MoE（Mixture of Experts，混合专家模型） 这个术语。你可以把它想象成一家有很多专业小组的公司：收到任务时，不是让全公司所有人一起上，而是只叫最对口的几个小组干活。2.4 万亿是这家公司的总人数，950 亿是每次干活实际出动的人数。

这种设计的意义在于：在扩大模型容量的同时，避免每次推理都动用全部算力。 它想同时要"脑容量大"和"跑得起"。

顺带说一句，我不太建议把参数量当成能力排名。对实际工作来说，任务完成率、错误恢复能力、工具兼容性、延迟和成本，这几项比总参数直接得多。一个跑分很高但工具调用经常出错的模型，在真实工作流里的表现可能还不如一个跑分平平但很稳的模型。

4.2 思考模式：三档强度，但关不掉

Qwen3.8-Max 是纯推理模型，不支持关闭思考。它提供 low / high / xhigh 三档强度，默认 xhigh，对应约 131,072 tokens 的默认思考预算。

这个设定有利有弊。好处是复杂任务的表现有保障，模型不会因为图快而草率作答；坏处是简单任务的成本和延迟都会被拉高——你让它算个百分比，它也要认真想一会儿。

我的应对方式很直接：简单任务根本不上 Qwen3.8-Max，在千问办公里切到经济档或基础档就行。把最强的模型留给真正需要它的场景。

4.3 官方公布的评测数字，以及需要保留的部分

阿里在发布会上公布了一批数据，我原样列出来，同时标注清楚状态：

这里必须泼一盆冷水。 截至目前，官方还没有发布完整的模型卡或技术报告来说明这些测试的具体方法和基准细节，独立第三方的复测结果也还在跟进中。有数据平台明确表示"暂缓录入结构化评测分数，待官方基准表公布后补充"。

所以正确的看法是：这些数字可以作为方向性参考，但不适合拿来做严格的横向对比。尤其是不同机构的自研基准，分数体系各不相同，直接比大小没有意义。

发布会还展示了几个长程任务案例：法律合同审查每小时处理 1284 条条款、量化研究中 6000 多个因子的回测，以及模型自主编程 16 天、在某开源项目上完成 265 次代码提交。这些演示的说服力在于时长和连续性，而不是单次输出的质量——它证明的是"能不能扛住长程任务"，恰好对应第二章那个 (p^{n}) 公式指向的核心难题。

4.4 价格：把缓存吃透，成本能砍一半

国内 API 定价是输入 12 元、输出 36 元（每百万 tokens），隐式缓存命中价格 1.5 元每百万 tokens。国际定价官方给的是相对口径，大致相当于对标海外顶级模型输入价的 40%、输出价的 24%。

这里有个很实用的推论：缓存价格只有输入价的八分之一。 如果你的场景里有大量重复前缀（固定的系统提示词、固定的知识库片段），把它们放在提示词开头、保持前缀稳定，就能显著吃到缓存红利。成本可以这样估算：

[

C_{\text{total}} = \frac{T_{\text{in,miss}}}{10^{6}} \times 12 + \frac{T_{\text{in,hit}}}{10^{6}} \times 1.5 + \frac{T_{\text{out}}}{10^{6}} \times 36

]

其中 (T_{\text{in,miss}}) 是未命中缓存的输入 token 数，(T_{\text{in,hit}}) 是命中缓存的部分，(T_{\text{out}}) 是输出 token 数。

举个例子。假设一个任务输入 20 万 tokens，其中 16 万命中缓存，输出 3 万 tokens：

[

C = \frac{40000}{10^{6}} \times 12 + \frac{160000}{10^{6}} \times 1.5 + \frac{30000}{10^{6}} \times 36 = 0.48 + 0.24 + 1.08 = 1.80\ \text{元}

]

如果完全不走缓存，同样的输入要花 2.4 元，加上输出就是 3.48 元。一个稳定的提示词前缀，能把成本压掉将近一半。 这是我做接口集成时最先优化的一项。

4.5 开源计划：宣布不等于落地

官方宣布 Qwen3.8-Max 的权重计划开放，这在 Qwen 的 Max 级别旗舰里是第一次；同时预告了 Qwen3.8-27B 也会开放权重。

但要保持一个基本的判断边界："宣布下周开放"和"权重已经能下载"是两回事。 许可证类型、量化版本、部署工具链、实际显存需求，这些都要等仓库文件真正出现之后才能下结论。

而且从实用角度看，2.4T 总参数的 Max 版主要面向大型集群，个人和中小企业基本不用考虑本地部署。真正有可能落到工作站和私有化环境里的，是 27B 那个稠密版本。如果你所在的组织有私有部署诉求，值得盯着的是后者而不是前者。

4.6 原生多模态：办公场景里的实际价值

Qwen3.8-Max 支持文本、图像、视频输入。这个能力放在办公场景里，价值比想象中大。

原因很简单：办公室里的原始材料本来就是乱的。 一张手机拍的白板照片，一段会议录音，一份别人发过来的扫描版 PDF，一个客户随手录的产品演示视频。过去处理这些东西，第一步永远是"转成纯文本"，而这一步本身就会丢信息——白板上的箭头指向、PDF 里的表格结构、视频里的时序关系，转成文本之后全没了。

原生多模态的意义就是这些东西可以按原样丢进去。模型直接看图、直接读版式、直接理解时序，中间不用经过一道有损转换。

我实际用下来体感最强的是处理带表格的 PDF。以前要么手动整理，要么用识别工具再修一遍错；现在可以直接扔进去让它读。当然扫描质量太差的情况下还是会出错，这个要有心理预期。

辛梓煜@词元二号站在测试时的一个小习惯：凡是丢原始材料进去，我都会在提示词里加一句"如果材料中有你无法确认的部分，请明确标出来，不要猜"。这一句话能挡掉相当一部分幻觉。

五、百万上下文不是数字游戏：它到底改变了什么

上下文长度是这一代模型最容易被当成营销话术的参数。一百万 tokens 听起来很吓人，但很多人并不清楚它换算成日常工作是多少东西。这一章我把它落到地上。

5.1 先做一次换算

上下文窗口（context window） 指的是模型一次能读进去并保持在"工作记忆"里的信息总量，单位是 token。中文的换算比例大致是一个汉字约占 1 到 1.5 个 token，英文单词平均在 1.3 个 token 左右。取一个偏保守的估计：

[

N_{\text{汉字}} \approx \frac{N_{\text{token}}}{1.3}

]

代入 983,616 这个实际元数据：

[

N_{\text{汉字}} \approx \frac{983616}{1.3} \approx 756{,}600

]

也就是七十多万个汉字。这是什么概念？

结论很直白：日常办公里绝大多数"一整批材料"，现在可以一次性丢进去。

5.2 长上下文改变的不是容量，是工作方式

容量只是表象，真正的变化在方法论层面。

过去处理长材料的标准做法叫分块摘要：把长文档切成小段，每段生成摘要，再把摘要拼起来做二次总结。这套方法的问题是跨段关联会丢失。合同第 3 条的定义和第 47 条的责任条款是有勾连的，切开之后模型看不到这层关系；一年运营日志里三月份的异常和十月份的复发是同一个根因，分块之后也串不起来。

一次性放进去，这些跨段关联才有可能被发现。

我拿一份虚构的年度运营台账做过对比测试。分块摘要模式下，模型给出的是十二个月份各自的情况总结；一次性投喂模式下，它主动指出了"第二季度和第四季度出现了两次特征相似的波动，可能来自同一个上游因素"。这个洞察在分块模式下是不可能出现的。

5.3 但也别把长上下文当成完美记忆

这里要说一句可能不太受欢迎的话：上下文窗口大，不等于模型能完美记住里面的每一个细节。

业内早就观察到长上下文的"中间遗忘"现象——放在开头和结尾的信息召回率高，埋在中间的信息容易被忽略。窗口越长，这个问题越明显。

所以我的实操习惯是：

第一，重要的约束放两头。 关键要求写在提示词开头，验收标准写在结尾，中间放大段材料。

第二，给材料加锚点。 上传多份文件时，在提示词里明确编号和用途，比如"文件 A 是合同正文，文件 B 是附件清单，回答时请标注引用来源"。有锚点，模型定位起来准得多。

第三，长任务分段验收。 别指望一次提问就拿到完美答案，先让它输出一个结构化的中间结果（比如一份要点清单），确认无误再往下走。

5.4 长上下文和长程 Agent 是两件事

这两个概念经常被混在一起，其实完全不同。

长上下文解决的是"一次能看多少"，是空间维度；长程 Agent 能力解决的是"能连续干多久不掉线"，是时间维度。

一个真正的交付型任务，往往要连续调用几十甚至上百次工具：读文件、查数据、画图、生成、校验、再修正。链路越长，中途出错的概率越大——这就是第二章那个概率公式说的事。

长上下文对长程任务是有帮助的，因为 Agent 的执行记录本身就会不断膨胀，窗口不够就得压缩历史，压缩就会丢信息，丢信息就容易出错。但窗口大只是必要条件，不是充分条件。真正决定能不能扛住长程任务的，是模型在工具调用、自我校验、错误恢复上的工程能力。

这也是为什么各家发布会都开始演示"连续工作十几天""提交几百次代码"这类案例——大家心里都清楚，跑分能刷，长程稳定性刷不出来。

六、连接器与 IM 频道：让 Agent 拿到"组织上下文"

这一章是我认为整个产品设计里最关键的一层。前面讲的交付能力，说到底是"把活干得更漂亮"；而这一层要解决的是"让 Agent 知道公司是怎么运转的"。

6.1 两类入口，解决两个不同的问题

千问办公给出的方案是两类入口并行。

一类是连接器（Connector），负责让 Agent 去调用不同的软件、数据库和信息源。它的角色是"手"——伸出去够到外部系统。

另一类是 IM 频道，让 Agent 直接进入员工每天在用的群聊和沟通平台。它的角色是"耳朵和嘴"——听得到讨论，也能把结果说回去。

这两者缺一不可。只有连接器，Agent 是个躲在角落里的工具人，你得专门去找它；只有 IM 频道，它能听见热闹但干不了实事。两个凑齐，它才像个能参与协作的同事。

6.2 连接器覆盖了哪些东西

从公测期的连接器市场看，覆盖面已经相当广：

这里要提醒一句：上面这份清单里有相当一部分是面向海外用户的工具，在国内的日常办公环境里未必能顺畅使用，选型时应当以钉钉、飞书、企业微信这类国内协作平台为主，海外工具按实际业务需要评估。清单本身反映的是产品的开放度，不代表每一项对你都适用。

另外，浏览器连接器和计算机控制这两项要格外谨慎。开启浏览器连接器意味着 AI 会在你已经登录的浏览器里执行操作，它能看到什么、能点什么，边界并不总是清晰的。官方帮助文档也建议在专用的浏览器配置文件里使用，避免涉及高敏感系统。我自己的做法是单独建一个浏览器配置，只登录必要的测试账号，绝不在主力浏览器上开。

6.3 IM 频道：把 Agent 拉进群

IM 频道这块，目前支持钉钉、飞书、Lark、微信、企业微信、Slack 和 WhatsApp。

配置完成之后的效果是：员工不必专门打开千问办公，直接在原有群聊里提出任务，Agent 就能接收消息、回复问题并参与协作。

这个设计的价值在于降低使用门槛到接近于零。推行任何新工具，最大的阻力永远是"又要多开一个软件"。而在群里 @ 一下就能用，阻力小得多。

6.4 钉钉为什么是重点

千问办公把钉钉当作进入企业工作场景的核心入口，这个选择不难理解。

在企业授权范围内，它可以连接群聊、消息、日程、待办、文档、知识库、审批、考勤、AI 听记、AI 表格这一整套模块。换句话说，一家公司沉淀在钉钉上的组织关系和工作记录，摇身一变成了 Agent 的上下文。

我举两个具体到能直接抄的场景。

场景一：周报自动化。 周五下午，把这一周的钉钉会议记录、待办列表、目标进度、审批信息一股脑丢给它，让它生成一份结构清晰的周报，再自动归档进企业知识库。以前这活儿要花一两个小时翻记录、拼素材，现在剩下的主要是核对和补充判断。

场景二：考勤异常提醒。 让 Agent 基于考勤记录和请假表，识别未打卡等异常情况，生成适合发到群里的提醒文字，并创建一个次日上午用于检查补签审批的待办。

第二个场景我特别想展开说说。识别考勤异常这件事，技术难度真不高，Excel 加个公式就能做。麻烦全藏在后续动作里：信息要发到哪个群，提醒用什么语气才不得罪人，第二天几点检查，谁负责确认补签，结果要不要写进待办。

普通 Agent 写完一段提醒文案，任务就结束了。企业 Agent 还要把文案送到正确的群，在正确的时间创建待办，并留下一条可以追踪的执行记录。这就是"个人助理"和"组织同事"的分界线。

6.5 定时任务：把重复劳动交出去

和连接器配套的还有一项能力：定时任务。

企业日常运营里最耗时间的，往往是那些机械的常规活儿——周期性的市场信息监控、数据汇总、部门汇报。这类工作可以配置成一次性、定时或者固定间隔执行的任务。

一个很典型的配置：设定每天上午九点自动抓取指定平台上关于某个赛道的公开信息，生成趋势简报，推送到指定的钉钉群。不用专人催办，不消耗跨部门沟通成本。

关键是这些任务在云端执行，关掉浏览器、退出登录之后仍然继续跑。这一点很重要，否则所谓的"定时"就变成了"我得开着电脑等着"。

6.6 深度接入的另一面：权限和边界

讲完好处，必须讲代价。

AI 能做的越多，企业对可控性和安全性的依赖就越强。 一个能读群聊、能看审批、能建待办的 Agent，本质上是一个拥有内部权限的账号。这带来几个必须提前想清楚的问题：

• 权限颗粒度够不够细？能不能做到"只读不写""只看本部门"？
• 执行记录是否完整可追溯？出了问题能不能定位到是哪一步、由谁触发的？
• 敏感系统怎么隔离？财务、人事、客户数据这类，要不要一律走只读或沙箱？
• 数据落在哪里？官方明确说明用户内容和相关数据存储在中国大陆境内的云环境中，除非获得明确授权或依据法律法规要求，数据不跨境。这一条对国内企业的合规评审很关键，但具体到自己公司，还是要走一遍内部的数据安全评估流程。

我的建议是分阶段接入：先接钉钉工作台这类相对可控的场景，跑顺了再按需接入自建系统；对高敏感系统一律采取只读或沙箱策略，别一上来就全线放开。

七、Skill 与专家套件：把一个人的经验变成一群人的能力

如果说连接器解决的是"Agent 能碰到什么"，那么 Skill 解决的就