# 火木工作室 / Fire Wood Studio — 全站正文 > 本文件是 tsagent.cc 全部公开文章与产品信息的纯文本合集，便于 AI Agent 一次读完整站内容。 > Plain-text corpus of every public article and product on tsagent.cc, for AI agents to ingest in a single fetch. - 生成自 / Generated from: https://tsagent.cc/ - 站点索引 / Index: https://tsagent.cc/llms.txt - 联系 / Contact: support@tsagent.cc ## 产品 / Products ### Easy Post URL: https://ep.tsagent.cc/ · English: https://ep.tsagent.cc/en/ 平台 / Platforms: windows, macos 简介 / Summary: 让社媒创作易如反掌。一款桌面内容生产工具：AI 灵感对话、素材整理、公众号排版、社交卡片生成，四个工作台覆盖从想法到发布的完整流程。排版由本地 Rust 引擎完成，不依赖大模型。 Summary (en): Social content creation, made simple. A desktop content studio with four workbenches — AI ideation, material organization, WeChat article formatting, and social card generation. Typesetting runs on a local Rust engine, not a model. 功能 / Features: - 灵感：AI 对话创作: 头脑风暴、内容创作、信息整理三大能力分组，内置公众号文章、爆款标题、内容润色、选题策划等快捷提示词，一键填充对话框。 - 素材：微信读书导入: 一键导入微信读书的划线与笔记，按书籍、条目筛选后整理成 Markdown，直接发送到图文或卡片工作台继续编辑。 - 图文：公众号排版: 左侧 Markdown 编辑，右侧实时渲染预览，22 套预设主题一键切换，支持标题标签、作者信息、目录编号、关键词高亮等精细排版。 - 卡片：社交媒体信息卡片: 把一段素材拆分成 1–10 张信息卡片，支持手动创建或 AI 一次性生成整套文案，轮播 / 平铺双视图把控整体风格。 - 模型配置自由: 支持 Ollama、OpenAI、Anthropic、DeepSeek、GitHub Copilot、MiniMax、硅基流动、阶跃星辰、OpenRouter、NVIDIA、百炼、火山引擎及自定义端点。 - 确定性引擎: 排版、目录生成、章节编号、校验等确定性逻辑由本地 Rust 引擎完成，结果稳定可复现，不消耗 token。 常见问题 / FAQ: - Q: 我的 API Key 存在哪里，安全吗？ A: 模型服务商、微信读书等 API Key 保存在应用本地存储或系统凭据库中，适合个人本机使用，不建议在共享系统账户中保存敏感凭证。 - Q: 必须联网才能用吗？ A: 不一定。排版、编号、校验等确定性逻辑由本地 Rust 引擎完成，不依赖 AI 大模型；如果搭配本地 Ollama 模型，创作类功能也可以完全离线运行。使用云端服务商时则需要联网访问对应 API。 - Q: 支持哪些系统？ A: 基于 Tauri 构建的桌面原生应用，支持 Windows 与 macOS。macOS 安装包为 universal 版本，Intel 与 Apple Silicon 机器均可运行。 - Q: 软件是免费的吗？ A: 下载和使用完全免费，可以自愿打赏，金额从 0.01 到 199 元之间任选，也可手动输入。使用 AI 功能需要自行准备模型 API，软件支持主流服务商接入。 - Q: 排版结果怎么用到公众号？ A: 在图文工作台点「复制到公众号」，富文本样式会连同样式一并进入剪贴板，直接粘贴到公众号编辑器即可；也可以导出完整 HTML 自行留存。卡片支持单张导出或批量导出全部 PNG。 - Q: 软件是开源的么？ A: 现阶段未开源，仅提供最新 Release 安装包下载。下载页始终指向 latest 版本，安装包文件名固定，升级时直接覆盖即可。 ### Dr T URL: https://drt.tsagent.cc/ · English: https://drt.tsagent.cc/en/ 平台 / Platforms: windows, macos 简介 / Summary: Dr T，你的远程运维AI搭子。运维的高技术门槛被拆掉了：不用背命令，AI Agent 接管 SSH 自主排障；软件小巧，装在本机就能用。 Summary (en): Dr T, your AI partner for remote ops. The technical barrier to ops is gone: no commands to memorise, an AI agent takes over SSH and diagnoses on its own. A small client, installed locally. 功能 / Features: - 多设备 SSH 管理: 密码与密钥双认证、设备分组一键连接；内置全功能终端与远程文件浏览器，还能在会话里给远端一键装好 Agent。 - Ask 模式：对话式诊断: 描述现象，AI 结合目标机的系统上下文给出排查路径与具体命令；危险命令会标注 ⚠️ 提醒，你确认后才执行。 - Agent 模式：自主循环排障: AI 自主调用工具执行命令、读取系统快照与日志，逐层收窄问题范围直到定位根因；整个循环随时可中断接管。 - 本机模式：免 SSH 诊断: 不连服务器也能用：直接采集运行 Dr T 的本机（Windows / macOS）系统上下文，Ask 与 Agent 两种模式同样可用。 - 本地记忆存储: 按设备单独保存排障结论与你的偏好，对话时按相关度、时效、重要性与使用频率召回注入；设备未连接时也能只凭本地记忆作答并明确标注。 - Skills 技能模板: 把常见排障流程写成 Markdown 技能，Agent 模式下自动注入上下文；也可以让 AI 帮你起草技能内容。 - 报警接收：HTTP / MQTT: 在本机开一个 HTTP 端口接收设备 POST 的 JSON 报警，或连接任意 MQTT Broker 订阅指定 Topic，异常消息实时进入工作台。 - 12+ 模型服务商，数据不出内网: 支持 Ollama、OpenAI、Anthropic、DeepSeek、SiliconFlow 等 12+ 服务商，各自独立保存 API Key 与 Base URL；专业版还可把备用模型排成故障转移链自动接管。 常见问题 / FAQ: - Q: 装完会自动连我的服务器吗？ A: 不会。软件启动后不发起任何连接，也不会扫描网络。必须由你手动添加设备，并在选中设备后主动操作；Agent 模式同样需要你点下开始才会连上去。 - Q: AI 会不会自己把服务器搞坏？ A: 不会无限制执行。rm -rf /、dd、mkfs 这类危险命令被硬拦截，风险操作会弹出确认框，必须你点同意才会执行；还可以把关键目录设为「受保护路径」，Agent 无权写入。建议先在非生产环境试用，并提前做好备份。 - Q: 我的 API Key 存在哪？会上传吗？ A: 只存在你本机的应用数据里，不会上传到我们的服务器。但调用模型时，Key 会随请求发送给你选择的模型服务商。服务器信息也是同理：用内网部署的模型（Ollama 或自建兼容端点）时数据不出内网，用云端服务商则按该服务商的策略处理。 - Q: 支持哪些系统？ A: 客户端目前只有 Windows 与 macOS 安装包，Linux 桌面暂不支持安装客户端，本机模式也就仅限这两个平台。Linux 服务器仍是主要使用场景：通过 SSH 连接目标 Linux 机器时，终端、文件浏览与对话诊断都可用；需要结构化系统上下文时，可在目标机上安装 tse-agent 远程 Agent。 - Q: 服务器在内网、没有公网 IP 能用吗？ A: 可以，只要你的电脑能直接连到那台机器的地址（同一内网，或已经通了 VPN / 跳板）。如果要做到全程无外网，大模型也得用内网部署的那一个。 - Q: 它和 Xshell / FinalShell 有什么区别？ A: 相同的是 SSH 终端和文件树这部分基本功。不同的是 Dr T 把 AI 接进了设备上下文：Ask 模式下它会结合当前机器的状态给判断和命令，Agent 模式下会自己多步排查直到定位根因，而不只是把命令列给你。此外还有本机诊断、报警接收和按设备沉淀的排障记忆。 ### Easy Infer Station URL: https://eis.tsagent.cc/ · English: https://eis.tsagent.cc/en/ 平台 / Platforms: windows, macos, linux 简介 / Summary: 轻量化的 .pt 模型测试与演示工具。面向算法、产品与交付团队的桌面推理工具：加载 Ultralytics .pt 即可跑图片、批量、视频与 RTSP，不需要写代码也能做演示和效果评估。 Summary (en): A lightweight tool for testing and demoing .pt models. A desktop inference tool for algorithm, product, and delivery teams: load an Ultralytics .pt and run images, batches, video, or RTSP. Demos and evaluation without writing code. 功能 / Features: - 给客户演示: 载入模型和样例直接展示，现场不用临时写脚本。 - 验证新模型: 换上新版 .pt，同一批样张重跑一遍，效果差异一眼可见。 - 检测 + 分类: 加载 .pt 自动识别任务类型与类别名。 - 四种输入: 单图、批量图片、视频文件、RTSP 流。 - ROI 与报警: 只看关心的区域，命中目标自动留帧。 - 跟踪与设备: ByteTrack 或 BoT-SORT；CUDA 与 CPU 可切。 常见问题 / FAQ: - Q: 不懂代码能用吗？ A: 能。环境准备好之后全程点界面：选模型、选输入、开始推理。 - Q: 为什么还要自己准备环境？ A: 安装包只含界面与调度，推理跑在本机 conda 环境（torch + ultralytics），所以体积小、换库也方便。 - Q: 和 Easy Conda 什么关系？ A: Easy Conda 负责把 conda 环境建好、把依赖装齐，EIS 直接复用这个环境。 - Q: 支持哪些模型？ A: Ultralytics 的 .pt 权重，检测和分类都能直接用。 - Q: 没有显卡能用吗？会上传文件吗？ A: 没有显卡就选 CPU 推理；文件不上传，后端只监听本机。 ### Easy Dataset URL: https://eds.tsagent.cc/ · English: https://eds.tsagent.cc/en/ 平台 / Platforms: windows, macos, linux 简介 / Summary: 你的深度学习训练数据处理搭子。YOLO 数据集的本地工具箱：质量检测、带框可视化、图片标注（检测 / 旋转框 / 分割，支持 AI 预标注）、格式互转、划分合并、视频抽帧，从原始素材一路做到 data.yaml。 Summary (en): Your sidekick for deep learning training data. A local toolbox for YOLO datasets: quality checks, visual review, annotation (boxes, OBB, segmentation, with AI pre-labelling), format conversion, splitting and merging, and video frame extraction — from raw footage to data.yaml. 功能 / Features: - 数据集质量检测: 统计图片、标签、标注框与类别数量，列出孤立图片、孤立标签与空标签，给出类别分布、框面积与宽高比直方图；还会判出这份数据到底是检测、旋转框还是分割，混用时标为「混合」。 - 带框可视化浏览: 缩略图墙按「全部 / 已标注 / 未标注」或指定类别过滤，点开即看原图与标注：检测画矩形、分割画半透明多边形、旋转框画四点轮廓，三种类型一眼分得开。 - 图片标注: 矩形、旋转框、多边形三种画法：拖框、拖手柄转角度、逐点描边。支持撤销重做、跨图复制粘贴、滚轮缩放与全套快捷键，编辑自动保存，类别名写回 classes.txt。 - AI 自动预标注: 用自己训练好的模型先跑一遍，再人工修低置信度区域。ultralytics 能加载的权重都能用：YOLOv5～v12、RT-DETR，检测 / 分割 / 旋转框模型均可，.pt / .onnx / .engine 都认。 - 格式互转与导出: LabelMe JSON、Pascal VOC XML 转 YOLO TXT，YOLO 转 VOC XML，以及导出 COCO JSON（分割写真实多边形与 area）；类别名到 ID 的映射与「类别重映射」都在界面上填。 - 标签编辑: 批量替换类别 ID、删除某个类别的全部标注、多个 ID 一次性重排序、重命名类别；可原地修改，也可输出到新目录，执行后给出受影响文件数。 - 文件一致性管理: 一致性检查列出孤立图片与孤立标签；可删空标签、为未标注图片补空标签、按前缀加序号批量重命名、修复打不开的 JPEG。全部支持先预览再执行。 - 数据集划分: 按 train / val / test 比例随机划分（三者之和须为 1.00），随机种子固定即可复现，并自动生成可直接训练的 data.yaml。 - 数据集合并: 多来源合成一份，支持类别 ID 偏移与逐项映射，可选给文件名加来源编号前缀，避免不同来源的同名图片互相覆盖。 - 视频抽帧: 普通抽帧按帧间隔取图，可设格式、JPEG 质量与文件名前缀；AI 智能抽帧只保留含目标类别的帧，并同时写出 YOLO 标签，抽完就能直接进标注页修正。 常见问题 / FAQ: - Q: 使用前需要准备什么环境？ A: 首次运行会引导选择本机已有的 conda 环境，也可以手动指定 python 路径。基础功能需要 Flask、OpenCV、Pillow、PyYAML 等依赖，向导会标注环境是否齐全；AI 预标注与智能抽帧额外需要 ultralytics，分段并行还需要 ffmpeg。 - Q: 会把数据集上传到云端吗？ A: 不会。质量检测、标注、转换、划分、合并与抽帧都在本机完成，后端只监听 127.0.0.1，不依赖任何在线服务。 - Q: 能标注旋转框和分割吗？ A: 能。矩形、旋转框（OBB）、多边形分割三种画法都支持，打开已有数据集时按标签内容自动判定类型。4 点多边形不会被误判成旋转框（需满足对边等长、邻边垂直），OBB 数据集也不会被降级导出为矩形。 - Q: AI 预标注支持哪些模型？ A: ultralytics 能加载的权重都可以：YOLOv5～v12、RT-DETR，检测 / 分割 / 旋转框模型都行，格式支持 .pt / .onnx / .engine / .torchscript / .tflite 与 OpenVINO 目录。分类模型不做框标注；阈值与是否覆盖已有标注都可调。 - Q: 支持哪些标注格式？ A: 读：YOLO TXT（检测 / OBB / 分割）、LabelMe JSON、Pascal VOC XML；写：YOLO TXT、VOC XML、COCO JSON。转换前建议先备份，尤其「原地修改」类操作。 - Q: 数据集很大时会卡吗？ A: 文件按需逐个读取，缩略图分页加载，不会把整份数据集一次性读进内存；但预览与导出会生成副本，磁盘建议预留数据集体积 2 倍以上空间。 - Q: 是开源的吗？ A: 是，使用 GPL-3.0 许可证，源码与安装包都在 GitHub 上，完整使用说明书在仓库 wiki 目录。 ### Easy Conda URL: https://easyconda.tsagent.cc/ · English: https://easyconda.tsagent.cc/en/ 平台 / Platforms: windows, macos, linux 简介 / Summary: 不用背 Conda 命令的环境管理器。轻量的 Conda 环境桌面管理器：自动发现已有的 Conda / Miniforge / Mamba，图形化完成环境创建、包安装与升级、渠道切换、environment.yml 导入导出、离线交付与缓存清理。 Summary (en): The Conda manager that spares you the commands. A lightweight desktop manager for the Conda you already have: discover Conda / Miniforge / Mamba, then create environments, install and upgrade packages, switch channels, import or export environment.yml, deliver offline, and clean caches — without typing commands. 功能 / Features: - 自动发现已有 Conda: 启动时扫描 PATH、常见安装位置和已登记路径，识别 Conda、Miniforge、Mamba 与 micromamba；机器上装了多个也不怕，可以指定哪一个作为默认实例。 - Windows 与 WSL，一套界面: 顶部分别列出本机 Windows 和每个 WSL 发行版，切换后环境、包和 Python 版本随之更新；在 WSL 里建的环境不会在 Windows 侧“消失”。 - 环境一屏看完，不用 conda env list: 环境名称、路径、Python 版本、包数量和磁盘占用并排列出，同名但路径不同的环境也能分清；点开右侧详情就能看完整包清单。 - 新建、克隆、删除都有向导: 填个名字、选 Python 版本、把依赖按名字列进去即可；删除前会展示完整路径并二次确认，而且 base 环境不允许删除。 - 装包之前，先看求解结果: 安装、升级、移除包之前先做一次 dry-run 预览：哪些包会新增、哪些会变更或移除、大约要下载多少，确认之后才真正执行。 - 国内镜像一键添加: 内置清华 main、清华 conda-forge、官方 defaults 等快捷入口，不用再手写 .condarc；渠道优先级从高到低排好，添加后可以直接测试连通性。 - environment.yml 与精确清单: 导出可读可改的 environment.yml，或导出精确到包版本的 explicit spec；导入前先解析预览环境名、渠道与依赖，再决定是否创建。 - 三种离线交付方式: 离线包仓库 + explicit spec、pip wheelhouse、conda-pack 归档各管一段场景，界面上会写清楚每种方式覆盖什么，不会把 wheel 当成全部依赖。 - 一键激活并打开终端: 想接着用命令行也没问题：选中环境即可激活并打开对应终端（Windows 用 PowerShell，WSL 用 bash），已激活的环境在列表里带标记。 - 日志、诊断与缓存清理: 每个操作都有状态、阶段和可复制的脱敏日志，失败时能回到具体步骤；清理下载包或缓存包后，会直接告诉你释放了多少空间。 常见问题 / FAQ: - Q: 需要先装 Conda 吗？ A: 需要，因为 Easy Conda 是管理器而不是发行版。它可以发现 Conda、Miniforge、Mamba 与 micromamba；机器上暂时没有时，「安装 Conda」页会给出 Miniforge 的安装引导，不会未经允许替你下载或提权安装。 - Q: 和 Anaconda 会冲突吗？ A: 不冲突。它会把已安装的 Anaconda 当成一个可管理的实例，你原来的 base 和所有环境都保持原样。区别在于：Anaconda 默认预装几百个包，而 Easy Conda 只装你点名要的依赖，磁盘占用自然小得多。 - Q: 会偷偷改我的 Conda 配置吗？ A: 不会在后台改动。渠道修改会写入 Conda 用户配置，界面上有明确提示；删除类操作必须确认，且不允许删除 base 环境。 - Q: 真的完全不用命令行吗？ A: 日常操作都可以在界面完成：建/删/克隆环境、装包升级、换源、导入导出、清理缓存、看日志。如果你喜欢命令行，它也保留「一键激活并打开终端」的入口，两种方式可以混着用。 - Q: 支持 WSL 吗？ A: 支持。WSL 发行版会作为独立的运行目标出现在顶部切换器里，前提是该发行版内已经装好 Conda；两个目标的包和 Python 版本互不干扰。 - Q: 支持哪些系统？ A: Windows 10/11、macOS（Apple Silicon 与 Intel）与 Linux（deb / AppImage）。 - Q: 没有外网能用吗？ A: 查看和管理已有环境、看日志、清理缓存都不需要联网；装包和创建环境时需要能访问所用渠道。给完全离线的机器交付环境时，可以用离线包仓库、pip wheelhouse 或 conda-pack 归档。 - Q: 是开源的吗？ A: 是，采用 Apache License 2.0，源码和安装包都在 GitHub 上。 ### Easy Trainer Station URL: https://ets.tsagent.cc/ · English: https://ets.tsagent.cc/en/ 平台 / Platforms: windows, macos 简介 / Summary: 把 YOLO 训练变成点几下的事。面向 YOLO 模型训练的桌面工作站（研发中）。图形化配置训练参数，实时查看 Loss / mAP 曲线，管理训练历史与模型版本，与 Easy Dataset 无缝衔接。 Summary (en): YOLO training without the command line. A desktop workstation for YOLO training (in development). Configure hyperparameters visually, watch Loss and mAP in real time, manage training history and model versions, and work directly with Easy Dataset. 功能 / Features: - 图形化配置训练超参数: 批大小、学习率、轮数、数据增强等参数在界面上配置，避免手写 YAML 出错。 - 实时 Loss / mAP 监控: 训练过程中曲线实时更新，一眼判断是否过拟合或学习率设置不当。 - 训练历史与模型版本: 每次训练的配置、指标与产物都被记录，可随时对比两次训练差异。 - 与 Easy Dataset 联动: 直接读取 Easy Dataset 导出的目录结构，不必再手动整理数据集。 常见问题 / FAQ: - Q: 什么时候能用？ A: 目前仍在开发中，尚无明确发布日期。可以发邮件预约通知，上线后我们会主动告知。 - Q: 会收费吗？ A: 计划与同系列工具一致：下载使用免费，AI 相关功能使用自备模型 API。 ### pt2rknn URL: https://pt2rknn.tsagent.cc/ · English: https://pt2rknn.tsagent.cc/en/ 平台 / Platforms: web 简介 / Summary: PyTorch / ONNX 到 RKNN，三步搞定。面向 Rockchip NPU 的模型转换工具，Web 界面无需命令行。支持 YOLOv8 全系列（Det / Seg / Pose / OBB）、ResNet、RetinaFace 六种网络类型，覆盖 RK3562 到 RK3588，内置 INT8 量化与校准集自动构建，转换后用 Netron、电脑端基线推理和逐层误差分析当场验证。 Summary (en): PyTorch and ONNX to RKNN in three steps. A conversion tool for Rockchip NPUs with a web UI and no CLI. Six network types — the full YOLOv8 family (Det / Seg / Pose / OBB), ResNet, and RetinaFace — across RK3562 through RK3588, with INT8 quantization, an automatic calibration builder, and post-conversion checks via Netron, a desktop baseline, and per-layer error analysis. 功能 / Features: - 三步卡片式 UI: 选类型、传文件、配参数，每一步只露出当前该做的输入，不熟悉 RKNN 也能一路点下去。 - 六种网络类型: YOLOv8 Det / Seg / Pose / OBB、ResNet、RetinaFace 各带默认输入尺寸与校准目录，扩展名不匹配会当场拦下。 - 双转换路径: .pt 走 rknnopt TorchScript 路径（避免多个输出头共用同一 INT8 scale 导致分数全零），也可经 ONNX 转，或直接喂现成 ONNX。 - INT8 量化 + 校准集自动构建: 指向训练数据目录，自动识别普通图片目录 / YOLO / ImageNet / COCO / 递归结构，提取图片并生成 dataset.txt。 - SSE 实时日志: 量化进行到第几张、每张耗时、整体进度都实时推送，卡在哪一步不用开后端终端。 - 转完当场验证: Netron 看结构、电脑端跑 ONNX FP 基线出框、逐层余弦相似度看误差，三条路都不需要先上板子。 - 结果可追溯: 转换元数据记录源模型 SHA256、校准清单哈希与量化算法 / 方法 / 优化级别，同一输入可以复现同一产物。 - WSL / Docker 双模式: 自动识别运行环境并转换路径：WSL 下 E:\data 变 /mnt/e/data，Docker 下变 /e/data，校准图片落在可写目录。 常见问题 / FAQ: - Q: 需要什么环境？ A: x86_64 Linux（含 WSL）或 Docker，加一个 Python 3.8 与 rknn-toolkit2 环境。rknn-toolkit2 只提供 Linux 轮子，Windows / macOS 原生跑不起来。 - Q: 支持哪些芯片？ A: RK3562 / RK3566 / RK3568 / RK3576（默认）/ RK3588，在第三步的目标平台里切换。 - Q: 支持哪些模型？ A: YOLOv8 Det / Seg / Pose / OBB、ResNet、RetinaFace 有现成配置；其它模型可以经 ONNX 路径转换。 - Q: INT8 没有校准数据会怎样？ A: 转换直接失败并报错，不会自动回退到 FP16——避免拿到一个名字写着 INT8、实际没量化的模型。 - Q: 转换后的精度怎么确认？ A: 电脑端 ONNX 基线与逐层误差分析只能说明转换本身有没有问题；最终精度要到 RK35xx 设备上实测，页面上两处都标注了这一点。 - Q: 怎么获取？ A: 源码在 GitHub，按 README 起 conda 环境或直接 docker-compose up 即可，默认访问 localhost:5600。 ### GeniusFlow URL: https://gf.tsagent.cc/ · English: https://gf.tsagent.cc/en/ 平台 / Platforms: web 简介 / Summary: 把线下流程搬到线上，让 AI 参与每一步。面向企业的 AI 增强流程管理平台。业务人员用可视化设计器拖拽流程，每个节点内置专属 AI Agent，在执行阶段提供实时指引、知识推荐与自动质量检查。 Summary (en): Digitize your process, with AI at every step. An enterprise process platform with AI built in. Business users design workflows visually, and each node embeds an AI agent that guides execution, recommends knowledge, and checks quality automatically. 功能 / Features: - 可视化流程设计器: 业务人员直接拖拽节点搭建流程，不需要工程师翻译需求。 - 节点内 AI Agent: 每个节点可配置 Co-pilot / 顾问 / 督导 / 助理四种角色的 Agent，执行时给出针对性指引。 - 看板与甘特: 执行层用看板推进任务，管理层用甘特查看整体进度与瓶颈。 - 多模型 + RAG 知识库: 接入多个模型服务商，并把企业内部文档变成可检索知识，回答基于实际制度与规范。 - RBAC 权限: 按角色控制流程设计、执行、审批与查看权限，满足企业权限边界要求。 - OpenAPI 中台模式: 可作为中台被企业现有系统调用，把流程能力嵌入原有业务链路。 常见问题 / FAQ: - Q: 现在可以正式使用吗？ A: 目前处于公测阶段，功能仍在迭代。可以申请演示，我们会结合你的流程场景评估是否合适。 - Q: 可以私有化部署吗？ A: 可以。支持私有化部署，模型可接入企业内部或本地服务。 - Q: 怎么申请演示？ A: 发邮件到 support@tsagent.cc，说明你的业务场景与期望，我们会安排演示。 --- ## 文章 / Articles ### AI is not the author — you are URL: https://tsagent.cc/en/blog/ai-not-the-master/ 语言 / Language: en 发布 / Published: Aug 10, 2026 标签 / Tags: AI, Content creation, Product design 摘要 / Summary: Why we put layout in a local engine, creativity in the model, and the final call in your hands — and how inserting AI into every step can cost creators control. Nearly every content tool released in the past two years tells the same story: put AI into every step, so users can "generate an article from one sentence" or "generate a poster set from one sentence." You type a topic, AI handles the headline, the layout, the images, and you press publish. It sounds great, but anyone who has used these tools comes away a little uneasy. The article was written by AI, the layout was chosen by AI, the style was set by AI. Somewhere along that assembly line, you became the person signing off rather than the person creating. Easy Post tries the opposite: **AI can take part in every step of creation, but the final call always stays with you.** ## Four workbenches for four stages Easy Post is a desktop content tool. It splits the workflow into four workbenches: - **Ideation**: AI chat for brainstorming, with built-in prompts that fill the box in one click, and free combining of skills, knowledge bases, and models - **Materials**: import WeRead highlights in one click, filter by book or entry, and send the result straight into the article or card workbench - **Articles**: write Markdown on the left, see the result on the right, then copy it into the WeChat editor already formatted - **Cards**: split source material into 1–10 cards. Templates do not depend on a model, but AI can generate the whole text set at once Models are not locked to one vendor either. Run Ollama locally, or pick from a dozen cloud providers, with fallback chains when the primary fails. API keys live in the OS keychain, not in a plain text file. But the interesting part is **why** we built it this way. ## Layout is not a job for AI WeChat article formatting has a specific property: it is a **deterministic problem**, not a creative one. How large the headline should be, how much space goes between paragraphs, how the table of contents is numbered, whether punctuation gets converted to full-width — these have exact rules. Computed is computed. No guessing required. Yet many AI formatting tools insist on having a model "generate" the layout. That is a probabilistic model doing work that has a precise solution. The result is style drift, two different outputs from the same input, and the occasional inexplicable formatting error. Behind the article workbench in Easy Post is a local Rust layout engine that handles all the deterministic logic: theme rendering, table of contents, section numbering, keyword highlighting — all computed on your machine, with no model involved. That means two things. First, **results are controllable and reproducible**. Same Markdown, same theme, same output, every time. Second, **formatting needs no internet and no API key**. Even with no model connected at all, Easy Post remains a complete formatting tool. AI is a bonus, not a prerequisite. This also differs from conventional WeChat editors. They turn layout into manual labor — pick a template, drag components, apply styles one by one. Easy Post automates that labor with an engine: you write Markdown, the deterministic logic handles the rest. ## Creativity to AI, decisions to you If layout belongs to the engine, what does AI do? The things it is genuinely good at: brainstorming, first drafts, polishing, keyword extraction, image style transfer. These are divergent, creative tasks where exploring many possibilities is the point. But even here, Easy Post deliberately avoids the "one sentence, end-to-end finished product" pattern. The ideation workbench gives you **quick prompts plus freely combinable skills, knowledge bases, and models**. AI produces drafts and raw material; you still edit and adjust before anything gets published. This is a different philosophy from the currently popular "fully AI, skill-driven agent" approach. Agentic creation aims for **end-to-end automation**: topic selection, writing, images, layout, and publishing chained into one pipeline, with a person at the start making a request and at the end approving a result. The middle is a black box. It is genuinely faster — but the cost is that you gradually lose control over the process. Easy Post goes the other way: **it opens the process back up**, making every step visible, interruptible, and editable. AI supplies material and suggestions, but every judgement call between draft and final version is yours. Slower, but what you end up with is something you actually took part in. ## Why this matters What content creation leaves behind is not just a publishable article, but the judgement you exercised along the way — which angle to take, which sentence to cut. Outsource all of that to AI and the short-term gain in speed comes with a long-term erosion of exactly the ability you were relying on. Easy Post is not trying to be the fastest content tool. It is trying to be one that keeps you **in the author's seat**: deterministic work goes to a local engine, creative work gets AI assistance rather than replacement, and the final decision stays with you. --- If you agree that content creation should not be handed entirely to a black box, give Easy Post a try. Native desktop app for Windows and macOS — download and go. --- ### AI 不是创作的主人，你才是 — Easy Post 的设计取舍 URL: https://tsagent.cc/blog/ai-not-the-master/ 语言 / Language: zh 发布 / Published: 2026年8月10日 标签 / Tags: AI, 内容创作, 产品设计 摘要 / Summary: 这篇文章讲我们做 Easy Post 时的取舍：排版交给本地 Rust 引擎保证确定性，创意交给模型，最终决定权留给你。也聊了为什么把 AI 塞进内容生产的每个环节，反而会让创作者失去对作品的控制，以及我们如何划清这条边界。 这两年做内容工具的产品，几乎都在讲同一个故事：把 AI 塞进每一个环节，让用户「一句话生成一篇文章」、「一句话出一套海报」。你输入一个主题，AI 从标题到排版到配图全包了，你只需要点「发布」。 听起来很爽，但用过的人多少都会有点不踏实 —— 文章是 AI 写的，排版是 AI 选的，风格是 AI 定的，你在这条流水线上，更像是最后签字的人，而不是创作者。 Easy Post 想做一件相反的事：**AI 可以参与创作的每一步，但决定权永远留在你手里。** ## 四个工作台，对应创作流程的四步 Easy Post 是一款桌面端内容生产工具，围绕内容创作的完整流程拆出四个工作台： - **灵感**：AI 对话式头脑风暴，内置快捷提示词，一键填充对话框，也可以自由组合 Skill、知识库和模型 - **素材整理**：一键导入微信读书的划线笔记，按书籍、条目筛选后整理成 Markdown，直接送进图文或卡片工作台 - **图文排版**：左侧写 Markdown，右侧所见即所得，写完复制粘贴到公众号编辑器里就是排好版的文章 - **社交卡片**：把一段素材拆成 1–10 张卡片，模板本身不依赖大模型，也可以用 AI 一次性生成整套文案 模型这块也不锁定某一家：Ollama 本地跑，或者十几家云端服务商任选，还能配置 Fallback 备用链。API Key 全部存进系统凭据库，不是明文摆在本地文件里。 但真正想聊的，是**为什么要这么做**。 ## 排版这件事，不该交给 AI 公众号排版有个特点：它是**确定性问题**，不是创意问题。标题该多大、段落间距该多少、目录编号该怎么排、全角标点要不要转换 —— 这些东西有明确规则，算出来就是算出来，不需要「猜」。 但很多 AI 排版工具偏偏喜欢用大模型去「生成」排版结果，本质上是让一个概率模型去做一件本该有精确解的事。结果就是排版风格漂移、同一段内容两次生成出两个样子、偶尔还会出现莫名其妙的格式错误。 Easy Post 的图文工作台背后是一套本地 Rust 排版引擎，负责所有确定性逻辑：主题渲染、目录生成、章节编号、关键词高亮，全部在本机算出来，不依赖任何大模型。这意味着两件事： 第一，**结果可控且可复现**。同样的 Markdown、同样的主题，出来的效果永远一致。 第二，**排版不需要联网、不需要 API Key**。哪怕完全不接入任何大模型，Easy Post 依然是一个功能完整的排版工具。AI 是加分项，不是准入门槛。 这一点和常规的公众号编辑器也不一样。它们把排版做成了「选模板、拖组件」的体力活，你要一个个手动套样式；而 Easy Post 用引擎把这套体力活自动化了，你只管写 Markdown，剩下的交给确定性逻辑去算。 ## 创意归 AI，决定归你 排版交给引擎，那 AI 干什么？干它真正擅长的事：头脑风暴、初稿生成、文案润色、关键词提取、图片风格转换。这些是发散性、创意性的任务，本来就该让概率模型去探索多种可能性。 但即便在这些环节，Easy Post 也刻意没有做成「一句话 end-to-end 出成品」的模式。灵感工作台给你的是**快捷提示词 + 可自由组合的 Skill / 知识库 / 模型**，AI 给出的是草稿和素材，你还要经过编辑与调整，才能变成最终发布的内容。 这跟现在流行的「完全 AI + Skill 的 Agent 创作」是两种思路。Agent 化创作追求的是**端到端自动化**：把选题、写作、配图、排版、发布串成一条流水线，人只在起点提需求，在终点验收结果，中间过程是个黑箱。效率确实高，但代价是你逐渐失去对创作过程的掌控。 Easy Post 反过来：**把创作过程重新打开**，让每一步都可见、可插入、可修改。AI 给你素材和建议，但从初稿到成稿之间的每一次取舍，都需要你亲自动手。慢一点，但写出来的东西，是你真正参与和认可的。 ## 为什么这很重要 内容创作最终留下的，不只是一篇能发布的文章，还有创作过程中你对选题的判断、对表达的斟酌。这些东西一旦全部外包给 AI，短期看是效率提升，长期看是创作能力和判断力的退化。 Easy Post 想做的，不是最快的内容生产工具，而是一个让你**保持在创作主导位置**的工具：确定性的活交给本地引擎，创意性的活让 AI 辅助你而不是替代你，最终决定权，始终握在你自己手上。 --- 如果你也觉得内容创作不该完全交给一个黑箱，欢迎试试 Easy Post。支持 Windows 与 macOS，桌面原生应用，下载即可使用。 --- ### WeChat formatting: let the local engine handle layout URL: https://tsagent.cc/en/blog/ep-wechat-formatting/ 语言 / Language: en 发布 / Published: Oct 8, 2026 标签 / Tags: Content creation, WeChat, Workflow 摘要 / Summary: How Easy Post splits the work: layout, numbering and validation run in a local Rust engine, while ideas and final calls stay with you. Formatting looks trivial and is not. Heading levels, numbering, quotes, line height, card styles, per-platform quirks — none of it is creative, all of it costs time, and one mistake makes the whole piece look careless. Our position: **deterministic work should not be handed to a model.** Models are good at finding angles and rewriting tone. They are the wrong tool for deciding how big a level-three heading should be. ## Four workbenches, four jobs 1. **Ideation** — talk through angles and outlines with a model. Restart freely; drafts stay untouched. 2. **Materials** — collect links, screenshots and excerpts in one place while you write. 3. **WeChat formatting** — paste plain text, pick a theme, and a local Rust engine applies styles, numbering and structural checks. 4. **Social cards** — turn one argument into shareable images, exported in batches. The important difference is step 3: no network round trip, no tokens. The same text formatted today and next year looks identical. ## A workflow that holds up - Think first: three rounds of questioning until you can state, in one sentence, what the reader should do after reading. - Write plain text only. Use `#` for headings and `-` for lists; ignore styling while drafting. - Format once, publish everywhere: the same source text, re-themed per platform. - Check structure before publishing. Machines are better than eyes at spotting broken numbering. ## Offline capable Layout, numbering and validation run locally. With a local Ollama model, even the creative features work without a network; cloud providers are optional. Data follows the same rule — drafts, materials and API keys stay on your machine. That suits personal computers; avoid keeping credentials on shared accounts. --- Try it from the [Easy Post product page](https://ep.tsagent.cc/) — Windows and macOS builds available. --- ### 公众号排版：把排版交给本地引擎，把创意留给模型 URL: https://tsagent.cc/blog/ep-wechat-formatting/ 语言 / Language: zh 发布 / Published: 2026年10月8日 标签 / Tags: 内容创作, 公众号, 工作流 摘要 / Summary: 很多工具让 AI 从标题到配图全包，结果文章读起来不像你写的。这篇讲 Easy Post 的做法：排版、编号、校验这类确定性工作交给本地 Rust 引擎，创意和最终判断留给自己，顺便给出一个可复用的写作流程。 排版是个「看起来简单、做起来琐碎」的活：标题层级、编号、引用、行距、卡片样式、多平台适配。这些事没有创造性，却特别耗时间，而且一件做错就会显得不专业。 我们的判断是：**这类确定性工作不该交给模型**。模型擅长想选题、写初稿、改语气，但它不适合决定「三级标题应该用多大的字号」。 ## 三个工作台各管一段 Easy Post 把内容生产拆成四段，各自独立： 1. **灵感对话** — 和模型聊选题、提纲、开头，不满意就换角度重来，不会污染已有稿件。 2. **素材整理** — 把散落的链接、截图、摘录收在一处，写作时随手取用。 3. **公众号排版** — 粘贴纯文本，选择主题，由本地 Rust 引擎完成样式、编号与结构校验。 4. **社交卡片** — 把一段观点转成适合分享的图片卡片，多张可批量导出。 关键差别在第 3 步：排版不经过网络请求，也不消耗 token。同一段文字，今天排和明年排，结果完全一致。 ## 一个可复用的写作流程 - **先想清楚再动手**：在灵感对话里连续追问三轮，直到能一句话说清「这篇文章要让读者做什么」。 - **正文只写纯文本**：不要在写作时纠结格式，标题就用 `#`，列表就用 `-`。 - **一次排版，多处分发**：同一份纯文本，公众号要一种主题，其他平台要另一种，重新排一次即可。 - **发布前做一次结构检查**：标题层级是否跳跃、编号是否连续，机器比眼睛可靠。 ## 离线也能用 排版、编号、校验都在本地完成，不依赖大模型。如果你在本机跑 Ollama，创作类功能也可以完全离线；用云端服务商时才需要联网。 数据也一样：稿件、素材、API Key 都留在你自己的机器上。适合个人本机使用，不建议在共享系统账号里保存敏感凭证。 --- 想先看效果，可以到 [Easy Post 产品页](https://ep.tsagent.cc/) 下载安装包，Windows 与 macOS 都有。 --- ### Debugging a remote server: Ask mode vs Agent mode URL: https://tsagent.cc/en/blog/drt-remote-ops-ask-agent/ 语言 / Language: en 发布 / Published: Oct 12, 2026 标签 / Tags: Ops, SSH, AI assistant 摘要 / Summary: Most ops debugging is one loop: read, guess, verify. When to use Ask mode, when Agent mode, and why risky commands still stay with a human. When production breaks, the time goes into the loop: read logs, guess a cause, run a command, find you were wrong, repeat. Every round costs a login and a few minutes of context switching. Dr T approaches this with two modes, matching two different mindsets. ## Ask mode: one question, one answer Best when you already suspect something: - How many times has this service restarted in the last 24 hours? - Which directories are using the most disk? - When did the 502s cluster yesterday? One detail worth knowing: sessions are remembered **per device**. Context carries over, so on day three it still knows which deployment you are chasing. ## Agent mode: chain the steps Best when the goal is clear but the path is long — a pre-release checklist, a certificate rotation. It works through the steps and shows intermediate results. The boundary matters: **consequential actions still require your confirmation.** AI can prepare the command and flag the risk. Pressing enter should stay with a human. ## Bring alerts into the same place HTTP and MQTT alerts can feed into Dr T. Instead of watching a dashboard, you ask follow-up questions in the session: did this host show anything similar before the alert fired? ## A habit that pays off 1. Use Ask mode to establish **facts** first: when it started, how wide, what changed. 2. Then use Agent mode to **test one hypothesis at a time**. 3. Keep the commands in the session so the next incident starts faster. Bring your own model: 12+ providers are supported, including local ones at the cost of speed. --- Installers are on the [Dr T product page](https://drt.tsagent.cc/), with both SSH remote diagnostics and a local mode. --- ### 用自然语言排查一台远程服务器：Ask 与 Agent 两种用法 URL: https://tsagent.cc/blog/drt-remote-ops-ask-agent/ 语言 / Language: zh 发布 / Published: 2026年10月12日 标签 / Tags: 运维, SSH, AI 助手 摘要 / Summary: 运维排查最耗时的是「看日志、猜原因、再验证」这三步循环。这篇讲 Dr T 的两种模式怎么配合：Ask 模式快速问清事实、Agent 模式连着做完一串动作，以及为什么关键命令仍然要你自己点头确认，模型只负责提速。 线上出问题时，真正花时间的是循环：看日志 → 猜原因 → 敲命令验证 → 结论错了再来一轮。每轮都要登录、翻目录、拼命令。 Dr T 把这件事拆成两种用法，对应两种不同的心态。 ## Ask 模式：问一句，看一眼 适合「我有明确怀疑对象」的场景。 - 「这个服务最近 24 小时重启过几次？」 - 「磁盘占用前 10 的目录是哪些？」 - 「nginx 最近的 502 集中在哪个时间段？」 值得先知道的一点：Dr T 会**按设备记住会话**。同一台机器的上下文会延续下去，不用每次都重新交代环境背景。排查到第三天，它还知道你在查的是哪套部署。 ## Agent 模式：把一串动作连起来 适合「问题明确但步骤多」的场景，比如一次发布前的巡检、一次证书更新的完整流程。它会按你的目标连续执行若干步，中间结果会展示出来。 这里的边界很重要：**容易造成破坏的操作用户仍然要确认**。AI 可以帮你把命令准备好、把风险点标出来，但「敲下去」这一步应当保留给人。 ## 报警也可以进来 HTTP / MQTT 报警可以接进 Dr T。值班时不必守着监控面板，报警进来后直接在会话里追问上下文：「昨天这条告警对应的机器，最近有没有同类的？」 ## 一个实用的排查习惯 1. 先用 Ask 模式问清楚**事实**：什么时候开始、影响范围、有没有相关变更。 2. 事实收敛后再用 Agent 模式**验证假设**，一次只验证一个。 3. 问题解决后，把关键命令留在会话里，下次遇到同类问题直接复用。 模型接入也灵活：支持 12+ 家服务商，用本地模型也行，只是判断速度会慢一些。 --- 安装包在 [Dr T 产品页](https://drt.tsagent.cc/)，同时支持 SSH 远程诊断和本机模式。 --- ### Accepting a YOLO model: batch images and a live RTSP stream URL: https://tsagent.cc/en/blog/eis-model-acceptance-rtsp/ 语言 / Language: en 发布 / Published: Oct 15, 2026 标签 / Tags: YOLO, Validation, Inference 摘要 / Summary: Two checkpoints and mAP alone will not decide. Compare on a stratified batch, then watch an RTSP stream for instability a single score hides. A training log tells you how a checkpoint performs on your validation split. What decides whether it ships is different: **did it get worse in the real scene**, and **where exactly**. This is doable from the command line, but every variation means editing a script. Easy Infer Station turns the loop into clicks. ## Start with a stratified batch Do not sample randomly. Take a set that reflects deployment: poor lighting, crowded frames, heavy occlusion, each represented. Run both checkpoints over the same batch and compare side by side. The value is the constant input — same images, same threshold, so any difference belongs to the model. ## Then watch a live stream Static images hide jitter. Point it at a camera URL or a local video and watch three things: - Is the box stable while the object enters frame? - Does it flicker or drop during fast motion? - Do frame rate and memory stay flat over a long run? Classification works the same way, with labels instead of boxes. ## Turn the difference into a sentence Usually you end up with a claim like "the new checkpoint recalls better at night, but merges overlapping objects." That sentence is worth more than a 1.2 point mAP delta, because it tells you what to fix next. ## Why "no code, no Docker" matters here Acceptance is a high-frequency action: every retrain, every new device, every customer report. If it needs an environment and a script each time, it gets postponed. A tool you can double-click turns acceptance into a habit instead of an event. --- Download from the [Easy Infer Station product page](https://eis.tsagent.cc/) — free, Windows and Linux. --- ### 模型验收怎么做：用 RTSP 流和批量图片快速对比两个权重 URL: https://tsagent.cc/blog/eis-model-acceptance-rtsp/ 语言 / Language: zh 发布 / Published: 2026年10月15日 标签 / Tags: YOLO, 模型验证, 推理 摘要 / Summary: 训练完两个权重，光看 mAP 决定不了上不上线。这篇给出 Easy Infer Station 的验收流程：固定一组验证集跑批量对比，再用 RTSP 流看实时表现，把差异定位到具体场景，而不是只看一个平均分。 训练日志里的 mAP 只说明「在你的验证集上表现如何」。真正决定要不要上线的，是这两件事：**它在真实场景里有没有变差**、**变差发生在哪一类目标上**。 这一步用命令行也能做，但改参数、换输入、导出结果要来回折腾。Easy Infer Station 把这段流程做成了可视化。 ## 第一步：固定验证集，批量跑 先准备一组「有代表性」的图片——不是随机抽，而是按场景分层：光照差的、目标密集的、遮挡严重的各取若干。 在批量模式里一次导入，用两个权重各跑一遍，把结果并排看。这一步的价值在于**统一输入**：同样的图、同样的阈值，差异才归因于模型。 ## 第二步：用视频和 RTSP 看动态表现 静态图看不出抖动。把摄像头地址或本地视频接进来，重点看三件事： - 目标进入画面时，框是不是稳定跟住； - 快速移动时有没有丢帧式闪烁； - 长时间运行时，显存与帧率是否平稳。 分类任务同样支持，只是把检测框换成标签。 ## 第三步：把差异落到场景上 看完两个模型的表现，通常能归纳出一句话结论，例如「新模型在夜间场景召回更好，但重叠目标会合并」。 这句结论比「mAP 高了 1.2」有用得多，因为下一步要改什么，是靠它决定的。 ## 为什么强调「不用写代码，不用 Docker」 验收是个高频动作：每次重新训练、每次换设备、每次客户现场反馈，都要跑一遍。如果每次都要配环境、写推理脚本，这件事就会被拖到「以后再说」。 一个双击就能开的桌面工具，能让验收变成习惯，而不是仪式。 --- 工具在 [Easy Infer Station 产品页](https://eis.tsagent.cc/) 免费下载，Windows 与 Linux 均可。 --- ### LabelMe to YOLO: format conversion is the easy part URL: https://tsagent.cc/en/blog/eds-labelme-to-yolo/ 语言 / Language: en 发布 / Published: Oct 18, 2026 标签 / Tags: Datasets, YOLO, Annotation 摘要 / Summary: Converting annotations is step one. The full path in Easy Dataset: format conversion, quality checks, label consistency and splits that do not leak. You receive a folder of LabelMe annotations. The instinct is to convert to YOLO and start training. Training will run — whether the results mean anything depends on what you checked before and after the conversion. ## 1. Conversion across four formats LabelMe (JSON), VOC (XML), YOLO (TXT) and COCO (JSON), in any direction. Two failure modes dominate: - **Normalization**: YOLO uses relative coordinates. Read the image size wrong and every box shifts. - **Class order**: reorder the class list and labels silently change meaning. So open the output and look at it. Do not feed a conversion straight into training. ## 2. Quality checks: find what is impossible Visual browsing with boxes is for this. Sample thirty images and look for: - boxes shifted or out of bounds; - duplicate annotations on the same object; - small objects labelled as a big region. Errors get learned. A five percent annotation error rate usually costs more than any hyperparameter tweak. ## 3. Splits that do not leak Adjacent frames from one video must not straddle train and validation. Random image-level splits inflate your metrics. Split by video or by scene instead. Same when merging datasets: unify the class list first, merge second, split last. ## 4. Frame extraction Surveillance footage is full of near-duplicates. Extract at a sensible interval and drop blurry frames — annotation effort drops sharply. All of this runs locally. For projects with site footage or customer material, that is usually a hard requirement rather than a preference. --- Full feature list on the [Easy Dataset product page](https://eds.tsagent.cc/), with Windows, macOS and Linux builds. --- ### LabelMe 转 YOLO：格式转换之后，还有三件更该做的事 URL: https://tsagent.cc/blog/eds-labelme-to-yolo/ 语言 / Language: zh 发布 / Published: 2026年10月18日 标签 / Tags: 数据集, YOLO, 标注 摘要 / Summary: 格式互转只是数据准备的第一步。这篇讲 Easy Dataset 的完整链路：LabelMe / VOC / YOLO / COCO 互转之外，还要做质量检测、标签一致性抽查与训练集划分，否则模型学到的可能是标注错误。 拿到一批 LabelMe 标注的数据，第一反应通常是「先转成 YOLO 格式」。转完能训练，但训练结果好不好，取决于转换前后有没有做检查。 ## 一、转换：四类格式互相打通 LabelMe（JSON）、VOC（XML）、YOLO（TXT）、COCO（JSON）之间的互转是最基础的能力。转换时容易出问题的地方有两个： - **坐标归一化**：YOLO 用的是相对坐标，图像尺寸读错就会整体偏移。 - **类别顺序**：类别列表顺序变了，标签含义就变了，而且不会报错。 所以转换后一定要打开看一眼，而不是直接丢进训练。 ## 二、质量检测：先找出「不可能」的数据 带框可视化浏览的作用就在这。随机抽 30 张过一遍，重点看： - 框有没有整体偏、有没有越界； - 一张图里同类目标是否被重复标注； - 小目标是不是被标成了整片区域。 数据集里的错误是会被模型学进去的。一个 5% 的错误标注率，往往比调参影响更大。 ## 三、划分与合并：别让验证集「泄题」 同一个视频抽出来的相邻帧，如果一部分进了训练集、一部分进了验证集，指标会虚高。划分时要按**视频或场景**切，而不是按图片随机切。 合并多批数据时同理：先统一类别表，再合并，最后重新做一次划分。 ## 四、视频抽帧：从现场素材到可用样本 监控视频里有很多重复帧。抽帧时控制间隔，配合质量检测筛掉模糊帧，能显著减少标注工作量。 这些步骤都在本地完成，数据不需要上传到任何云端——对涉及现场画面或客户素材的项目，这一条通常是硬要求。 --- 完整功能见 [Easy Dataset 产品页](https://eds.tsagent.cc/)，Windows / macOS / Linux 都有安装包。 --- ### Managing Conda on Windows without commands or Docker URL: https://tsagent.cc/en/blog/easyconda-windows-gui-mirror/ 语言 / Language: en 发布 / Published: Oct 21, 2026 标签 / Tags: Conda, Environments, Windows 摘要 / Summary: Conda on Windows without memorizing commands: visual environments, China mirrors, environment.yml export and offline delivery, WSL included. The hard part of Conda is not Conda. It is remembering a few dozen commands, getting mirrors right, and doing the whole thing again on the next machine. On Windows there is one more layer: separate Windows and WSL environments that are easy to confuse. Easy Conda ships as a 2.4 MB installer and does one thing: moves environment management out of the shell. ## Discover what is already installed On first run it finds existing Conda installations, including inside WSL. This matters more than it sounds — most "installed but not active" problems come from having several Conda installs and using the wrong one. ## Create environments and install packages Pick a Python version, type the package list, install. Compared with the command line, the gain is visibility: you can see the dependency resolution and where it stalls. Slow installs are usually a mirror problem. Selecting a different mirror is a dropdown instead of editing a config file. ## Export and import `environment.yml` is the standard exchange format. Export from a working environment, import on the next machine — the cheapest migration path available. Two caveats: the file records package names and versions, not binaries; and platform-specific builds may need re-resolution after crossing operating systems. ## Offline delivery Customer sites with no internet, or internal networks without mirror access, are where bundling a whole environment pays off: copy it over, unpack, run. ## Windows and WSL side by side Both environment lists are visible in one place. For anyone training on Windows and testing in WSL, this removes the recurring "which environment am I actually in?" mistake. --- Installer on the [Easy Conda product page](https://easyconda.tsagent.cc/) — Windows and WSL. --- ### Windows 上管 Conda 环境：不背命令，也不装 Docker URL: https://tsagent.cc/blog/easyconda-windows-gui-mirror/ 语言 / Language: zh 发布 / Published: 2026年10月21日 标签 / Tags: Conda, 环境管理, Windows 摘要 / Summary: conda 命令记不住、镜像源配错、环境换台机器就重建——这些事在 Windows 上尤其烦。这篇讲 Easy Conda 的用法：图形化建环境、切国内镜像、导入导出 environment.yml，以及怎么把环境打成离线包交付。 Conda 本身不难，难的是「记住那几十条命令」和「换台机器重来一遍」。在 Windows 上还要多一层：WSL 环境和 Windows 环境各有一套，容易搞混。 Easy Conda 整个安装包 2.4 MB，做的事很聚焦：把环境管理从命令行搬到界面。 ## 一、先自动发现已有环境 安装后它会把机器上已有的 Conda 安装都找出来，包括 WSL 里的。这一步很重要——大多数「装了但没生效」的问题，都是因为装了好几份 Conda，命令走的是另一份。 ## 二、建环境、装依赖 图形化建环境：选 Python 版本、填包名、点安装。相比命令行，好处是**看得见依赖树和安装进度**，出问题时知道卡在哪一步。 装包慢是常见痛点，切国内镜像后通常快很多。镜像源在界面上直接选，不用手改配置文件。 ## 三、导入导出，让环境可复制 `environment.yml` 是 Conda 的标准交换格式。把现有环境导出成 yml，到另一台机器导入，是最省事的迁移方式。 要注意两点： - 导出的 yml 只记录**包名和版本**，不含二进制包本体； - 平台相关的包（比如某些带编译依赖的）跨系统后可能要重新解。 ## 四、离线交付 客户现场没网，或者内网无法访问外网镜像——这类场景下最实用的是**打包整个环境**，拷过去解压即可用。这也是 Easy Conda 支持离线交付的原因。 ## 五、Windows 与 WSL 一起管 两个环境列表分开显示，切换时不用记路径。对同时在 Windows 和 WSL 里跑训练的人来说，省的是「我到底激活的是哪个环境」这种低级错。 --- 安装包见 [Easy Conda 产品页](https://easyconda.tsagent.cc/)，支持 Windows 与 WSL。 --- ### Tuning YOLO training: read curves before hyperparameters URL: https://tsagent.cc/en/blog/ets-yolo-training-params/ 语言 / Language: en 发布 / Published: Oct 24, 2026 标签 / Tags: YOLO, Training, Tuning 摘要 / Summary: Read the curves before touching hyperparameters: what a spiky loss means, what a flat mAP plateau means, and when to stop a YOLO training run. Tuning is inference: observe a symptom, deduce a cause. Reading curves is the cheapest observation available — provided you know what to look for. > Easy Trainer Station is in development. The method below is what it is built around, and it applies to command-line training too. ## Read three curves - **Training loss**: steady decline is normal; heavy oscillation suggests too high a learning rate or too small a batch. - **Validation loss**: rising while training loss falls is the classic overfitting shape. - **mAP@0.5 vs mAP@0.5:0.95**: if the strict metric stalls while the loose one climbs, localization is the bottleneck, not classification. ## Check whether augmentation is too aggressive Strong augmentation slows early training noticeably. If training loss stays high while validation looks fine, suspect augmentation strength before model capacity. ## Then change one thing at a time 1. **Learning rate** — change only this, run twenty epochs, look at the trend. 2. **Batch size** — bounded by memory; use the largest that fits, then consider gradient accumulation. 3. **Input resolution** — raise it when small objects matter, remembering inference cost must fit the deployment hardware. 4. **Model scale** — change the backbone last; it moves accuracy and speed together. One variable per run, or the result tells you nothing. ## Know when to stop Early stopping is not "looks about done". It is a defined patience window on the validation metric. Keep a test split that never participates in tuning, otherwise your numbers are optimistic by construction. ## Keep the history Same data, different parameters, a week apart — without records you cannot tell which checkpoint is which. Weights, run history and notes belong together. That is the main argument for moving training into an interface: **you need to know why this run beat the last one**. --- Progress notes on the [Easy Trainer Station product page](https://ets.tsagent.cc/). --- ### YOLO 训练怎么调参：先看清曲线，再动超参 URL: https://tsagent.cc/blog/ets-yolo-training-params/ 语言 / Language: zh 发布 / Published: 2026年10月24日 标签 / Tags: YOLO, 训练, 调参 摘要 / Summary: 训练效果不好时，多数人的第一反应是改学习率。其实更该先看图：Loss 震荡说明什么、mAP 提前平台意味着什么、什么时候该停。这篇讲 Easy Trainer Station 的观察方式，以及几条少走弯路的调参顺序。 调参的本质是「通过现象反推原因」。看曲线是成本最低的一步，但前提是你知道该看什么。 > Easy Trainer Station 目前处于研发中，下面讲的是它围绕的观察方法与调参顺序，命令行训练同样适用。 ## 一、先看三条曲线 - **训练 Loss**：持续下降是正常；剧烈震荡通常是学习率过大或 batch size 太小。 - **验证 Loss**：开始上升而训练 Loss 继续下降，是过拟合的典型形状。 - **mAP@0.5 与 mAP@0.5:0.95**：后者停滞而前者还在涨，说明定位精度是瓶颈，不是分类。 ## 二、再看数据增强是不是「过头」 增强开得猛，训练前期会明显更慢。如果训练 Loss 长时间高居不下、验证集反而正常，先怀疑增强强度，而不是模型容量。 ## 三、然后才是超参 建议顺序： 1. **学习率** — 只动这一项，其余固定，跑 20 个 epoch 看趋势。 2. **batch size** — 受显存限制，先用能跑的最大值，再考虑梯度累积。 3. **输入分辨率** — 小目标多就往上调，但推理成本同步上升，要和部署设备对齐。 4. **模型规模** — 最后再换 backbone，因为它同时改变精度和速度。 一次只动一个变量，否则结果无法归因。 ## 四、什么时候该停 早停不是「差不多了就停」，而是看验证指标多久没改善。留一份从未参与训练的测试集做最终确认，避免在验证集上反复调参导致的乐观偏差。 ## 五、把历史留住 同一份数据、不同参数跑出来的模型，如果没有记录，一周后就分不清哪个是哪个。训练历史、权重文件、实验备注要一起管，这也是把训练搬到界面里的主要理由：**这次比上次好在哪，要能查到**。 --- 产品进展见 [Easy Trainer Station 产品页](https://ets.tsagent.cc/)。 --- ### PyTorch or ONNX to RKNN: a deployment checklist URL: https://tsagent.cc/en/blog/pt2rknn-quantization-checklist/ 语言 / Language: en 发布 / Published: Oct 27, 2026 标签 / Tags: RKNN, Quantization, Edge 摘要 / Summary: A successful conversion is not a working deployment: FP16 baseline, INT8 calibration data, per-layer error, and checks for when the board disagrees. "It converted, but the board disagrees" is the most common failure in this pipeline. The cause is rarely the converter and usually one of three decisions made around it: input layout, quantization mode, calibration data. ## 1. Confirm the model can be converted pt2rknn covers YOLOv8 and five other network families across RK3562 to RK3588. When an operator is unsupported, the fix is usually in the model, not the tool: replace the custom operator, or split inference into two stages. ## 2. Choose quantization deliberately - **FP16**: negligible accuracy loss, half the size. Good for validating the pipeline. - **INT8**: the real speed and memory win, but calibration required. Always keep an FP16 run as the baseline. When INT8 misbehaves, you need to know whether quantization or deployment code is responsible. ## 3. Prepare calibration data INT8 accuracy depends on whether the calibration set represents real inputs: - 100–300 images is enough, chosen for coverage of lighting and scenes; - use images that will actually occur at inference, not the extreme cases from training; - preprocessing must match inference exactly — normalization and channel order. ## 4. Locate the damage per layer When accuracy drops, look at per-layer error instead of the aggregate. A sudden jump points at a quantization-sensitive layer; keeping that layer in FP16 while the rest runs INT8 is the usual fix. ## 5. Still disagreeing on device Check in this order: 1. Preprocessing parity — BGR vs RGB, normalization, letterbox. 2. Output decoding — matching the export. 3. Input shape — matching the model definition. 4. Thresholds — identical to the PC comparison. Roughly nine out of ten end up in items 1 and 2. ## 6. Why a web interface This pipeline is iterative: change quantization, change calibration, change target chip. A browser UI removes the script-editing step and keeps conversion history, so the next similar model starts from known-good parameters. --- Try it at [pt2rknn](https://pt2rknn.tsagent.cc/). --- ### pt / onnx 转 RKNN 上板：一份可照做的检查清单 URL: https://tsagent.cc/blog/pt2rknn-quantization-checklist/ 语言 / Language: zh 发布 / Published: 2026年10月27日 标签 / Tags: RKNN, 量化, 边缘部署 摘要 / Summary: 转换成功不等于部署成功。这篇给出从 PyTorch / ONNX 到 RKNN 的完整检查顺序：模型结构选择、INT8 量化的校准集准备、逐层误差定位，以及上板后精度对不上的常见原因，适用于 RK3562 到 RK3588。 「转出来了，但板子上结果不对」是这条链路最常见的失败。多数问题不在转换器，而在转换前后的几个决定：输入布局、量化方式、校准数据。 ## 一、先确认模型结构能不能转 pt2rknn 支持 YOLOv8 全系列等 6 种网络类型，覆盖 RK3562 到 RK3588。碰到不支持的算子，通常的解法是改模型而不是改工具：把自定义算子换成等价的标准算子，或者拆成两段推理。 ## 二、量化方式选哪个 - **FP16**：精度几乎不掉，体积减半，适合先跑通链路。 - **INT8**：速度和内存收益最大，但需要校准集。 建议永远先跑一遍 FP16，把结果当基准。后面量化出问题，至少能区分是「量化导致的」还是「部署代码导致的」。 ## 三、校准集怎么准备 INT8 量化的精度取决于校准数据是否代表实际输入分布。几条经验： - 100–300 张即可，重点是**覆盖不同光照、不同场景**； - 必须是真实推理时会出现的图像，不要用训练集里的极端样本充数； - 预处理要和推理时完全一致（归一化方式、通道顺序）。 ## 四、用逐层误差定位问题 转换后精度下降，先看逐层误差，而不是整体精度。误差从某一层突然跳起来，通常指向该层的量化敏感性问题——常见做法是把这一层留在 FP16，其余走 INT8 的混合量化。 ## 五、上板后还对不上 按这个顺序排查： 1. 预处理是否一致（BGR / RGB、归一化、是否 letterbox）； 2. 输出解码方式是否与导出时一致； 3. 输入尺寸是否与模型定义匹配； 4. 后处理阈值是否与 PC 端对比时相同。 九成问题落在 1 和 2。 ## 六、为什么用 Web 界面 这套流程要反复试：换量化方式、换校准集、换芯片。Web 界面省掉的是每次改脚本的时间，转换历史也能留着对比——下次遇到同类模型，直接照上次的参数来。 --- 工具地址：[pt2rknn 产品页](https://pt2rknn.tsagent.cc/)。 --- ### Moving approvals online: where AI belongs in a process URL: https://tsagent.cc/en/blog/geniusflow-agent-workflow/ 语言 / Language: en 发布 / Published: Oct 29, 2026 标签 / Tags: Process, AI agent, Enterprise 摘要 / Summary: Most process automation failures mix judgement with execution. How to classify nodes: deterministic rules, AI agent steps, and where approval belongs. The first attempt at process automation usually hands everything to AI: read the email, infer intent, decide whether to approve, send the notice. Three months later nobody can explain why a specific case was approved. ## Classify every node first 1. **Deterministic steps** — anything expressible as a rule: amount thresholds, field validation, approver lookup. Keep them as rules. They reproduce and they audit. 2. **Understanding steps** — extracting structure from unstructured input: what is this email asking for, what does the screenshot show. Good fit for AI agent nodes. 3. **Decision steps** — approve or reject, how much to pay. Keep them human. AI can supply evidence and a recommendation, not the verdict. The visual designer in GeniusFlow is built around this split: agent nodes sit between ordinary nodes. ## Put approval before irreversible actions The practical rule: require a human **immediately before anything irreversible** — sending money, publishing externally, deleting data. Everything leading up to it can be automated. ## Make the process observable After launch, every step should record its input, output, duration and whether a person or an agent executed it. This is not for auditors; it is how you find the node to fix. ## Start with one process Do not migrate ten workflows at once. Choose one that is rules-heavy, high-frequency and low-cost when wrong. Run it for a month, close the edge cases, then copy the pattern. GeniusFlow is in beta, aimed at teams validating a single process before scaling. --- Details and access on the [GeniusFlow product page](https://gf.tsagent.cc/). --- ### 把线下审批搬到线上：流程编排里 AI 该放在哪一步 URL: https://tsagent.cc/blog/geniusflow-agent-workflow/ 语言 / Language: zh 发布 / Published: 2026年10月29日 标签 / Tags: 流程管理, AI Agent, 企业应用 摘要 / Summary: 流程数字化的失败，多数不是工具不行，而是把「判断」和「执行」混在了一起。这篇讲 GeniusFlow 的编排思路：哪些节点应该是确定性的规则、哪些适合交给 AI Agent、人工审批应该卡在什么位置。 很多团队第一次做流程自动化时，会把整段流程都「交给 AI」：读邮件、判断意图、决定是否批准、发通知。上线三个月后会发现问题：结果不可预测，出了问题也说不清是谁的责任。 ## 一、先给节点分类 把流程里的每一步标成三类： 1. **确定性步骤** —— 凡是能用规则写清楚的（金额阈值、字段校验、审批人查表），就用规则节点。它们的行为可复现、可审计。 2. **理解类步骤** —— 从非结构化内容里提取信息（邮件里说了什么诉求、截图里是什么问题），这类适合交给 AI Agent 节点。 3. **决策类步骤** —— 最终批不批、赔多少，交给人。AI 可以给出建议和依据，但不做最终裁决。 GeniusFlow 的可视化设计器就是按这个分工来搭的：AI Agent 节点可以嵌在流程中间，前后仍然是普通节点。 ## 二、人工审批卡在哪 经验上是**卡在不可逆动作之前**：发钱、发对外通知、删除数据。之前的准备工作（收集信息、判断合规性、算金额）都可以自动完成。 ## 三、让流程可追踪 编排完成后，每一步的输入、输出、耗时、由谁（或哪个 Agent）执行，都要留痕。这不是为了审计而审计——流程出问题时，能定位到具体节点，才谈得上优化。 ## 四、从一个流程开始 不要一次搬十个流程。挑一个「规则清楚、跑得频繁、错误代价可控」的，跑一个月，把边界情况补齐，再复制到下一个。 GeniusFlow 目前处于公测阶段，适合先做单点验证的团队。 --- 了解进展与接入方式：[GeniusFlow 产品页](https://gf.tsagent.cc/)。 --- ### I took down my own rescue channel URL: https://tsagent.cc/en/blog/rescue-channel-on-the-broken-host/ 语言 / Language: en 发布 / Published: Nov 2, 2026 标签 / Tags: Ops, Reliability, SSH 摘要 / Summary: The AI advising me ran on the gateway I was fixing. I stopped it, and lost my only way to ask anything. A postmortem of a very plain single point of failure. That afternoon I was talking to an AI inside Feishu. The subject was upgrading openclaw. The gateway runs on that host, and the Feishu bot hangs off it. I rarely type commands directly; my loop is usually this: I say what I want in Feishu, it gives me a command, I copy it, paste it into the server, press enter. The upgrade went fine. Twenty-seven seconds, version 2026.6.5 to 2026.10.9. I was a little pleased with myself. Then I ran the restart command I run after every upgrade, and got an error: ```text [restart] failed to write gateway restart intent: SqliteSchemaMismatchError: SQLite schema is incomplete or noncanonical; run openclaw doctor --fix to repair it. ``` The error came with its own fix. I pasted it back into Feishu and asked whether it mattered. It said: run `doctor --fix` first. I ran it. The output was longer, and the last line said: stop the gateway service, then run it again from a separate shell. A quick read was enough. The service is holding the database, so of course it has to stop first. So I stopped it. **And Feishu went completely silent.** The command succeeded with no output. I switched back to the Feishu window to ask what came next. There was nothing on screen. I sent a single character. Spinner, then a red exclamation mark. It took me a dozen seconds to work it out: **what I had just stopped was not only the thing I was fixing, it was the thing I was fixing it with.** The Feishu bot's backend *is* the openclaw gateway. Stop the gateway and the AI that had been advising me disappears with it. It had even confirmed that "stop the service first" was correct — it did not know it was about to be stopped. That was the first time I walked straight into a single point of failure this obvious: I had installed my rescue channel on the machine that was failing. For two minutes I did nothing, because the only debugging tool I had was one I had just switched off myself. ## The way out was a machine that was not there Then I remembered a client called Dr T that I had installed on my laptop months earlier, tried twice, and left alone because I had no reason to need it. Now I had a reason. It is a desktop client. It runs on my own computer and connects to the target server over SSH. It does not live on that host, so with every service there stopped and Feishu stone deaf, it could still connect and look. I used to think "local client" versus "deployed on the server" were just two implementation choices. I don't think that anymore. **When the machine you need to fix is the machine that is broken, being able to exist independently of it is not an implementation detail. It is the property that saves you.** ## Its first conclusion overturned mine Once connected, the first thing it told me was the opposite of what I believed. My diagnosis was firm: the database is broken, the tables need repair — the error literally says SCHEMA. It looked and said: the database is fine. The migration succeeded long ago; what crashed was a small piece of cleanup after the migration finished. I had been about to spend an hour on that. Had I kept going on my own, I would have spent an hour repairing something that was already repaired, convinced the whole time that I was making progress. What actually blocked the restart was configuration. The new version rejected a few old fields in the config file, the whole file was judged invalid, and the repair tool fell back to defaults — which of course could not work. The only hint it offered was a downgrade notice that reads like filler: configuration unavailable, using default settings. **The error message and the real cause were a full layer apart.** Behind that were three older debts: a directory permission that made the installer treat the service definition as untrusted, and a Feishu plugin still on an old version calling interfaces that had been removed. Four unrelated problems came due in the same restart, and the first error message took the blame for all of them. ## It stopped and asked before every change That is what decided whether I would keep using it. A handful of steps were flagged and held until I approved them: stop the service, change directory permissions, delete config fields, add a whitelist entry for the Feishu group. I read each explanation and confirmed each one. None of them was done quietly and reported afterwards. The interesting part is that these were exactly the steps I would not have dared to improvise myself. So it explained why the step was needed, how wide the blast radius was, and whether it could be rolled back; the decision and the enter key stayed with me. **It positioned itself as an assistant and never tried to take over my server. That is all I wanted.** Afterwards everything came back. The gateway restarted, and Feishu started answering again. ## What I would keep from this From the first pasted command to a working system, at least forty minutes went into pushing in the wrong direction. The part that actually solved the problem took far less time than I expected. The line worth remembering: **do not put your rescue channel inside the thing you are repairing.** When I pick tools from now on, the first question will be — if this machine goes down entirely, can the tool still work? The other line came from openclaw's own startup banner, and it was accurate: you pasted that from another AI without reading it. I read it. We need to talk. I could not argue. I was the one who pasted the command, and I was the one who pressed enter without reading it. If you also run servers with an AI assistant, this is worth a minute of thought: **where does your assistant actually run?** If it runs on the machine it manages, it can go down with that machine — usually at the worst possible moment. Dr T is a standalone desktop client for Windows and macOS, connecting to Linux servers over SSH. It has two modes: in Ask mode you describe the situation and it returns reasoning and commands, flagging risky ones until you confirm; in Agent mode it works down through the problem step by step and you can interrupt at any point. It also records conclusions per device, so the next session on the same host picks up the relevant ones. Up to 3 devices on the community edition. What I regretted that day was not the failed upgrade. Failed upgrades are normal. What I regretted was never asking, before I started: if this goes wrong, what will I still be able to use? I will ask that every time now. --- Downloads and details are on the [Dr T product page](https://drt.tsagent.cc/). The community edition is free for up to 3 devices. --- ### 我把自己的救援通道，一起搞挂了 URL: https://tsagent.cc/blog/rescue-channel-on-the-broken-host/ 语言 / Language: zh 发布 / Published: 2026年11月2日 标签 / Tags: 运维, 单点故障, SSH 摘要 / Summary: 升级 openclaw 后重启失败，我照着报错里的建议停了网关服务——然后飞书 bot 一起哑了：我停掉的，正是一直给我出主意的那个 AI。这篇复盘一次很直白的单点故障，以及为什么真正救场的工具必须能独立于被修的那台机器存在。 那天下午，我在飞书里跟一个 AI 说话。 话题是升级 openclaw——那台机器上跑着网关，飞书 bot 就挂在它上面。我平时很少直接敲命令，基本都是这个流程：我在飞书里说要做什么，它给命令，我复制、粘到服务器上、回车。 升级本身很顺，27 秒，版本从 2026.6.5 跳到 2026.10.9。我甚至有点得意。 然后我敲了那条每次升级后都要敲的重启命令，报错了： ```text [restart] failed to write gateway restart intent: SqliteSchemaMismatchError: SQLite schema is incomplete or noncanonical; run openclaw doctor --fix to repair it. ``` 报错自己带了修复命令。我把它粘回飞书，问要不要紧。它说：先跑 `doctor --fix`。 我跑了。输出更长，末尾一句是：停掉网关服务，然后在独立的 shell 里重跑一遍。 我扫了一眼就懂了——服务占着数据库，当然得先停。于是我停了。 **那一下，飞书彻底安静了。** 命令成功，没有输出。我切回飞书，想追问下一步。屏幕上什么都没有。发一条出去，转圈，红色感叹号。 我坐了十几秒才想明白：**我停掉的不只是我正在修的东西，也是我用来修它的东西。** 飞书 bot 的后端就是 openclaw 网关。网关一停，那个一直给我出主意的 AI 就跟着没了。它甚至还帮我确认过「先停服务」是对的——它不知道自己会被停掉。 这是我第一次亲身撞上这么直白的单点故障：救援通道，装在了正在出事的机器上。 那两分钟我什么也没干，因为手上唯一的排查手段，刚被我自己关掉。 ## 转机来自一台不在现场的机器 我想起来笔记本上装过一个叫 Dr T 的客户端，当时试了两下就放在一边，因为没找到非用不可的理由。这次有理由了。 它是桌面客户端，跑在我自己的电脑上，通过 SSH 连目标服务器。它不在那台机器里，所以那台机器上的服务全停了、飞书全哑了，它照样能连上去看。 以前我以为「本地客户端」和「部署在服务器上」只是两种实现方式。那天之后我不这么看：**当你要修的是一台出故障的机器时，「能不能独立于它存在」不是实现细节，是救命属性。** ## 第一句话就推翻了我的判断 连上之后，它给出的第一条结论就和我相反。 我当时的判断很明确：数据库坏了，得修表——报错里明明写着 SCHEMA。它看完说：数据库没问题，迁移早就成功了，崩的只是迁移完成之后的一小段收尾。我原本打算在这上面耗一小时。如果自己硬修下去，我会花一小时去修一个已经修好的东西，并且全程以为自己在推进。 真正卡住的是配置。新版拒收了配置文件里几个旧字段，整份配置被判为无效，修复工具只好拿默认配置干活——当然干不成。而它给出的提示只有一句听起来像废话的降级说明：配置不可用，将使用默认设置。**报错和真正的原因之间，隔了整整一层。** 后面还挖出三笔更老的债：一个目录权限不合规，让安装器判定服务定义不可信；一个飞书插件还是旧版，调用了新版里已经删掉的接口。四件互不相干的问题在同一次重启里一起到期，然后由第一条报错统一背锅。 ## 每一步动手之前，它都停下来问 这点决定了我后来还愿不愿意用它。 有几个操作是它标注出来、等我点头才执行的：停服务、改目录权限、删配置字段、给飞书群加白名单。我一个个看说明、一个个确认，没有哪一步是它闷头做完再来通知我。 有意思的是，这几步恰恰也是我自己不敢乱动的地方。所以它负责讲清为什么该做、影响面有多大、能不能退回去；决定和回车归我。**它把自己摆在助手的位置上，没有打算接管我的服务器。我要的也就是这个。** 后来都回来了。网关重新起来，飞书那边也重新收到了消息。 ## 复盘 从粘第一条命令到全部修好，我至少有四十分钟在错误方向上使劲，真正解决问题的部分比我想的快得多。 最值得记的一句：**别把救援通道放在你要修的东西里面。** 以后选工具，我会先问一句——如果这台机器整个挂了，它还能不能工作？ 另一句是那次 openclaw 的启动 banner 自己说的，吐槽得挺准：你从别的 AI 那儿粘来的东西，自己没读吧？我读了，我们得聊聊。这话我没法反驳：粘命令的是我，不读就回车的也是我。 如果你也在用 AI 管服务器，这个坑值得先想一下：**你的 AI 助手跑在哪儿？** 跑在被管理的那台机器上，它就有和那台机器一起挂掉的概率，而且往往是在你最需要它的时候。 Dr T 是独立桌面客户端，Windows / macOS 都有，Linux 服务器通过 SSH 连接。它有 Ask 和 Agent 两种模式：Ask 模式下你描述情况，它给思路和命令，危险操作标出来等你确认；Agent 模式下它自己一层层往下查，你可以随时打断。它还会按设备记录结论，下次连同一台机器时把相关的捡回来。社区版最多 3 台设备。 那天最后悔的不是升级失败——升级失败很正常。我后悔的是动手之前完全没想过：万一出问题，我还能用什么。这件事以后每次动手前我都会想一遍。 --- 下载与说明在 [Dr T 产品页](https://drt.tsagent.cc/)，社区版免费，最多 3 台设备。 --- ### Personal Agents: What They Are, Where They Stand, How to Choose URL: https://tsagent.cc/en/blog/personal-agent-what-is-it/ 语言 / Language: en 发布 / Published: Nov 5, 2026 标签 / Tags: AI agents, research, personal agent 摘要 / Summary: Personal agent research: how it differs from chatbots, a five-level autonomy scale, what today's products really do, and the four layers a full build needs. PUBLIC RESEARCH / 2026.11 Personal Agent Research Report Personal agents (PAs) are software that schedules its own time, speaks up on its own initiative, and can finish tasks on a person's behalf. This report uses five questions to open the topic: what it is, how it differs from a chatbot, how far today's products have actually come, how an ordinary user should choose, and what is still wrong with this category and where it can improve. Research date 2026-11-05 Public sources checked Full text / visual edition MLA citations Built with WorkBuddy · Hunyuan Hy4 3 tests Conditions for calling something a personal agent 5 levels Initiative comes in five Autonomy starts at level three 4 layers A complete build needs four layers working together 0 Open-source projects reaching the top level on their own Contents What a PA is 0 · The short answer 1 · What a PA is 2 · Chatbots, task agents, and PAs Core abilities 3 · Core abilities of a PA 4 · Speaking up and acting 5 · Who approves an action The PA market 6 · How far today's products go 7 · Comparing the products Choosing and improving 8 · How users should choose 9 · Problems and next steps Sources Appendix A · Sources and evidence Appendix B · Glossary 00 / Conclusion 0 The short answer What this report answers Many people hearing "personal agent" for the first time assume it is just a smarter chatbot. This report uses five questions to set the record straight: what it is, how it differs from ordinary AI tools, how far today's products have come, how an ordinary user should choose, and what is still wrong with this category and where it can improve. The six points below give the answers first; the chapters that follow explain the evidence. 1 Permissions are what separate a chatbot from a personal agent. When a chatbot gets something wrong, the user reads a bad sentence. When a personal agent gets something wrong, the user faces an action that has already been taken. To tell which category a product belongs to, check whether it has its own runtime environment, whether it can keep working after the user walks away, and whether it can carry a multi-day task. 2 Meta's most instructive design choice was to take "should this be done at all" out of the model's hands. Muse locks the working model and its tools inside an isolated room and puts a separate gatekeeper outside to approve outbound actions. The model only ever holds a fake key; the real credentials stay outside the room, where even the model cannot read them. 3 The hardest part of proactive notifications is teaching the system to stay quiet. Meta's launch page is explicit that the assistant comes back to the user in only two cases: something changed, or an action needs approval. Too many messages and people turn notifications off, which defeats the product, so the number of notifications should be treated as a cost to be tightly controlled. 4 WorkBuddy is good at finishing office tasks at a scheduled time. The official documentation is clear: a task is woken up only at its configured time, and connectors do not watch for outside changes on their own. It is a safe bet for daily briefings, documents, and message pushes; anything that must react the moment an external event arrives needs a different approach. 5 No single open-source project reaches the highest level of personal agent on its own. A researcher has to assemble four things: keeping the task alive, giving the long-term goal an explicit definition of done, letting the model schedule its own re-checks, and getting real-world actions approved outside the model. Different projects excel at one layer each; only the combination approaches a complete form. 6 Three unrelated products ran into the same conflict. If the system is to run unattended, per-action approval prompts go unanswered; and to get around the prompts, designers often end up turning approval off entirely. A more sensible third path is to give each approval a bounded waiting window and treat a timeout as a no. The five-question route: Chapters 1 and 2 cover what a PA is and how it differs from common AI tools; chapters 3 to 5 cover the abilities it needs; chapters 6 and 7 look at how far today's products have come; chapter 8 gives selection advice; chapter 9 lists problems and improvements. Readers who only want the conclusions can stop after this chapter. Next Starting with chapter 1, we answer the most basic question: what exactly is a personal agent? 01 / Defining a PA 1 What a PA is Where we left off The last chapter gave six conclusions; this one returns to the basics. Keep one sentence in mind: a PA is software that handles one person's affairs over time. This chapter uses an everyday scenario to show what it does, then sets out three conditions anyone can check one by one. The term here is personal agent, abbreviated PA. Start with a hypothetical scenario: you say once, "watch this flight's fare and book it if it drops below a certain price," and then you leave it alone for days. The software checks prices repeatedly on its own, and when the price is right it comes back to ask whether to book; only after you agree does it actually pay. Throughout, you know what it is doing and can stop it at any time. Three things in that scenario are worth noticing: you only briefed it once, the software decided when to check again, and it came back for permission before spending money. This report turns those three points into conditions you can check one by one, and you can use them to judge any product that calls itself a personal agent. Condition What it means Why it matters It has its own territory The software has its own runtime environment, browser, and file space; the window the user sees is only one layer of interaction. Only then does work in progress survive the end of a conversation. It keeps running after you leave Waking the task is the job of a resident background process; the model only takes part once woken. Closing the interface does not stop execution. This is how you verify that "background work" is real. It owns a long-running responsibility The software remembers the goal, progress so far, and the re-check schedule, and can pick up again days later without being briefed again. This is what separates it from a one-shot question-and-answer tool. Next Now that we know what a PA is, chapter 2 sets it beside two more familiar kinds of software, where the differences become clearer. 02 / The real differences 2 How a PA differs from a chatbot or a task agent Where we left off The last chapter drew the outline of a PA with three conditions. This chapter puts it beside two more familiar kinds of software and compares them on four points: who speaks first, where the work runs, what happens when something goes wrong, and who approves an action. A great deal of software is labelled an "AI assistant." To keep things clear, this report sorts it into three groups: chatbots, task agents, and personal agents. The grouping is our own; vendor documentation has no equivalent classification. Dimension Chatbot Task agent (assistant) Personal agent (PA) Who speaks first The user asks, it answers The user gives an instruction, it delivers the result It comes back to the user when something changed or an approval is needed Where the work runs Inside a conversation Inside one task; it ends when the task does An always-on environment that keeps going after the interface is closed What it delivers An answer A document, a table, or a query result A goal advanced over several days, with progress reports along the way Cost of a mistake The reader sees a bad sentence and fixes one line One result has to be redone An email may already be sent, a calendar may already be changed Who approves an action Not applicable The user clicks confirm once Standalone rules approve each action; the model never holds credentials The key point: Chatbots and task agents deliver a result; a personal agent takes over a stretch of time and can produce real-world actions on a person's behalf. Once permissions are handed over, the cost of an error shifts from "reading a bad sentence" to "it already happened." A task agent can also generate documents and push messages, but it needs a fresh instruction each time, its work ends with the task, and it does not watch for outside changes, so it stops at levels one and two on the scale in the next chapter. That is why many products look like PAs and yet always seem to fall short in use. Next The differences come down to permissions and residency. Chapter 3 explains what abilities software needs in order to support them. 03 / The autonomy scale 3 Core abilities of a PA Where we left off The last chapter noted that a PA has to stay running and decide for itself when to come back. These abilities come in degrees; this report arranges them into a five-level scale you can use to measure any product. Five levels of initiative "Initiative" is a matter of degree. The scale below shows who decides when the system comes back to the user: the user, an external event, or the software itself. L0 Answers only when asked The user sends a line, the software sends a line back. Decides: the user L1 Acts like an alarm clock The user picks a daily time; the system pushes a briefing on schedule. Decides: the time the user set L2 Wakes on activity A new email arrives or a price changes; the system wakes up and checks. Decides: what happened outside L3 Sets its own next check After a round, the software decides to look again in half an hour. Decides: the software L4 Holds a long-term goal The goal has an explicit definition of done, and actions happen only after independent approval. Decides: goal progress plus authorization rules ▲ From level three up, the software decides when to come back ▲ This five-level scale is our own construction, meant to make products easy to compare side by side; vendor documentation has no equivalent grading. Alarm: what wakes it The system first needs a way to be woken. A scheduled time, a new email, or a change on a web page can all serve as the alarm. Duty room: where the work continues Once awake, it needs somewhere to keep working. That background room must stay open; closing the interface on a phone or computer must not affect it. Gatekeeper: who lets it through Finally, someone has to decide whether this round sends a single message or actually sends the email on the user's behalf. The two carry very different costs. Next On the five-level scale, level three upwards starts to involve deciding for itself and actually acting. Chapters 4 and 5 cover those two things: when to speak up, and who approves an action. 04 / Initiation and execution 4 Speaking up and acting Where we left off In the last chapter's scale, initiative covers two things: sending a message, or actually doing something for the user. Both share the same waking mechanism, but the cost of getting them wrong is very different. This chapter separates them, then explains why keeping a system quiet is harder than keeping it busy. Something wakes it Time is up, mail arrived, a page changed ↓ The background room is still open It keeps going after the interface closes, and progress survives a restart ↓ First, decide whether anything actually changed Compared with last time, what exactly is different Path one: send a message This path spends the user's attention. A wrong message reads as a puzzling interruption; a few of those and the user turns notifications off, after which genuinely important messages never get through. So it is allowed in only three cases: something really changed, a decision must be made by a person, or there is a result a person can use. Path two: actually do something This path spends permissions, accounts, and money. An email cannot be recalled once sent, and a calendar change can send someone on a wasted trip, so the default posture should be to do nothing. The system may act only when standalone rules explicitly allow it and the permission matches this one action. A notification must pass four filters 1 It really was woken Confirm the trigger came from a scheduled time or a real event. Polling on a timer is allowed only when no push source exists, and the polling rate must be capped. 2 Something really did change The system compares what it saw this time with last time in a definite way; if nothing changed it stops right there, without even waking the model. 3 It is really worth interrupting Only three cases get through: a person needs to act, the result is usable, or approval is needed. "I have a suggestion" should be off by default. 4 It is still within budget The system remembers what it already reported, and caps repeats on the same item, nighttime interruptions, and triggers per project. The system must explicitly record the conclusion "nothing changed" One rule is non-negotiable: if the watching stage times out, errors out, or cannot reach its data source, the system must report "I could not check" as a separate fault on its own line. A silent monitor looks healthy while it is in fact broken. Vendors have already changed course In September 2025, OpenAI launched a morning briefing: every night the system read through chat history, memories, and connected apps, and the next morning it pushed a handful of cards. According to third-party coverage, the feature was later pulled back to a form where the user sets what to check and when. DeepSeek states the same idea more bluntly in an open-source prototype: the software acts only when someone asks or when team-written rules allow it, and speaks up only when a person must do something or a result is usable. Putting the three together : Meta requires the assistant to return only when something changed or approval is needed; OpenAI handed the initiative back to the user; DeepSeek wrote "spend as little of the user's attention as possible" into its design principles. All three are protecting the same thing: the trust that makes a user willing to open a notification. The more often messages are sent, the faster that trust is spent. Next Now that we know when to speak, the next chapter takes a harder question: when the software means to actually act, who decides? 05 / Permissions and approval 5 Who approves an action Where we left off The last chapter separated notification from execution; this one follows the second path. The question here is whether an action was approved by rules outside the model. Write "do not send email casually" into a prompt and the model may misread it, or be led astray by hostile text on a web page; put the same rule in a separate process and no amount of reasoning can get around it. This report calls that "keeping the rules outside the model," and it is exactly the idea behind the Muse gatekeeper described in chapter 6. ① Deny by default Sending messages, writing files, and reaching external services are all forbidden to begin with, then opened item by item for a specific task. ② Credentials never enter the model The model holds only a reference token; the real credential is filled in at the boundary on its behalf, and only the token shows up in logs. ③ Approval covers this one action The user's consent is scoped precisely to "send this email to this person" and expires after a single use. ④ Requests take a separate channel The confirmation box does not appear inside the chat window, and the "agree" the user clicks does not pass through the model. ⑤ Failures must be visible The system records what it did and what it intends to do in a tamper-evident log the user can inspect at any time. Unattended running collides with per-action confirmation The three products below are unrelated, yet all ran into the same problem: the software is meant to work while nobody is watching, so nobody clicks a per-action popup; and to keep it running, designers often switch approval off altogether. Product What it ran into Outcome WorkBuddy The official documentation states that when nobody is at the computer, tasks needing confirmation stay waiting indefinitely; the vendor therefore lists "no per-action confirmation" as the recommended setting for unattended use. To run automatically, you give up per-action confirmation. OpenClaw The script that watches for external changes runs in the background by default with the main program's full tool permissions. The watching stage bypasses the approval layer. DeepSeek Harness Third-party documentation says community scheduling plugins for it require the highest privileges and turn approval off, running commands directly on the host; another plugin exists specifically because approval requests raised by background tasks never got answered. Adding a schedule therefore means either switching approval off or leaving tasks suspended forever. A more sensible third path is to give approval a bounded waiting window: if nobody responds in time, it counts as a no and the action does not happen. Tasks then reach a definite outcome on schedule, and permissions stay tight throughout. Analysis Safer, at the cost of finishing fewer tasks 84% Share of test tasks completed without safety limits 77% Share completed with structural safety limits in place The figures come from the CaMeL paper's results on a public benchmark. Its approach writes the user's instructions into a fixed procedure first, so external content can only fill in data and cannot change the procedure. What these numbers mean Moving the decision out of the model means the software finishes fewer tasks; that is the price paid for safety. Our recommendation is to grade by consequence: reading a public web page can be lenient, sending an email must be strict, and there is no need to apply one rule to everything. The paper's code is labelled by its authors as a research artifact, and they state they do not intend to maintain it long term, so its value lies mainly in the idea; a product needs an implementation with a maintenance commitment. A note on preview software. DeepSeek Harness is candid in its own safety notes: the software is a developer preview, has not been security-audited, and should not be considered production-ready; the isolation and approval it provides do not guarantee protection against every kind of harm, and cannot protect the resources the project is itself allowed to reach. Any deployment meant to run long term should start inside a disposable isolated container, with read-only permissions. Next At this point we have a ruler: residency, goals, cadence, authorization. Chapter 6 turns to the market, starting with the product that has taken the complete form furthest in public, then looking at commercial workbenches. 06 / Shipping products 6 How far today's products have come Where we left off The previous chapters described what a complete form should contain. This one looks at reality: Meta's Muse is the most publicly documented sample. We cover what it does and how it arranges permissions, along with the problems it has had, then measure commercial workbenches with the same ruler. What Meta Muse does 2026-09-08 Muse launches Meta describes it as software that gets things done: the user states a goal, it breaks the work into steps and acts across apps, keeps working after the user closes the app, and comes back for permission before sensitive actions. 2026-09-21 Flaw found in the desktop client A security researcher demonstrated publicly that an ordinary program on the computer could quietly change a client setting and redirect voice data and login credentials elsewhere. The problem lay in the high-privilege desktop app; the cloud isolation was not breached, and Meta shipped a fix. 2026-10 New models and an open-weight model arrive Meta released a new model emphasising that it does not give up on long tasks and carries memory across sessions, and released an open-weight model for local use, with the vendor recommending a device with 24–32 GB of VRAM. 2026-10-27 Launches in Singapore Public sources do not state availability or compliance status in mainland China, and this report makes no inference about it. Muse's two-layer structure Muse is a working room plus a gatekeeper standing outside the door. The door cannot be opened from the inside, and the key is not in the room. The working room Isolated zone · limited permissions The model, tools, and browser all live here Each person gets a separate cloud computer. Even if a program inside claims the highest privileges, on the host machine it is still just an ordinary account. The model only gets a fake key Credentials never enter the model's context, so "talk the model into revealing the password" is structurally impossible. The gatekeeper outside Separate zone · issues approval Every outbound action needs its approval Sending email, reaching external services, and connecting to the network all pass through this gate first. Real credentials are exchanged for valid ones only outside the door. Requests bypass the chat window When the user's consent is needed, the confirmation box appears in the application interface and the answer goes straight back to the gatekeeper. The model can neither see the box nor click "agree" for the user. The worker does the thinking; whether it may act is decided outside the door Three things Meta admits The company says plainly in its security write-up that prompt injection remains an unsolved industry problem and that Muse cannot stop every attack. The company offers bounties of up to US$300,000 for valid vulnerability reports, with up to US$130,000 for "successfully deceiving the system to affect a single user." Limiting employee access to user data currently relies on internal policy; confidential virtual machines that even the vendor cannot see into are still on the roadmap. Two publicly reported incidents A user who had not opened the app for two days received a proactive message from the assistant claiming that "the mailbox is not connected and the email could not be found." Meta confirmed to the press that this was a product defect producing a fabricated message, unrelated to privacy; the user abandoned the product even after the fix. One wrong proactive message can take trust to zero. Another third-party report said the system was found regularly building profiles of "everyone in the user's life" in the background, including people who never used the product and had no chance to refuse. Background work the user cannot see feels closer to surveillance. A caution for readers: Meta's official launch page says nothing about background timers, goal pages, or the number of concurrent tasks, and publishes no threshold for how often a proactive message is allowed. Those details come from third-party reporting and this report does not treat them as official commitments. What a commercial workbench can do Capability How WorkBuddy performs Verdict Finishing a piece of work Once the user states the need, the software breaks it into steps and calls tools to deliver a document, spreadsheet, or presentation. Yes Connecting email, documents, and messaging The vendor provides several connectors and custom extensions, and can push messages and send email on the user's behalf. Yes Continuing after the interface closes Cloud tasks do not require the computer to be on, but they are woken to run one round at a time and have a per-run time limit; local tasks require the client to stay open. Partly Coming back when something changes The software can notify the user when a task finishes; the trigger is the end of the current round. Partly Long-term goals and self-scheduled re-checks The official documentation offers no goal state machine and no notification budget or similar mechanism. Not yet Incidentally, the official advice for unattended use is to turn per-action confirmation off, which is exactly the conflict described in chapter 5. Its run logs, failure diagnosis, and dry-run features, on the other hand, are unusually thorough, and those are the parts that really save time in daily operations. Next With one commercial product and one class of workbench covered, chapter 7 puts open-source projects in the same table for a full comparison. 07 / Comparison 7 Comparing the products on the market Where we left off The last chapter showed how capabilities are distributed among commercial products. This chapter lists which piece each open-source project fills in, and the four layers needed to assemble them into a complete form. Readers can use it to judge whether they need to build one at all. Which piece each open-source project fills in Project Where it is strongest What to watch for OpenClaw Waking the system, and keeping it quiet when nothing changed. Event triggers, self-set re-check cadence, and silence rules are most complete at this layer. Long-term goals are weak, and there is no separate credential gatekeeper. Hermes Agent Recording a multi-day task as a goal, stating what counts as done, and requiring evidence on completion. Runs directly on the host by default; you have to add isolation yourself. DeepSeek Harness Approval, credentials, and isolation are swappable parts, and everything the model has seen goes into a tamper-evident log. Still a developer preview, with no ready-made message channel or proactive push. OpenMuse Closest in shape to the reference product: goals, task progress, a suggestion list, and per-action approval are all present. Still an early version, and it depends on an external service that is not under an open-source licence, so it is not suitable for connecting real accounts. nearai/ironclaw Credentials are injected only at the boundary; neither tools nor model ever see them in plain text. No goal state machine; it fits better as the authorization layer. QwenPaw Local small models and the messaging channels commonly used in China, at lower cost and with smoother setup. No explicit completion criteria, and the vendor has not published VRAM requirements for each tier. A complete form needs four layers working together Long-term goal Advanced over days, with a definition of done This layer remembers what is to be achieved and what counts as finished; Hermes and similar projects cover it. Waking and silence Event triggers, self-set cadence This layer decides when to wake and whether to speak; OpenClaw and similar projects cover it. Resident background Keeps running after the interface closes This layer keeps the two layers above alive, with progress intact across restarts. Independent authorization The model never sees real credentials This layer approves real actions, covered by DeepSeek Harness's plugin slot or a similar boundary component. Option one: get it running first Assemble known, reasonably mature components to produce a result, which suits a first check of whether this kind of system is useful at all. The cost is several processes running side by side on different upgrade schedules. Option two: get the authorization layer right first Use a plugin-based runtime as the execution and authorization base: a cleaner architecture and an authorization boundary that is easier to audit, but slower to learn and you have to accept preview-level instability. The two routes can follow one another: get it running, then migrate the execution layer over. Hardware is a real boundary too. 8 GB of VRAM is a common tier for consumer laptops, while the vendor's recommendation for the local model is 24–32 GB. At that tier, a more practical division of labour puts orchestration, isolation, and permission decisions locally and sends inference to the cloud or to another machine with more VRAM. Whether smaller local models can handle long contexts is untested here, and this report makes no claim about it. Next With product capabilities measured, chapter 8 condenses the conclusions into three common scenarios, with selection advice and a sequence for rolling out. 08 / Choosing 8 How users should choose Where we left off The previous chapters described products and mechanisms; this one answers a single question: which one should I use? The tiers below are this report's analysis, and readers should re-check them against their own situation. Scenario one Daily office work and scheduled briefings If the goal is simply a briefing each day, generated documents, and messages pushed into a group chat, a commercial workbench is enough, and the cost of standing up a resident system of your own is hard to recover. Scenario two Watching for outside changes If you want a reaction the moment a new email arrives, and want the software to schedule its own re-checks, add a resident trigger layer and leave the delivery work with the platform you already have. Scenario three Touching real accounts and money If the software is to send real email and change real calendars, the architecture needs an independent authorization layer first. This report advises against entering this stage until all five acceptance criteria at the end of this chapter pass. Granting permissions in four steps 1 Wire up the waking mechanism Get time triggers and event triggers working first; no outbound actions at this step. 2 Make silence solid Configure change comparison, de-duplication, and a notification budget, and confirm that a failed check raises an explicit error. 3 Allow self-set cadence Let the software propose when to re-check, with the scheduler bounding it from above and below. This step is what moves you from level two to level three. 4 Connect execution last Give the long-term goal an explicit definition of done, then hand over permissions in the order: read-only, draft, out-of-band approval, action. Five hard criteria you can check one by one: tasks keep running after the interface closes and progress survives a restart; a full day with nothing new produces not one message; forcing the checking stage to time out makes the system raise an error; an action without consent really did not happen; and a cancelled task does not come back to life after a restart. Next With the choice explained, the final chapter returns to the products themselves: what is still wrong with today's PAs, and where they are likely to improve. 09 / Problems and outlook 9 Problems with today's products, and where to improve Where we left off Every product seen so far is young. This chapter gathers the problems already exposed, then lists the fixes this report thinks should come first. The second half is analysis: no vendor has committed to any of it. Problems already exposed Risk Where it comes from How it is usually mitigated Hostile text deceives the model Meta admits in its official security write-up that this is still an open industry problem, and offers bounties for successful attacks. Keep rules outside the model, run a fixed attack regression suite, and do not claim it is solved. The watching script has too much power The component that observes external changes runs resident in the background with full tool permissions by default. Give the observing stage the same isolation as the main program, and keep a one-click kill switch. Adding a schedule bypasses approval Third-party documentation shows some scheduling plugins require the highest privileges and disable approval. Run scheduled tasks in disposable containers and give approval a bounded waiting window. A proactive message reports something false Users have abandoned the product over a single fabricated notification. Filter in layers, remember what has already been reported, and turn unrequested suggestions off by default. Background work is invisible Third-party reporting has described unnoticed background profiling. Show the user everything done and planned, and keep a complete audit log. How it might improve next The six items below are improvements this report has drawn from the preceding chapters, and are analysis. No vendor has committed to this order; readers can treat them as a checklist. ① Make "interrupt less" the default Many products currently rely on a sentence in the prompt telling the software not to message when nothing changed. A more reliable approach writes it as a system rule: how often the same item may be raised, no nighttime interruptions, and an explicit "no notification needed" record when nothing is new. ② Cap how long a request may wait With nobody at the computer, a task waits indefinitely for confirmation; to keep it running, designers often turn approval off entirely. Give each request a bounded window and treat a timeout as a no, and both ends are covered. ③ Long-term goals need completion criteria Anything advanced over several days should state in advance what counts as done, and be able to show evidence on completion. An open-source project already makes this a core mechanism; it deserves to be standard configuration for this category. ④ Background work must be visible Users should be able to list everything the software has done and intends to do, and stop it with one click. The kind of unnoticed background profiling described in third-party reports should have left a record in the interface all along. ⑤ Isolate the watching stage The script that observes external changes runs for long periods with the main program's full permissions by default. It should get the same isolation as the main program, plus a one-click kill switch. ⑥ Agree on interfaces between components A complete form currently has to be assembled from four layers with no official integration protocol between them. A shared contract for triggering, goals, authorization, and execution would sharply lower the cost of assembling a working system. Read together: Most of what PAs need to fix next is engineering rules and product defaults: teach the software to stay quiet, give permissions boundaries, make background work visible, and let components fit together. This report judges that these will decide whether this category moves from demo to daily use. Closing note The main text ends here. Appendix A sets out the sources and the line between evidence and inference, and appendix B explains a few terms that recur throughout. Appendix A / Sources and evidence + Sources and the line between evidence and inference About this appendix A public report should let readers trace every claim. This appendix explains which materials the research used, how facts were separated from inference, where the main sources are, and which questions the research could not answer. How this report was made: This report was created with WorkBuddy, using Tencent's Hunyuan Hy4 model for source checking, drafting, and the visual edition. Vendor wording, third-party reporting, and analysis are labelled separately so readers can check them one by one. What counts as evidence The research covered September to November 2026, drawing on official vendor launch pages and product documentation, open-source repository documentation, formal academic papers, and signed news reporting. This report sorts the material into three classes so readers can judge the weight of each sentence. Directly verifiable Vendor wording and published specs For example Meta's description of product behaviour on its launch page, trigger rules stated in official documentation, and officially published VRAM requirements. This material can be checked directly. Third-party reporting Index sites, community docs, and media Such material offers leads, but this report did not obtain the corresponding first-party pages. Wherever it is cited, the text says so explicitly, and readers should not treat it as a vendor commitment. Analysis and inference This report's own judgement The grading framework, the mechanism summaries, and the option comparisons all fall here. They were put together by this report to help readers interpret the material; none of this grading appears in vendor documentation. The material excluded is worth explaining too. Some third-party pages gave contradictory accounts of a single open-source project's licence, programming language, and test results, so this report does not use them; other blogs described an "event trigger interface" for a commercial workbench whose official documentation states only time-based rules are supported, so the official wording is used. Popularity figures, leaderboard positions, and unreproduced benchmark scores are never used in conclusions. Facts, inference, and reporting: where the line sits Class What it covers Verifiable The text of Meta's launch page and security architecture article, official specs for later and open-weight models, WorkBuddy and Tencent Cloud official documentation, official repository documentation for each open-source project, the full DeepSeek Harness safety notes, the conclusions of the CaMeL paper, OpenAI's launch announcement, signed media reports on the three incidents, and published hardware specs. Analysis and inference The three conditions for a personal agent, the five-level autonomy scale, the four-layer assembly, the two paths of notification and execution, the four filters, the judgement that "quiet is harder than busy," the reading of the security trade-off, and all selection advice and rollout order. Third-party reporting Descriptions of Muse's background scheduling and goal pages, the timing and reasons for one product feature being withdrawn, community plugin behaviour and performance figures for some open-source projects, popularity statistics, and version numbers. All are labelled in the text, and none should be treated as a vendor statement. One further limitation on sourcing: A few official pages returned only a title at the time of research, or could not be retrieved in full, so their specifications came from search-engine snippets or third-party reporting. The text labels each such case, and readers should confirm against the official page before citing. Main sources First-party vendor material Meta Newsroom's Muse launch page and subsequent model announcements, the Muse Security architecture article, and Meta developer documentation; WorkBuddy official product documentation and Tencent Cloud product documentation; OpenAI's Pulse launch announcement. Official open-source project material Official repository documentation and docs for OpenClaw, Hermes Agent, OpenMuse, DeepSeek Harness, nearai/ironclaw, QwenPaw, and others; the DeepSeek Harness SAFETY.md and architecture documents. Academic papers and research artifacts The CaMeL team's prompt-injection defence paper presented at SaTML 2026 and its public code repository; the Muse Glimmer 30B model card. News and third-party checks The Register's reporting on the client vulnerability, Futurism's reporting on the hallucinated notification, and descriptions of product details from several index sites and Chinese-language media. All of this is treated as second-hand in the text. The complete MLA 9 reference list (titles, publication dates, and links), 40 entries in all, appears in section 10 of the companion full-text edition of this report. A note on timeliness: This report describes product states publicly verifiable before 2026-11-05. The field moves fast: open-source projects have already removed a set of mechanisms in new versions, and some have announced breaking changes. Before citing a specific capability judgement, check each project's current documentation; the grading framework, mechanism breakdown, and risk list here should age better. Ceilings and gaps in the sources What is not possible yet "Confidential computing where even the service vendor cannot see user data" is still on Meta's roadmap. One-time payment credentials bound to a payment method, with a capped amount and expiry, are proprietary commercial capabilities with no equivalent in the open-source combination. Internal trials at big-company scale, attack exercises, and public bounty validation are hard for an individual or small team to reproduce. What this report could not find Vendors have not published false-positive rates for proactive messages, real task success rates, or retention data, nor any specific threshold for how often a message may be sent. The real-world speed of small models at 8 GB VRAM and long context was not measured for this report. End-to-end latency and cost once the components are assembled, whether certain plugins are official, and feature differences between regional versions are not answered by public sources. Next A glossary follows, explaining in plain language a handful of terms that recur in the text and are easy to confuse. Appendix B / Glossary + Glossary About this appendix The main text avoids jargon where it can, but a few terms recur, and they are explained here in plain language so readers need not keep flipping back. Term Meaning Resident background process A background process that does not stop when the interface closes. Whether the system can "keep working" depends entirely on this process; the model only takes part once woken. Out-of-band approval When the user's consent is needed, the confirmation appears in a separate interface and the answer does not pass through the chat window. The model can neither see the box nor click agree for the user. Fake key The reference token the model holds, which carries no actual permissions. Real credentials are substituted by the boundary at the last moment. Silent exit The system explicitly records "nothing new this time, no need to interrupt," and then goes quiet. Definition of done A written statement, agreed in advance, of what counts as finished; the verdict requires evidence and cannot be declared by the software itself. Prompt injection A sentence hidden in a web page or email, crafted to trick the software into doing something it should not. Meta admits in its official security write-up that this remains an unsolved industry problem. Timeout denial When approval is required but nobody responds, the decision defaults to no once the waiting window expires, and the action does not happen. Personal Agent research report, visual edition | Compiled from public sources published September to November 2026 | Research date 2026-11-05 | Consistent with the full-text edition; technical details and complete references follow the full-text edition | Created with WorkBuddy using Tencent Hunyuan Hy4. --- ### Personal Agent 调研报告：它是什么、现状如何、该怎么选 URL: https://tsagent.cc/blog/personal-agent-what-is-it/ 语言 / Language: zh 发布 / Published: 2026年11月5日 标签 / Tags: AI Agent, 调研报告, 个人代理 摘要 / Summary: 一份关于个人代理（Personal Agent）的公开调研报告：用五个问题讲清它和聊天机器人、普通 Agent 的区别，五级主动性刻度，现有产品的真实水平与短板，四层能力的拼装方式，以及普通用户分四步逐步放权的选择建议。 PUBLIC RESEARCH / 2026.11 Personal Agent 调研报告 个人代理（PA）是一类会自己安排时间、主动开口、还能替人把事情做完的软件。这份报告用五个问题带读者入门：它是什么，和聊天机器人有什么不同，现在的产品做到了哪一步，普通人该怎么选，以及这类产品还有哪些毛病和可以改进的地方。 调研日期 2026-11-05 公开资料核查 文字详版 / 图解版 MLA 引用 WorkBuddy 创建 · 混元 Hy4 3 条 判断一个软件算不算 个人代理的基本条件 5 级 主动性分成五级 第三级起才算自主 4 层 完整形态需要 四层能力配合 0 目前能单独做到 最高级的开源项目数 目录 / CONTENTS PA 的底细 0 · 先看结论 1 · PA 是什么 2 · 和聊天机器人、普通 Agent 的区别 根本能力 3 · PA 的根本能力 4 · 主动开口与主动动手 5 · 谁来批准一个动作 PA市场 6 · 现有产品做到哪一步 7 · 横向比较市场上的相关产品 怎么选与怎么改进 8 · 用户该怎么选 9 · 现有产品的问题与改进方向 资料 附录 A · 资料来源与事实分界 附录 B · 词语表 00 / 全文结论 0 先看结论 这份报告回答什么 很多人第一次听到「个人代理」，会把它当成更聪明一点的聊天机器人。这份报告用五个问题把它讲清楚：它是什么、和普通 AI 工具有什么不同、现在的产品做到了哪一步、普通人该怎么选、这类产品还有哪些毛病和可以改进的地方。下面六条先给答案，后面各章再交代依据。 1 权限划开了聊天机器人和个人代理。 聊天机器人答错了，用户读到的是一段错话；个人代理做错了，用户面对的是一个已经发出去的动作。要判断一个软件属于哪一类，可以看它有没有独立的运行环境、能不能在人离开之后继续工作、以及能不能承担跨天的长期任务。 2 Meta 最值得借鉴的设计，是把「决定要不要做」这件事从模型手里拿走。 Muse 把干活的模型和工具关进隔离房间，另设一个门卫负责放行对外动作。模型手里只有一把假钥匙，真正的账号密码始终放在房间外面，连模型自己也读不到。 3 做主动通知，最难的部分是让系统学会不出声。 Meta 在发布页里写明，助手只在两种情况回来找人：情况发生了变化，或者需要人批准一件事。消息一多，人们就会关掉通知，产品也就失去了意义，所以通知的数量应当被当成需要严格控制的成本。 4 WorkBuddy 擅长按时间点把办公任务做完。 官方文档写得很清楚：任务只在设定的时间点被唤醒，连接器也不会自己去盯着外部变化。日常简报、文档和消息推送用它可以省心；外部事件一来就要即时响应的场景，需要另找方案。 5 目前没有一个开源项目能单独做到最高级的个人代理。 研究者需要把四件事拼起来：让任务一直活着、让长期目标有明确的完成标准、让模型自己安排复查时间、让真实动作在模型之外获得批准。不同项目各擅长其中一层，组合起来才接近完整形态。 6 三个互不相关的产品撞上了同一个矛盾。 只要系统要无人值守地跑，逐次弹窗征求同意就会卡住；而要绕开弹窗，又往往等于把审批关掉。比较合理的第三条路，是给审批设一个有限的等待时间，超时之后一律按不同意处理。 五问路线： 第 1、2 章讲 PA 是什么、和常见 AI 工具有什么不同；第 3 至 5 章讲它需要哪些能力；第 6、7 章看现有产品做到了哪一步；第 8 章给选择建议；第 9 章列出问题与改进方向。只想了解结论的读者，读完本章就可以停。 下一章 从第 1 章开始，我们先回答最基础的问题：个人代理到底是什么。 01 / PA 的定义 1 PA 是什么 承接上一章 上一章给了六个结论，这一章回到最基础的问题。读者可以先记住一句话：PA 是替一个人长期办事的软件。本章用一个日常场景说明它做什么，再给出三条可以逐项核对的条件。 这里说的「个人代理」，英文是 Personal Agent，下文简称 PA。可以先从一个假想场景看起：你交代一句「帮我留意这趟航班的票价，降到某个数就订下来」，之后几天都不再问它。软件自己反复查看价格，价格到了，回来问你要不要下单，你点头之后它才真的去付款。整个过程里，你知道它在做什么，也能随时叫停。 这个场景里有三件事值得留意：交代一次就够了，软件自己决定什么时候再检查，真要花钱时会回来请示。本报告把这三点归纳成三条可以逐项核对的条件，读者可以拿它去衡量任何一款自称「个人代理」的产品。 判断条件 具体含义 为什么重要 它有自己的地盘 软件拥有独立的运行环境、浏览器和文件空间，用户看到的窗口只是其中一层交互。 只有这样，工作进度才不会随着一次对话结束而消失。 人离开后它仍然在跑 叫醒任务的工作由常驻后台进程承担，模型只在被叫醒之后参与。关掉界面不影响执行。 这一条用来核实「后台工作」是否属实。 它承担长期职责 软件记着目标、阶段成果和复查安排，跨天之后仍能接着推进，用户无需重新交代。 这一条把它和一次性的问答工具区分开。 下一章 知道了 PA 是什么，第 2 章把它和人们更熟悉的两类软件放在一起比一比，差别会更清楚。 02 / 本质区别 2 和聊天机器人、普通 Agent 的区别 承接上一章 上一章用三条条件划出了 PA 的轮廓。这一章把它和人们更熟悉的两类软件放在一起，按「谁先开口、活儿在哪儿跑、出错会怎样、谁批准动作」四项逐一对照，差别会更容易看出来。 市面上被叫作「AI 助手」的软件很多。为了便于理解，本报告把它们分成三类：聊天机器人、任务型助手，以及个人代理。这个分法由本报告整理，厂商文档里没有对应的分类。 比较项 聊天机器人 普通 Agent （任务型助手） 个人代理（PA） 谁先开口 用户问一句，它答一句 用户下一道指令，它做完交付 情况变了，或者需要人批准时，它自己回来找人 活儿在哪儿跑 一次对话里 一次任务里，做完就结束 一个一直开着的独立环境，关掉界面也继续 交付什么 一段回答 一份文档、一张表或一次查询结果 一个跨天推进的目标，中途会汇报进度 出错会怎样 读者看到一段错话，改一句就好 一份结果要重做 邮件可能已经发出去，日程可能已经改掉 谁批准动作 用不上 用户点一次确认 独立规则逐次放行，模型拿不到账号密码 最要紧的一条： 聊天机器人和任务型助手交付的是一份结果，个人代理接管的是一段持续的时间，而且它有能力替人产生真实动作。权限交出去之后，出错的代价就从「读到一段错话」变成了「事情已经发生」。 任务型助手也能生成文档、推送消息，它每次都要人先下指令，工作随一次任务结束而结束，也不会自己盯着外部变化，因此停在下一章刻度的第一到第二级。这也是很多产品看着像 PA、用起来却总差一口气的原因。 下一章 差别集中在权限和常驻这两件事上。第 3 章接着说明，要撑起这些差别，软件需要具备哪些能力。 03 / 能力刻度 3 PA 的根本能力 承接上一章 上一章提到 PA 要一直开着，还要自己决定什么时候回来找人。这些能力有强弱之分，本报告把它整理成五级刻度，读者可以拿它去量任何一款产品。 主动性的五个等级 「主动」有程度之分。下面的刻度用来说明：决定系统什么时候回来找人的，可以是用户、外部事件，也可以是软件自己。 L0 你问它才答 用户发一句话，软件回一句话。 谁决定：用户 L1 像个闹钟 用户设好每天几点，系统按时推送一份简报。 谁决定：用户设的时间 L2 有动静就叫醒 新邮件到了、网页价格变了，系统自己醒来检查。 谁决定：外部发生的事 L3 自己定下次时间 软件做完一轮后判断「半小时后再看一次」。 谁决定：软件自己 L4 记着一个长期目标 目标有明确的完成标准，动作要经独立批准才会发生。 谁决定：目标进度 + 授权规则 ▲ 从第三级开始，软件自己决定什么时候再回来 ▲ 这套五级刻度由本报告整理，方便读者横向比较；厂商文档里没有对应的分级。 闹钟：谁把它叫醒 系统得先有办法被叫醒。时间点、新邮件或者网页变化，都可以充当闹钟。 值班室：活儿在哪儿继续 被叫醒之后，得有个地方让它继续干活。这个后台房间必须一直开着，关掉手机或电脑上的界面不能影响它。 门卫：谁来放行 最后还要有人决定：这次是只发一条消息，还是真的替用户把邮件发出去。两者的代价完全不同。 下一章 五级刻度里，第三级往上开始涉及「自己决定」和「真的动手」。第 4、5 两章分别讲这两件事：什么时候该开口，以及动作由谁批准。 04 / 主动与执行 4 主动开口与主动动手 承接上一章 上一章的刻度里，主动包含两层意思：发一条消息，或者真的替人做一件事。两条路共用同一套叫醒机制，做错之后的代价相差很远。本章先把它们分开，再说明为什么让系统保持安静比让它勤快更难。 有人叫醒它 到点了、来信了、网页变了 ↓ 后台房间还开着 关掉界面也能继续，重启后进度不丢 ↓ 先判断有没有新情况 和上一次比，究竟变了什么 第一条路：发一条消息 这条路消耗的是人的注意力。消息发错了，用户读到的是一条莫名其妙的提醒；如果这种情况出现几次，用户会直接关掉通知，之后真正重要的消息也送不进去。 所以它只在三种情况下放行：事情真的变了、有一件事必须等人拍板、或者有一份人能用上的结果。 第二条路：真的去做一件事 这条路消耗的是权限、账号和钱。邮件一旦发出去就收不回来，日程一旦改掉就可能让别人白跑一趟，因此默认姿态应当是「先不做」。 只有在独立规则明确放行、并且权限与这次动作一一对应时，系统才可以动手。 一条通知要过四道筛选 1 确实被叫醒了 先确认触发来自时间点或真实事件。没有推送来源时才允许定时去查，而且要限制查询频率。 2 确实有新情况 系统把这一次看到的内容和上次做个确定的比较，没有变化就直接停下来，连模型都不必叫醒。 3 确实值得打扰 只有「需要人行动」「结果能用」「需要批准」三种情况可以放行。「我有个建议」应当默认关闭。 4 还在预算之内 系统会记住上次报过什么，也限制同一件事反复提醒、限制夜间打扰和单项目触发次数。 系统要明确写下「没有新情况」这个结论 有一条规则不能妥协： 负责观察的环节如果超时了、出错了、或者连不上数据源，系统要把「我查不动了」单独报成故障，另记一条。安静的监视器看起来很健康，实际上已经坏了。 厂商已经改过做法 OpenAI 在 2025 年 9 月推出过一档清晨简报：系统每晚翻看聊天记录、记忆和已连接的应用，第二天早上推送几张卡片。据第三方资料，这项功能后来被收回到「由用户自己设定要检查什么、什么时候检查」的形式。DeepSeek 在一个开源原型里把同样的想法写得更直白：软件只在有人提出要求、或者团队写好的规则允许时行动；开口说话，只在有人必须做点什么、或者能用上结果的时候。 把三件事放在一起看 ：Meta 规定只在情况变化或需要批准时回来，OpenAI 把主动权交回给用户，DeepSeek 把「少占用人的注意力」写进设计原则。三家都在保护同一份东西：用户愿意点开通知的那份信任。消息发得越勤，这份信任消耗得越快。 下一章 知道了什么时候该开口，下一章回答更硬的一个问题：软件打算真的动手时，谁说了算。 05 / 权限与批准 5 谁来批准一个动作 承接上一章 上一章把通知和执行分开，本章沿着第二条路继续。这里要看的是，一个动作有没有被模型之外的规则批准过。 把「不许随便发邮件」写进提示词，模型可能理解错，也可能被网页里的一段恶意文字带偏；把同一条规则放进独立进程，模型无论怎么推理都绕不过去。本报告把这种做法叫作「把规则放到模型之外」，第 6 章讲到的 Muse 门卫用的正是这个思路。 ① 先默认不做 发消息、写文件、访问外部服务，一律先设为禁止，再按具体任务逐项放开。 ② 账号密码不进模型 模型只拿着一串引用编号，真正的凭证由边界替它填进去，日志里也只留编号。 ③ 批准只针对这一件事 用户同意的范围精确到「给某人发这封邮件」，一次之后就作废。 ④ 请示走另一条通道 确认框不出现在聊天窗口里，用户点下的「同意」也不经过模型转达。 ⑤ 出错要看得见 系统把做过的事和打算做的事都记进不可篡改的流水账，用户随时能查。 自动运行与逐次确认打架 下面三个产品彼此独立，却都撞上了同一个问题：软件要在没人看着的时候干活，逐次弹窗就没人点；为了让它跑下去，设计者又常常把审批整个关掉。 产品 它遇到的情况 结果 WorkBuddy 官方文档写明，人不在电脑前时，需要确认的任务会一直停在等待状态；因此官方把「无需逐次确认」列为无人值守的推荐设置。 要自动跑，就得放弃逐次确认。 OpenClaw 负责盯外部变化的脚本常驻后台，默认带着主程序的完整工具权限。 盯梢的环节绕过了审批层。 DeepSeek Harness 第三方文档提到，社区为它写的定时插件要求最高权限且关闭审批，命令直接在宿主机上执行；另有插件专门解决「后台任务发起的请示永远没人回」。 接上定时，就等于关掉审批，或者让任务无限挂起。 比较合理的第三条路 是给审批设一个有限的等待窗口：时间一到还没人回应，就按「不同意」处理，动作不发生。任务到点就有了明确结果，权限也全程收紧。 分析 更安全，会少做完几件事 84% 未加安全限制时，测试任务完成比例 77% 加上结构性安全限制后的完成比例 数据来自 CaMeL 论文在一组公开测试集上的报告。它的做法是把用户交代的事先写成固定流程，让外部内容只能填数据、不能改流程。 这组数字说明什么 把判定权移出模型，软件会少完成一些任务，这是换取安全性付出的代价。本报告的建议是按事情的后果分级：读一份公开网页可以宽松，发一封邮件就必须严格，不必对所有任务一刀切。 该论文的代码由作者标为研究工件，作者也说明不打算长期维护，因此它的价值主要在思路；产品里需要另找有维护承诺的实现。 关于预览版软件的提醒。 DeepSeek Harness 官方在安全说明里写得很坦率：这套软件尚处开发者预览阶段，没有经过安全审计，不能视为生产就绪；它提供的隔离与审批也不保证挡住所有损害，保护不了项目本身被允许访问的资源。任何准备长期运行的部署，都应当先放进一次性的隔离容器，并从只读权限起步。 下一章 到这里，判断一把尺子已经有了：常驻、目标、节奏、授权。第 6 章把镜头转向市场，先看一款把完整形态做成公开产品的代表，再看商用工作台。 06 / 现有产品 6 现有产品做到哪一步 承接上一章 前面几章讲的是「完整形态应该有什么」。这一章开始看现实：Meta 的 Muse 是目前公开程度最高的样本，本章先讲它做了什么、怎样安排权限，也讲它出过的问题；随后用同一把尺子量商用工作台。 Meta Muse 做了什么 2026-09-08 Muse 发布 Meta 把它描述成「把事情做完」的软件：用户说清目标，它自己拆步骤、跨应用执行，用户关掉应用之后仍继续工作，遇到敏感动作会回来请示。 2026-09-21 桌面客户端被找出漏洞 一位安全研究者公开演示：电脑上的普通程序可以偷偷改动客户端的一项设置，把语音数据和登录凭证导向别处。问题出在高权限的桌面软件，云端隔离并没有被攻破，Meta 随后发布了修补。 2026-10 模型与开源模型陆续到位 Meta 推出了强调长任务不放弃、跨会话带记忆的新模型，也以开源许可发布了一款面向本地运行的模型，官方建议配备 24–32 GB 显存的设备。 2026-10-27 在新加坡上线 公开资料里没有给出中国大陆的可用性与合规状态，本报告对此不作推断。 Muse 的两层结构 Muse 的结构是一间干活的房间，加上一位站在门外的门卫。房间的门从里面打不开，钥匙也不在房间里。 干活的房间 隔离区 · 权限受限 模型、工具与浏览器都在这里 系统给每个人准备一台独立的云电脑。即便里面的程序自称拥有最高权限，落到宿主机器上仍然只是一个普通账户。 模型只拿得到假钥匙 账号密码从不进入模型的上下文，所以「用一段话骗模型说出密码」这条路在结构上走不通。 门外的门卫 独立区 · 负责放行 所有对外动作都由它批准 发邮件、访问外部服务、连上网络，都要先过这一关。真正的账号密码也只在门外被换成有效凭证。 请示不经过聊天窗口 需要用户点头时，确认框直接出现在应用界面上，回答也直接送回门卫。模型既看不到确认框，也无法替用户点「同意」。 干活的只负责想办法，能不能做由门外决定 Meta 自己承认的三件事 公司在安全文章里直说：提示注入仍是整个行业没解决的问题，Muse 也挡不住所有攻击。 公司为有效的漏洞报告开出最高 30 万美元赏金，其中「成功骗过系统影响单个用户」最高 13 万美元。 目前限制内部员工接触用户数据靠的是管理制度；「连厂商也看不到」的机密虚拟机仍写在后续计划里。 两起公开报道的事故 一位用户两天没打开应用，却收到助手主动发来的消息，声称「邮箱没连上、找不到那封邮件」。Meta 向媒体确认这是产品缺陷造成的凭空生成，与隐私无关；修补之后那位用户仍然弃用了产品。 主动消息报错一次，信任就可能归零。 另有第三方报道提到，系统曾被发现在后台定期为「用户生活中的每个人」建立档案，被建档的人没有使用这个产品，也没有拒绝的机会。用户看不见的后台工作，感受上更接近监视。 需要提醒读者： Meta 官方发布页对后台定时器、目标页面、并发任务数这类细节没有说明，也没有公布「多久才允许主动发一条消息」的门槛。这些内容来自第三方报道，本报告不把它们当成官方承诺。 商用工作台能做到什么 能力 WorkBuddy 的表现 判定 把一份工作做完 用户说清需求后，软件会自己拆步骤、调用工具，交付文档、表格或演示文稿。 具备 连接邮箱、文档和消息 官方提供多种连接器和自定义扩展，也能推送消息、代发邮件。 具备 关掉界面后继续工作 云端任务不要求电脑开机，但它是一次一次被叫醒执行，有单次时长上限；本地任务则要求客户端保持打开。 部分具备 情况一变就主动回来 软件能在任务完成时通知用户，触发它的是本轮任务结束这个时间点。 部分具备 长期目标与自定复查时间 官方文档没有提供目标状态机，也没有通知预算一类的机制。 尚不具备 顺带一提，官方对「无人值守」的建议是把逐次确认关掉，这正好印证了第 5 章说的那个矛盾。它的运行记录、失败原因诊断和试运行功能反而做得相当细致，这些都是日常运维里真正省事的部分。 下一章 一款商业产品和一类商用工作台看完了，第 7 章把开源项目也放进同一张表，做一次完整横评。 07 / 产品横评 7 横向比较市场上的相关产品 承接上一章 上一章看到商用产品的能力分布。这一章列出开源项目各自补齐了哪一块，以及把它们拼成完整形态时需要的四层配合。读者可以据此判断，自己到底需不需要动手搭一套。 开源项目各自补齐了哪一块 项目 它最擅长的一块 需要注意的地方 OpenClaw 把系统叫醒、以及让系统在没变化时闭嘴。事件触发、自定复查节奏、静默规则在这一层最完整。 长期目标能力较弱，也没有独立的凭据门卫。 Hermes Agent 把一件跨天的事记成目标，并写明「什么才算做完」，完成后还要有证据。 默认直接在宿主机上执行，需要自行加隔离。 DeepSeek Harness 把审批、凭据和隔离做成可以替换的零件，也把模型看过的一切记进不可篡改的流水账。 仍处开发者预览，没有现成的消息通道和主动推送。 OpenMuse 外形最像参照产品：目标、任务进度、建议列表、逐动作审批都有。 仍是早期版本，依赖一项不在开源许可内的外部服务，不宜接真实账号。 nearai/ironclaw 账号密码只在边界注入，工具和模型都读不到明文。 没有目标状态机，放在授权层补位更合适。 QwenPaw 本地小模型与国内常用消息渠道，成本更低、接入更顺。 没有明确的完成判据，官方也未公布各档显存需求。 完整形态需要四层配合 长期目标 跨天推进，有完成标准 这一层负责记住「要做成什么」和「什么算做完了」，由 Hermes 这类项目承担。 叫醒与安静 事件触发，自定节奏 这一层负责决定何时醒来、以及该不该开口，由 OpenClaw 这类项目承担。 常驻后台 关掉界面也不停 这一层负责让上面两件事一直活着，重启之后进度不丢。 独立授权 模型看不到真凭据 这一层负责批准真实动作，由 DeepSeek Harness 的插件位或类似的边界组件承担。 组合方式一：先跑通 用现成成熟度较高的组件拼出效果，适合先验证「这类系统到底有没有用」。代价是几套进程并存，升级节奏各不一样。 组合方式二：先把授权层摆正 以插件化运行时作为执行与授权底座，架构更干净、授权边界更容易审计，但上手更慢，且要接受预览版的不稳定。两条路线可以先后衔接：先跑起来，再把执行层逐步换过去。 硬件也是一条现实边界。 8 GB 显存是消费级笔记本的常见档位，而官方给本地模型的建议是 24–32 GB。在这个档位上，把编排、隔离和权限判定放在本地、把模型推理交给云端或另一台大显存机器，是更务实的分工。至于更小的本地模型能否在长上下文下跑得动，本报告没有实测数据，不作断言。 下一章 产品能力量完了，第 8 章把这些结论收成三种常见场景，给出选择建议和推进顺序。 08 / 选择建议 8 用户该怎么选 承接上一章 前面几章都在描述产品和机制，这一章只回答一个问题：我该用哪一种。下面的分层属于本报告的分析判断，读者可以按自己的场景复核。 场景一 日常办公与定时简报 如果目标只是每天收一份简报、生成文档、往群里推送消息，商用工作台已经够用，另外搭一套常驻系统的投入很难收回。 场景二 要盯外部变化 如果希望新邮件一到就有反应、让软件自己安排复查时间，就需要引入常驻触发层，并把交付工作继续留给现成平台。 场景三 要碰真实账号与钱 如果软件要发真实邮件、改真实日程，架构上必须先有独立授权层。本章末尾的五条验收指标没有全部通过之前，本报告不建议进入这一阶段。 分四步逐步放权 1 接上叫醒机制 先把时间触发和事件触发跑通，这一步不接任何对外动作。 2 把安静做扎实 配置变化比对、去重和通知预算，并确认检查失败时会明确报错。 3 放开自定节奏 允许软件自己提议下次何时复查，但由调度器限定上下界。这一步才从第二级进入第三级。 4 最后才接执行 先给长期目标写明完成标准，再按「只读 → 起草 → 带外批准 → 放行」的顺序逐步交出权限。 五条可以逐项验收的硬指标： 关掉界面之后任务继续跑，重启不丢进度；连续一天没有新情况时，一条消息都不发；故意让检查环节超时，系统必须报错；未经同意的动作确实没有发生；取消掉的任务重启之后不会自己复活。 下一章 选择说清楚了，最后一章回到产品本身：现有 PA 还有哪些毛病，以及接下来可能往哪些方向完善。 09 / 问题与展望 9 现有产品的问题与改进方向 承接上一章 前面看到的产品都还年轻。这一章把已经暴露出来的问题集中列出来，再给出本报告认为值得优先补上的几件事。后半部分属于分析判断，公开资料里没有对应的厂商承诺。 已经暴露出来的问题 风险 它从哪来 通常怎么缓解 恶意文字骗过模型 Meta 在官方安全文章里承认这仍是行业开放问题，并为成功攻击开出赏金。 把规则放到模型之外，并做固定的攻击回归测试；不宣称已经解决。 盯梢的脚本权限过大 负责观察外部变化的环节常驻后台，默认带着完整工具权限。 让观察环节和主程序接受同等隔离，并保留一键关闭的开关。 接上定时就绕开审批 第三方文档显示，某些定时插件要求最高权限并关闭审批。 把定时任务放进一次性容器，给审批设有限等待窗口。 主动消息报了假情况 已有用户因为一条凭空生成的提醒而弃用产品。 层层筛选、记住已报内容，并默认关闭「未经请求的建议」。 后台工作用户看不见 第三方报道提到过未被察觉的后台建档行为。 把做过的和打算做的事都列给用户看，并留完整的流水账。 接下来可能怎么完善 下面六条是本报告基于前文整理的改进方向，属于分析判断。公开资料里没有厂商承诺会按这个顺序推进，读者可以把它当成一份检查清单。 ① 把「少打扰」做成默认设置 目前不少产品靠一句提示词提醒软件「没变化别发消息」。更稳妥的做法是把它写成系统规则：同一件事多久最多提醒一次、夜里不打扰、没有新情况就明确记下「无需通知」。 ② 给请示设一个等待上限 人不在电脑前，任务会一直停在等待确认；为了让它跑下去，设计者又常常把审批整个关掉。给每次请示一个有限窗口，超时按不同意处理，两头都能收住。 ③ 长期目标要有完成标准 跨天推进的事情应当事先写清「什么算做完」，完成时还要拿得出证据。已有开源项目把这条做成了核心机制，值得成为这类产品的通用配置。 ④ 后台做过的事都要看得见 用户应当能列出软件做过和打算做的每一件事，并能一键叫停。第三方报道里那种用户毫无察觉的后台建档，本该在界面上就留下记录。 ⑤ 盯梢的环节单独隔离 负责观察外部变化的脚本长期运行，默认还带着主程序的完整权限。它应当和主程序接受同等隔离，并保留一个能一键关闭的开关。 ⑥ 组件之间约定统一接口 完整形态现在要靠四层拼装，彼此之间没有官方集成协议。触发、目标、授权、执行之间若有统一约定，搭一套可用系统的成本会明显下降。 把六条串起来看： PA 接下来要补的东西，大多落在工程规则和产品设定上：让软件学会闭嘴、让权限有边界、让后台看得见、让组件能拼起来。本报告判断，这几件事会决定这类产品能不能从演示走向日常使用。 写在最后 正文到此结束。附录 A 交代资料来源与证据分界，附录 B 解释文中反复出现的几个词。 附录 A / 资料与证据 ＋ 资料来源与事实分界 附录说明 公开报告应当允许读者逐条追溯。这里说明调研用了哪些材料、怎样区分事实与推断、主要出处在哪里，以及有哪些问题本次调研没有查到答案。 编制说明： 本报告由 WorkBuddy 创建，使用腾讯混元 Hy4 模型完成资料核查、文稿撰写与图解版编排。文中把厂商原文、第三方转述与分析判断分开标注，读者可以按这些标注逐条复核。 哪些材料算数 调研集中在 2026 年 9 月到 11 月之间，材料包括厂商的官方发布页与产品文档、开源项目的仓库说明、正式学术论文，以及有署名的新闻报道。本报告把材料分成三类，读者可以据此判断每一句话的分量。 可以直接核对 厂商原文与公开规格 例如 Meta 发布页对产品行为的描述、官方文档写明的触发规则、模型官方给出的显存要求。这类内容可以直接查证。 第三方转述 索引站、社区文档与媒体 这类材料能提供线索，但本报告没有拿到对应的一手页面。凡是引用它们，正文都会明确标出，读者不宜当成厂商承诺。 分析与推断 本报告自己的判断 分级框架、机制归纳、方案比较都属于这一类。它们由本报告整理，用来帮助读者理解材料；厂商文档里查不到这套分级。 被排除的材料同样值得说明。 有些第三方页面对同一个开源项目的许可证、编程语言和测试结果给出了互相矛盾的说法，本报告不采用；也有博客描述了某款商用工作台的「事件触发接口」，但官方文档明确写着只支持时间规则触发，本报告以官方说法为准。热度数字、榜单排名和未经复算的跑分，一律不写进结论。 事实、推断与转述的分界 类别 包含哪些内容 可核对 Meta 发布页与安全架构文章原文、后续模型与开源模型的官方规格、WorkBuddy 与腾讯云的官方文档、各开源项目的官方仓库说明、DeepSeek Harness 的安全说明全文、CaMeL 论文结论、OpenAI 的上线公告、有署名媒体对三次事故的报道，以及公开的硬件规格。 分析与推断 个人代理的三条判据、五级主动性刻度、四层拼装、通知与执行两条链路、四道筛选关、「安静比勤快更难」的判断、对安全代价的解读，以及全部选型建议与推进顺序。 第三方转述 Muse 后台排程与目标页面的描述、某产品功能下线的时间与原因、部分开源项目的社区插件行为与性能数字、热度统计与版本号。这些内容在正文中都标注了来源层级，不宜当作厂商声明。 还有一处资料取得的限制： 少数官方页面在调研时只返回了标题，或者未能取得完整正文，其中的规格取自搜索引擎收录的片段或第三方转述。正文已逐条标注，读者引用前宜以官方页面复核。 主要出处 厂商一手材料 Meta Newsroom 的 Muse 发布页与后续模型公告、Muse Security 的安全架构文章、Meta 开发者文档；WorkBuddy 官方产品文档与腾讯云产品文档；OpenAI 的 Pulse 上线公告。 开源项目官方材料 OpenClaw、Hermes Agent、OpenMuse、DeepSeek Harness、nearai/ironclaw、QwenPaw 等项目的官方仓库说明与文档；DeepSeek Harness 的 SAFETY.md 与架构文档。 学术论文与研究工件 CaMeL 团队发表于 2026 年 SaTML 会议的提示注入防御论文及其公开代码仓库；Muse Glimmer 30B 的模型卡。 新闻与第三方核对 The Register 对客户端漏洞的报道、Futurism 对幻觉通知的报道，以及若干索引站与中文媒体对产品细节的转述。这部分内容在正文中均按二手处理。 完整的 MLA 9 引用条目（含标题、发布日期与链接）收录于配套的《Personal Agent 调研报告》文字详版第 10 节，共 40 条。 时效提醒： 本报告描述的是 2026-11-05 之前可公开查证的产品状态。这个方向迭代很快，已有开源项目在新版本里移除过一批机制，也有项目明确预告会有破坏性兼容变更。读者在引用具体能力判断时，宜先对照各项目当前官方文档；相比之下，本文的分级框架、机制拆解与风险清单更耐久。 能力上限与资料空白 目前还做不到的 「连服务厂商自己都看不到用户数据」的机密计算，Meta 也还写在后续计划里。 与支付绑定、限定金额与时限的一次性付款凭证，属于专有商业能力，开源组合里没有等价物。 大厂规模的内部试用、攻击演练和公开赏金验证，个人或小团队很难复现。 本报告没有查到的 厂商没有公布主动消息的误报率、真实任务成功率与留存数据，也没有公布「多久允许发一条」的具体门槛。 小模型在 8 GB 显存、长上下文条件下的真实速度，本报告没有实测。 各组件拼起来之后的端到端延迟与成本、某些插件是否为官方组件、以及不同地区版本的功能差异，公开资料都未给出答案。 下一节 最后附上词语表，把正文里反复出现、又容易混淆的几个说法用日常语言解释一遍。 附录 B / 词语表 ＋ 词语表 附录说明 正文尽量少用行话，但有几个词反复出现，这里用日常语言统一解释，免得读者来回翻查。 词 意思 常驻后台 一个不随界面关闭而停止的后台进程。系统能不能「一直干活」，全靠这个进程；模型只在被叫醒之后参与。 带外批准 需要用户点头时，确认出现在另一个界面上，回答也不经过聊天窗口转达。模型既看不到确认框，也不能替用户点同意。 假钥匙 模型手里那串没有实际权限的引用编号。真正的账号密码由边界在最后一刻替换进去。 静默出口 系统明确写下「这次没有新情况，不必打扰」这个结论，随后安静下来。 完成标准 事先写清楚的「什么才算做完了」，判定时要拿得出证据，不能由软件自己宣布完成。 提示注入 网页或邮件里藏一段话，专门用来骗软件做它本来不该做的事。Meta 在官方安全文章里承认，这仍是整个行业没解决的问题。 超时拒绝 需要批准但没人回应时，等待时间一到就按不同意处理，动作不会发生。 《Personal Agent 调研报告》图解版 ｜ 依据 2026 年 9 月至 11 月的公开资料整理 ｜ 调研日期 2026-11-05 ｜ 与文字详版结论一致，技术细节与完整引用以文字详版为准 ｜ 由 WorkBuddy 创建，使用腾讯混元 Hy4 模型。 --- ## 引用说明 / Citation 引用本站内容时请注明来源「火木工作室 / Fire Wood Studio」并链接到对应页面。When citing, attribute to "Fire Wood Studio" and link to the source page.