xAgent 的目标不是把文件简单塞进对话框，而是让 Agent 能在服务端持续处理任务。对于会议记录、合同、报告、表格、演示文稿和业务资料来说，文件是否能被正确识别、定位和复用，直接决定后续任务是否可靠。

本版本仍为测试版。以下内容面向准备部署或升级的用户说明，不替代正式安装与升级指引。

文件与附件：先确认文件可用，再交给任务​

0.0.6.beta 统一了会话附件与工作区文件的接收流程。文件只有在格式、大小和内容解析都通过后才会被正式接收；失败的上传不会留下看似存在、实际无法使用的记录。

当前支持 DOCX、可提取文本的 PDF、PPTX、XLSX、CSV、TSV、静态 HTML、Markdown、常见文本和代码文件，以及 PNG、JPEG、WebP 图片。上传限制也改为按文件类型和入口分别处理，在保存前给出明确错误，而不是使用一个统一的大小上限。

对长文档，xAgent 不再把全部内容一次性塞入上下文。较小的文本文件可以直接完整读取；较长的文档会提供结构化定位信息，让 Agent 按需读取相关页、工作表、幻灯片或区段。这有助于保留上下文，也让模型更容易回到原始材料的正确位置。

Word 和 HTML 会尽量保留标题、段落、强调、列表、链接和表格结构；PDF、表格和演示文稿会保留页、工作表和幻灯片定位。该版本还修复了部分工作区文件显示存在但无法读取，以及中文或空格文件名下载异常的问题。

GIF、旧版 Office 格式、加密文档，以及没有文本层的纯扫描 PDF 暂不支持上传。

Word 文档：从内容完成到交付前验证​

这版新增内置 Word 模板库和默认模板。生成文档时可以使用内置模板或用户提供的模板，并保留模板中的样式、页眉、页脚和占位符。

生成流程也做了调整：先完成内容框架和全文，再一次性创建文档，减少反复修改造成的排版漂移。交付前会进行 DOCX 转 PDF 和逐页图片渲染验证，检查分页、字体、间距、表格、页眉页脚和文本裁切等常见问题。

同时，xAgent 新增共享字体资源能力。首批内置 Noto Sans SC、Noto Serif SC 与 Noto Sans Mono CJK SC；管理员也可以补充本地字体，或登记具备大小和完整性校验的内部在线字体。

子会话：减少启动协作时的额外步骤​

创建子会话时，xAgent 会自动完成初始化编排，根据任务选择合适的 Agent 与可用能力。这一初始化不再额外要求用户审批，减少开始协作前的等待。

本版也优化了能力合并与去重，避免重复加载同一 Tool；子会话能够识别当前协作请求并完成回复，已经完成的委派任务不会因为后续处理而被重复执行或重复发送结果。

模型与运行环境：减少配置和执行中的隐性问题​

连续会话中的模型请求缓存更加稳定，减少不必要的缓存失效。OpenAI、Anthropic 和 Gemini 的配置兼容性得到完善；新增、修改、切换默认模型或删除配置后，变更可以更快生效。

CLI 侧，Python 依赖安装到用户级共享目录，同一用户的不同会话可以复用已安装依赖，同时内置运行资源保持只读。相对路径按照命令工作目录解释，需要引用工作区根路径时使用 $XAGENT_WORKSPACE。

执行输出在返回 Agent、历史记录和界面前会隐藏宿主机与临时目录，显示稳定的逻辑路径。CLI 也默认启用管道失败检测，并加强失败原因分析、有效重试和结果验证，减少错误被掩盖后反复执行的问题。

升级与数据清理​

对于受支持的托管安装，控制台发现新版本后可以直接发起升级：系统下载、切换并重启；健康检查失败时会自动回滚。旧版 OpenAI 模型配置会在升级时适配当前类型，并尽量保留原有连接参数和模型设置。

历史文件迁移也更稳健：单条损坏或无法识别的旧文件不会阻断服务启动。用户格式化数据时，会更完整地清理触发器、会话、附件、工作区和相关运行数据；现有登录状态会失效，重新登录后会创建新的主会话。账号、模型用量和明确保留的外部连接信息不会受到影响。

准备升级​

升级前请先备份运行目录、配置、数据库和 Connector 状态。安装与升级步骤见更新日志和开始安装。

欢迎通过 Issue 反馈部署、文件处理、模型配置或连接器接入中的问题。

