2025 年 4 月，我开始写 xAgent。
那时候想得比较直接，就是想做一个任务型 Agent，让 AI 能自己把任务跑起来，实现真正的自动化。现在回头看，这句话说起来很简单，但后面这一年多做的事情，基本都在给“自己把任务跑起来”这几个字填坑。
最早做的是单体 Agent。很快我就发现，单体 Agent 有一个很麻烦的问题：提示词的关注点一旦集中起来，它做某一类任务确实会很好，但换一类任务就可能做得稀烂。你给它补这边，它就忘了那边；什么都想让它兼顾，最后又什么都顾不好。
所以后来开始做多 Agent，让不同的 Agent 各自处理自己更擅长的部分，再互相配合。思路是对的，跑起来以后新的问题也很直接：Token 太贵了。
xAgent 0.0.9.beta 已发布。这次更新重点解决一个长期容易混淆的问题：管理员治理系统和用户完成日常任务，不应该挤在同一套入口和导航里。
新版本将管理后台移到独立的 /admin，/app 则专注于个人会话、工作区和用量。Web 与桌面端的会话界面也统一为同一套双栏布局，会话级提示词可以直接编辑，并从下一轮请求开始生效。
xAgent 0.0.8.beta 已发布。本版本把存储治理从“文件放在哪里”继续推进到“数据如何备份、故障后如何恢复、外部存储如何接入”，并补齐会话复用文件、Skill 多语言治理和本地存储清理。
如果只看一个变化，建议先看在线增量备份：备份任务可以在 xAgent 运行时完成，恢复数据也可以先在线下载和校验，只有最后切换数据目录时需要停机。
自托管系统的备份不能只回答“文件有没有传到远端”，还要回答三个更实际的问题：能否恢复、恢复时要停多久、切换失败后能否回到原状态。
xAgent 0.0.8.beta 把这三个问题拆成一条可验证的流程：运行中创建加密增量快照，运行中下载并校验恢复数据，停机后完成目录切换，最后由管理员确认或回滚。
企业不必在“所有任务都使用内部模型”和“所有任务都交给第三方 API”之间二选一。xAgent 可以为敏感任务创建一个默认使用内部模型的智能体，再让该智能体创建的会话使用对应模型配置：通用任务使用外部模型，受限任务默认使用指向内网服务的模型配置。模型配置决定最终 Provider，因此两类任务会进入不同的模型通道。
这是一种面向特定数据边界的智能体搭建方式，不替代智能体管理中的通用创建说明，也不是一个自动覆盖所有数据流的绝对安全承诺。下面说明这条边界如何建立、怎样验证，以及还需要控制什么。
xAgent 0.0.7.beta 已发布。本版本围绕文件存储与团队协作进行了较大升级，同时推出首个桌面端版本 0.0.1，并继续改进模型缓存、Provider 适配和图片识别能力。
本版本仍为测试版。以下内容说明本次发布的主要变化，不替代正式安装与升级指引。
xAgent 0.0.6.beta 已发布。这一版重点处理一件很基础、也很容易影响任务质量的事情：让文件进入系统、被读取、被处理和被交付的过程更可靠。
xAgent 的目标不是把文件简单塞进对话框，而是让 Agent 能在服务端持续处理任务。对于会议记录、合同、报告、表格、演示文稿和业务资料来说，文件是否能被正确识别、定位和复用，直接决定后续任务是否可靠。
本版本仍为测试版。以下内容面向准备部署或升级的用户说明，不替代正式安装与升级指引。
许多人第一次使用 AI Agent 时，会先在自己的电脑上安装一个桌面工具。这种方式适合试用、写代码或处理一次性任务。但当 Agent 开始读取文件、调用外部系统、等待审批、生成报告，或者需要多人重复使用时，问题就不再只是“模型够不够聪明”，而是它应该在哪里运行。
本文不讨论某个具体模型，而是解释个人电脑和服务器部署分别适合什么场景，以及为什么团队长期使用 Agent 时通常需要服务端运行方式。
客户经常会问：xAgent 和 WorkBuddy、QoderWork、Codex、OpenClaw 这些产品有什么区别？
这个问题不应该回答成“xAgent 比它们都强”。它们解决的问题并不相同。选型时最重要的不是比较谁的模型更聪明，而是先明确：谁在使用、任务在哪里运行、是否涉及多人和业务系统，以及谁来承担安全与运维责任。