本文不讨论某个具体模型，而是解释个人电脑和服务器部署分别适合什么场景，以及为什么团队长期使用 Agent 时通常需要服务端运行方式。

两种部署方式的核心区别​

个人电脑部署的 Agent 跟着一个人、一台设备和一个本地环境走。服务器部署的 Agent 则作为长期在线服务运行，用户通过 Web 或已授权的 IM 连接器提交、跟进和确认任务。

没有哪一种方式天然更好。关键在于任务是否需要持续运行、是否涉及多人共享、文件是否需要集中管理，以及外部操作是否需要有明确边界。

什么时候个人电脑就够了​

下面这些情况，个人电脑运行通常已经足够：

• 只是个人试验模型、提示词或自动化想法。
• 任务在几分钟内完成，电脑通常不会离线。
• 不需要把任务材料交给其他人复用，也不需要统一保存结果。
• 不需要长期连接企业系统、消息渠道或定时触发器。

这类场景的优势是启动快、环境直观，代价是任务和配置容易绑定在某一台设备上。

什么时候应该放到服务器​

一旦出现以下任一情况，就应认真考虑服务器部署：

任务不能依赖用户电脑在线​

资料整理、长文档分析、报告生成、周期性检查和等待外部回复的任务，不应因为用户合上电脑就中断。服务端运行让用户可以离开页面，之后再回来查看进度和结果。

团队不希望每个人都重复配置​

团队通常需要一组经过验证的模型、Skill、Tool、MCP、连接器和审批策略。管理员准备这些基础能力后，普通用户只要提交目标和材料，不需要从头理解每一个模型参数、工具协议或权限细节。

文件和结果需要集中管理​

任务会产生输入材料、中间文件和最终结果。把这些内容留在服务端工作区，能让会话持续引用同一份材料，也便于用户之后查看、下载或继续处理。

集中不等于所有人都能看到所有文件。xAgent 对工作区有独立的可见性与访问边界：用户和其下的 Agent 会话只能通过 xAgent 允许的逻辑路径读写文件，并不是直接浏览宿主机目录。

外部动作需要审批与留痕​

当 Agent 要发送消息、修改外部数据或调用具有影响力的工具时，团队往往不希望完全依赖“模型自己判断”。服务端部署可以把模型、连接器、审批策略和运行记录放在同一套治理范围内处理。

服务器部署也不是“零配置”​

服务端运行并不会自动解决所有问题。部署方仍然需要决定：

1. 使用本地模型、自有模型网关还是第三方模型 API。
2. 哪些用户可以访问服务，公网入口如何通过 HTTPS 和网络策略保护。
3. 哪些 MCP、连接器和外部系统可以接入，以及分别使用谁的授权。
4. 哪些高风险操作需要审批。
5. 如何备份运行目录、配置、数据库和 Connector 状态。

私有化部署的价值是把这些选择留给部署方，而不是让它们分散在每个用户的电脑里。使用第三方模型 API、MCP 或外部系统时，数据仍会按照对应服务的规则流转；部署在自己的服务器上并不意味着所有数据天然不会离开环境。

一个适合起步的路径​

不需要一开始就接入所有系统。更务实的做法是：

1. 在长期在线的服务器上安装 xAgent。
2. 先接入一个支持工具调用的模型。
3. 用非敏感材料完成一个可以检查结果的小任务。
4. 验证文件处理、工作区、审批与备份。
5. 再按真实需求接入 MCP 或连接器，并逐步开放给更多用户。

这样能先确认任务链路是否可靠，而不是把全部复杂性集中到第一次部署。

下一步​

• 阅读如何在自己的服务器上部署 AI Agent。
• 按开始安装完成服务端部署。
• 了解xAgent 如何隔离多用户工作区与任务进程。
• 查看审批策略，为外部操作设置底线。

简单说，MCP 更接近“任务执行时可调用的工具”；连接器更接近“带着用户身份、消息和事件进入系统的双向通道”。把两者区分清楚，才能避免把账号授权、消息入口和工具调用混在同一层。

先看一个实际任务​

假设员工希望 Agent 每天整理客户邮件，提取待办事项，并把结果发送到团队群里。

这个任务至少有三类动作：

1. 接收或读取邮件。
2. 分析邮件内容并生成待办事项。
3. 把结果发送到指定消息渠道。

如果邮件系统或消息渠道要主动把新消息推给 xAgent，并且需要绑定每个用户自己的账号或授权，连接器更适合承担这条通道。如果 Agent 在任务执行过程中需要按需搜索、查询或调用某项外部服务，MCP 更适合作为可发现、可加载的工具来源。

它们可以共同存在：连接器负责让任务和授权进入 xAgent，MCP 或系统 Tool 负责在任务运行时提供操作能力。

MCP：任务需要时取用的工具​

MCP 的重点是让 Agent 在已经开始处理任务后，按需调用外部能力。例如查询资料、读取某个业务系统的数据、创建记录，或者运行一项专用操作。

从任务视角看，MCP 解决的是：

“为了完成当前任务，我还需要调用什么能力？”

它适合被模型发现、加载并在当前上下文中调用。并不是每个会话一开始都要加载全部 MCP 工具，xAgent 会根据任务和可用状态按需发现能力，以减少无关上下文。

但 MCP 本身通常不负责持续接收外部系统主动发来的消息，也不天然表达“这个动作代表哪个用户的已有账号”。这些是连接器更关注的事。

连接器：用户身份、外部事件与双向通道​

连接器的重点不是单次工具调用，而是把外部系统与 xAgent 之间的用户连接长期维护起来。

从产品视角看，它解决的是：

“谁以什么身份接入？外部系统发生新事件时，如何主动送进来？处理结果如何回到原系统？”

连接器可以负责用户认证、会话或通道状态、接收外部消息和文件、把结果写回原系统，并告诉 xAgent 当前可以使用哪些能力。微信、Telegram、飞书，以及未来的企业内部系统，都是这一类需求。

外部系统的真实数据权限仍然由外部系统自己的账号和授权控制。xAgent 的审批策略控制的是“xAgent 是否应该执行某个动作”，不替代 CRM、邮箱、IM 或其他系统本身的数据权限。

选择时不必二选一​

可以用下面这个判断方式：

实际系统中常常是“连接器 + MCP + Skill”的组合：连接器维护用户连接和事件入口，MCP 提供业务工具，Skill 把这些能力组织成面向用户的任务方法。

不要把授权边界交给模型猜测​

无论选择 MCP 还是连接器，都不应把外部系统权限简单交给模型自行判断。至少要明确：

• 连接使用谁的账号和授权。
• 哪些操作只读，哪些会改变外部数据。
• 哪些动作必须经过用户或管理员审批。
• 连接失效、凭据过期或健康检查失败时如何处理。

xAgent 将这些问题拆开处理：连接器维护连接与认证状态，工具提供可调用能力，审批策略决定 xAgent 是否放行操作，而外部系统仍保留最终的数据权限判断。

下一步​

• 阅读什么是连接器。
• 查看连接器使用手册。
• 查看Tool 管理，了解个人、公共、MCP 与连接器工具如何显示。
• 阅读Agent 审批与安全控制。

这个问题不应该回答成“xAgent 比它们都强”。它们解决的问题并不相同。选型时最重要的不是比较谁的模型更聪明，而是先明确：谁在使用、任务在哪里运行、是否涉及多人和业务系统，以及谁来承担安全与运维责任。

先说结论：xAgent 是团队专用 Agent 的服务端基座​

xAgent 不是要替代所有 Agent，也不是一个以聊天陪伴为目标的个人应用。它部署在服务器端，面向团队把专用 Agent 用在持续的具体任务上。

管理员先准备模型、Skill、Tool、MCP、连接器和安全策略；普通用户不需要从头理解每项配置，只需要描述目标、提供材料、确认关键动作并查看结果。任务在服务端执行，不依赖用户电脑始终在线。

因此，xAgent 的核心问题是：

团队如何把经过配置和治理的 AI 能力，稳定交给多位用户处理真实工作？

如果你的主要需求是个人快速试用一个现成助手，或者只想在代码仓库里完成开发任务，其他产品可能更直接。

用产品目标而不是“强弱”比较​

这张表不代表一个产品可以完全替代另一个。实际使用中，团队可能继续使用 Codex 完成开发工作，同时使用 xAgent 承载文件处理、报告、消息通知和业务协作任务。

WorkBuddy：现成办公助手与团队能力底座的差别​

当用户想迅速把重复办公工作交给一个现成 Agent 时，WorkBuddy 这类产品的体验通常更直接：用户打开产品、提出需求、在已有能力范围内开始工作。

xAgent 的出发点不同。它希望管理员先把团队常用的场景、Skill、工具、模型和安全策略准备好，再让普通用户直接使用这些经过验证的能力。用户可以“无脑使用”，但高阶用户仍可在任务中精调模型、Skill 和工具。

这更适合下面的情况：

• 团队希望每个人使用同一组经过验证的能力，而不是各自在电脑上重复配置。
• 任务需要在用户离线后继续运行。
• 文件、结果和中间材料需要集中保留，供后续会话继续使用。
• 外部系统接入需要使用用户自身账号与授权，而不是一个权限过大的共享账号。

QoderWork：业务协作入口与部署自主权的差别​

QoderWork 的公开定位是连接办公工具和数据，用多 Agent 协作完成业务任务。对于希望直接进入既有产品生态的团队，这类平台具有明确价值。

xAgent 更像一个可以部署到自己服务器或云环境中的工作门户。部署方自行选择模型服务、外部能力和访问入口；可以从 Web 访问，也可以通过 IM 连接器把任务、消息和文件送入 xAgent。

这不意味着私有化部署没有成本。部署方仍然需要配置模型、HTTPS、备份、外部授权和审批策略。xAgent 的价值是把这些选择与运行责任留在团队自己的环境里，而不是把它们分散到每个用户电脑或固定在单一平台中。

Codex：编码 Agent 与任务 Agent 门户的差别​

Codex 的重点是帮助开发者理解代码库、编写和修改代码、运行测试以及完成软件交付。对于以代码仓库为中心的工作，直接使用 Codex、IDE Agent 或终端 Agent 通常是最自然的选择。

xAgent 不应被描述成“比 Codex 更强的编码工具”。它的重点是让团队把不同类型的任务放在同一个服务端工作入口中运行，例如：

• 读取和整理 Word、PDF、表格、演示文稿等材料。
• 基于 Skill 生成报告、文档或分析结果。
• 通过 MCP、Tool 或连接器查询外部系统。
• 在需要时通过审批后发送消息、写回结果或执行后续动作。
• 通过主会话与子会话协作拆分和推进任务。

如果团队同时有开发任务和业务任务，合理方式往往是让各自擅长的 Agent 做各自的事，而不是强行用一个产品覆盖所有工作。

OpenClaw：个人自动化自由度与团队治理的差别​

OpenClaw 面向技术用户构建自主的个人助手和自动化工作流。对于愿意自行维护本地环境、连接个人账号、持续尝试技能和自动化的人，这种自由度很有吸引力。

xAgent 对自动化更克制。它从一开始就假设会有多个用户、不同类型的任务材料，以及需要明确边界的外部动作。因此它更关注：

• 用户工作区的可见范围与访问边界。
• 公共 Skill 与个人 Skill 的使用方式。
• 密钥不直接交给模型，工具调用时才在系统内部完成替换。
• 管理员设置的公共审批底线，以及用户可以额外细调的个人审批策略。
• 连接器使用用户在外部系统已有的账号和授权，并由外部系统保留最终数据权限判断。

这会减少一部分“随手接入、立即自动化”的自由度，但更适合希望把 Agent 放进团队日常工作，而不是只作为个人实验环境的场景。

客户应如何选择​

可以先用四个问题判断：

1. 主要用户是谁？ 个人用户、开发者，还是需要统一能力的团队成员？
2. 任务在哪里运行？ 用户电脑上短暂执行，还是服务器上持续执行？
3. 是否需要接入文件和外部系统？ 是否需要管理用户自己的账号、授权、消息入口和结果回写？
4. 谁负责风险边界？ 是否需要工作区隔离、密钥管理、审批与运行记录？

如果答案是“团队、多用户、服务端持续任务、内部或外部系统接入、需要安全底线”，xAgent 是更匹配的方向。

当前边界​

xAgent 仍处于 Beta 阶段。它并不是零配置的个人陪伴型产品，接入模型、连接器和内部系统仍需要部署方完成配置、授权和验证。它的优势也不在于宣称模型一定更聪明，而在于为专用 Agent 提供一个可私有化部署、可持续运行、可逐步治理的团队使用入口。

各产品的能力和版本会持续变化。本文仅根据其公开定位讨论适用场景，不构成对任何产品完整功能、安全性或商业方案的评测。

相关链接​

• 什么是 xAgent
• 如何在自己的服务器上部署 AI Agent
• 什么是连接器
• xAgent 如何隔离多用户工作区与任务进程
• WorkBuddy
• QoderWork
• OpenAI Codex
• OpenClaw