智谱 AutoClaw（澳龙）：闭源本地桌面 Agent 客户端，仅在博客/changelog 层面披露产品行为

智谱 AutoClaw（澳龙）

一句话定位

AutoClaw（中文名”澳龙”）是智谱 AI 推出的闭源商业本地桌面 Agent 客户端（“AI 数字员工”），官方自述”基于 OpenClaw 开源框架打造”；本仓库没有任何源码可读，全部结论来自 7 篇官方一手博客 + changelog 页面，只能在”产品行为/营销话术”层面刻画其 agent loop、记忆、编排、自进化等能力，无法做到源码级验证——这是本 dossier 与其余 harness 页面在证据强度上的本质差异，需要读者带着这个前提使用全文。

核心架构总览（目录结构关键路径 + 引用的 commit）

• 无公开仓库：https://autoclaw.zhipuai.cn/ 是 Next.js/SPA 营销站点（落地页 + 博客 + changelog），没有 .git 端点，不是代码托管地址。任务原始指令要求 git clone 该 URL 不可执行，已确认没有可 clone 的对象，未做任何 clone 尝试。
• GitHub 上唯一同名命中 github.com/tsingliuwin/autoclaw 经核实是无关项目（一个跑在 Docker 容器里的轻量级 headless agent，与智谱产品无关），已排除。
• 上游基座：AutoClaw 官方博客自称”智谱基于 OpenClaw 开源框架打造的 AI 数字员工”（blog-what-is-autoclaw.md）。OpenClaw 是一个独立的、体量更大（第三方称 100k+ star）的开源个人 agent 框架，有自己的 Gateway/agentic-loop/Skills/MCP/memory/Heartbeat 架构。本 dossier 明确不深挖 OpenClaw（超出 AutoClaw 本身范围，建议作为单独的 harness 条目），也没有找到 AutoClaw 对应的 OpenClaw 版本号/commit 锁定。
• 版本标识：因闭源，不存在 commit SHA 或 npm 包版本；唯一可查的是公开 changelog 里的产品发行号。已读 changelog 覆盖 v1.5.1 → v1.10.0：
  • v1.10.0（2026-06-30，“最新”）：灵感与活动功能上线；修复图片识别等已知问题
  • v1.9.0（2026-06-17）：新增积分奖励任务；全新工作区能力；新增危险脚本智能拦截；自动预下载安装包；Windows 安装提速；优化断联
  • v1.8.0（2026-06-13）；v1.7.0（2026-06-09）；v1.5.1（2026-06-03，“云龙虾”上线）
  • 注：GLM-5.2 接入的博客（blog-v1.9.0-glm5.2.md）标题标注为 V1.9.0，与 changelog 记录的 v1.9.0 发行日期 2026-06-17 一致对应同一版本号，但 stage-1 笔记表格误记该博客发布日为”2026-06-24”——这是 stage-1 记录的小出入，未进一步核实博客页面本身的实际发布时间戳，此处以 changelog 的 2026-06-17 为版本发行的权威日期。
• 客户端形态：Windows 10+ / macOS（含 Apple Silicon）原生本地桌面客户端，直接持有本机文件/浏览器/代码执行权限（非沙箱化，见”沙箱”节）。
• 一手来源全部落盘于 /Users/zhao/projects/self-wiki/ai-research/sources/harness/zhipu-autoclaw/，文件清单见文末。

Agent Loop（主循环 / 何时继续何时停）

源码级未披露。 没有任何官方文档描述循环内部结构、迭代上限或停止条件。

唯一在产品行为层面暴露循环宏观结构的是 Cluster Mode（集群模式）：强制走一套 6 阶段 SOP——理解任务 → 查资料（强制联网核实关键事实）→ 规划 → 并行派活 → 审计复核 → 规范化交付（blog-cluster-mode.md 行 40-52）；对比”普通模式”是”凭判断直接干”，没有强制分阶段。执行时会在聊天 UI 展示”进度面板”，暴露当前/已完成/剩余步骤（blog-cluster-mode.md 行 58），说明底层确有一个显式的多步状态机，但其判断”何时继续/何时停”的具体逻辑（如工具调用次数上限、失败重试策略）没有任何披露。

记忆与上下文管理（压缩、长期记忆、会话持久化）

• 多层文件式记忆，四个命名文件、按内容类型分工（blog-hermes-self-evolution.md 行 84-89）：
  • SKILL.md —— 新工作流/操作流程
  • AGENTS.md —— 行为规则/偏好
  • MEMORY.md —— 事实性/长期记忆
  • TOOLS.md —— 工具相关配置（如常用摄像头名称、SSH 地址）
• 多 Agent（“分身”）隔离：每个 Agent 拥有独立的 Workspace（文件/项目/代码库）、Memory（长期记忆+日常日志）、Session（对话历史）（blog-multiagent.md 行 41-46）；同一 Agent 绑定多个 IM 渠道（如飞书 bot + 企微 bot）实时共享同一份记忆，无”同步延迟”；不同 Agent 即使挂在同类渠道上也完全隔离（blog-multiagent.md 行 51-63）。
• 长上下文替代压缩工程：v1.9.0（changelog 记 2026-06-17）接入 GLM-5.2，宣称 1M token 上下文，营销话术明确说这是为了避免”需求背景被压缩后细节容易丢失”和多轮分块生成导致的跨轮漂移（blog-v1.9.0-glm5.2.md 行 37-57）。这是”用更大原生上下文窗口替代工程化压缩”的路线，而非披露了某种摘要/压缩算法。
• 没有披露：任何压缩/摘要算法、token 预算管理机制、RAG/向量记忆层。

结论：记忆 = 结构化平铺文件（SKILL/AGENTS/MEMORY/TOOLS.md）+ 长原生上下文窗口；无披露的上下文压缩机制。

工具体系（定义/调用协议/注册/权限）

无 API/schema 级披露（无源码，未找到工具 schema 文档）。功能层面可推断的工具面：浏览器自动化、本地文件读写、代码执行、飞书开放平台 API 直连（官方明确强调”不是 RPA、不是浏览器插件”——blog-feishu-integration.md 行 36）、日历/多维表格/文档/任务操作（经飞书 API）。

最具体的”工具注册”披露来自飞书集成的配置流程（blog-feishu-integration.md 行 101-112）：一键创建飞书应用 → 一键批量添加权限 scope → 必须在飞书开放平台手动创建版本并发布（官方点名这是最常被漏掉的一步）→ 扫码授权 → /feishu auth 命令做全部 scope 的一次性批量授权。这本质是叠加在飞书自身开放平台权限模型之上的 OAuth 式 scope 授予流程，不是 AutoClaw 自研的权限 schema。

v1.9.0 changelog 提到”安全防护升级：新增危险脚本智能拦截”（changelog.md 行 46）——暗示工具调用/脚本内容在执行前会被某种机制检查/过滤，但检测原理（静态分析？沙箱试跑？关键词匹配？）完全未披露。

Prompt 设计（系统提示结构、动态组装）

未披露任何系统提示文本、模板或组装逻辑。 间接证据：每个 Agent 有一个 SOUL.md 文件定义”人设与性格”（如”工作助手严谨专业，生活助手轻松活泼”——blog-multiagent.md 行 43），这暗示 SOUL.md 内容大概率被注入系统提示，但注入机制/顺序未文档化。Auto Design 子 agent 流程提到会推送”结构化需求澄清卡片”（blog-auto-design.md 行 43-47），暗示该子 agent 存在模板化/动态提示，但未展示模板本身。

Router / 编排（任务分解、多 agent、子 agent）

这是披露最充分的维度之一，有两套不同的编排面：

1. 多 Agent（“分身”）——用户侧账号级隔离，不是运行时任务分解技术：用户手动创建多个顶层 Agent（各有独立人设/工作区/记忆/会话），手动绑定到 IM 渠道，不是自动任务分解（见”记忆”节）。
2. Cluster Mode（集群模式）——单任务内的运行时多角色任务分解，是真正的子 agent/编排引擎：
   • 强制 SOP：理解 → 资料核实（强制联网验证关键事实）→ 规划 → 并行派活（“能拆维度时默认拉人并行”）→ 交付前审计复核 → 格式受限的交付物（网页/DOCX/PPT 级别，不只是 markdown）。
   • 官方明确说普通模式”已经是个能搜资料、能用工具、能派子 Agent 的助手”——暗示子 agent 派发能力在普通模式下也存在，Cluster Mode 只是加了强制分阶段（blog-cluster-mode.md 行 42）。
   • 真实案例中观察到的角色规模（blog-cluster-mode.md 行 86-129）：
     • Case 1（大范围调研）：18 个角色——1 个总览扫描 → 7 个并行方向研究员（产品/学术/框架生态/中国生态/投资/KOL/反方观点）→ 7 个方向深挖 → 1 个写作 → 1 个独立审核 → 1 个排版/HTML 布局。审核角色捕获”71 个幽灵引用 + 5 处编号重复 + 3 处跨维度引用错配”；耗时 43 分钟，约 2 万字，爬取 140+ 页面，留存 21 份中间笔记。
     • Case 2（单公司估值）：2 个角色——主 agent（数据采集+对比+估值）+ 独立审核（捕获小数点级数值偏差与逻辑漏洞，打回修订）；8 分钟。
     • Case 3（财报）：2 个角色——主 agent（数据+撰写17页DOCX+自我交叉检查）+ 独立图表生成 worker（并行产出10张PNG）；自我审核捕获文件名不匹配（chart_10_revenue_vs_usdc.png 引用 vs 实际 chart_10_rev_vs_usdc.png）并自动修复；13 分钟。
     • Case 4（量化回测）：3 个角色——主 agent（akshare 拉数据）、量化 coder（写/跑 MACD 回测脚本）、独立审核（独立用 Python 重新推导 MACD 公式，交叉核对指标到小数点后4位，抽样6笔交易，对1笔 EMA 初始化噪声交易标 WARN）；约 10 分钟。
   • 团队规模按任务可分解程度动态调整（“按任务复杂度自动选阵型”），非固定编制。
   • 未披露：底层调度/派发代码、agent 间消息传递协议、“角色”如何映射到具体模型调用/实例（是否每个角色=独立一次模型上下文，还是共享上下文分饰多角色）。

Skill / 插件体系

• 50+ 预置技能，覆盖办公自动化、自媒体/内容、财务、Web 应用脚手架、浏览器自动化、IM 集成（落地页 + blog-what-is-autoclaw.md）。
• 技能格式：SKILL.md——单个技能 = “完整的多步骤操作流程”，来源有二：(a) 产品内置预设技能；(b) 自进化（“Skill 进化”）——从一次已完成的复杂任务（10+ 次工具调用）自动蒸馏成一个可复用的命名技能文件，用户说”按老流程”可触发召回（blog-hermes-self-evolution.md 行 127-150）。
• “技能市场”在某第三方摘要中提到”即将上线”，未在一手页面独立核实，标记为未确认。
• 未披露：插件 API/manifest schema、运行时加载器机制。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

这是披露最详尽的维度，品牌名”Hermes 自进化”（blog-hermes-self-evolution.md）：

• 三步人在环流程：用户陈述 → AutoClaw 提出”进化卡片”（准确展示它打算记住什么）→ 用户必须显式批准。明确设计原则：“AutoClaw 永远不会偷偷修改自己”——每次进化都需要显式批准（行 43-51）。
• 两条触发路径：
  1. 关键词触发（用户主动表达意图信号）：明确列举触发词——以后/记住/永远/从不/每次都/始终/下次/一律。给出明确对比：“回复简洁点”（一次性请求，不触发）vs “以后回复简洁点”（触发）——一个关键词就是区分点（行 55-70）。
  2. 自动检测：复杂任务涉及”大量工具调用或多次失败重试”时，系统自动标记为”有价值的踩坑经验”，无需关键词即运行进化检查（行 72-76）。举例：某 API 调用因参数格式错误失败，下次类似任务自动纠正。
• 按内容类型分发到目的文件：与”记忆”节相同的四个文件——SKILL.md（流程）、AGENTS.md（行为/偏好规则）、MEMORY.md（事实/长期记忆）、TOOLS.md（工具配置）。
• “Skill 进化” 作为进阶/独立子情形被点名：普通进化记录一条规则，Skill 进化记录”一整套操作流程”到独立 SKILL.md 文件，在复杂任务（10+ 次工具调用）后自动检测，不靠关键词触发。
• 明确披露的运营护栏：质量优先目标”每周 1-3 次高质量经验记录”；后续纠正覆盖先前记录（如先”详细点”后”简洁点”→后者生效）；被拒绝的提案有 2 周冷却期才会重新提出；用户可查询”你最近学会了什么？“来列出近期进化；明确声明进化是”经验积累”而非”能力提升”——即不声称模型权重/能力有任何变化，纯粹是持久化上下文/文件级学习。
• 默认启用，无需配置。
• 没有 eval-harness / benchmark 驱动的纠错循环披露——这纯粹是交互触发的文件式记忆蒸馏，不是自动化的 eval 驱动自我改进管线。
• 未披露：实现细节（“10+ 次工具调用”如何被检测、提案文本如何生成、MEMORY.md 的 diff/merge 逻辑）。

可观测性（日志 / trace 格式）

没有日志格式、trace schema 或遥测披露。 产品层面可见的可观测性面：Cluster Mode 的实时”进度面板”（展示当前/已完成/剩余步骤，blog-cluster-mode.md 行 58）；Case 1 提到”过程留下 21 份中间笔记可以回看”（行 93），暗示多 agent 任务存在某种可持久化、事后可查阅的中间产物轨迹，但格式/存储位置/留存期均未文档化。自进化的”你最近学会了什么？“查询是针对进化日志本身的用户侧审计钩子，不是通用执行 trace。

安全与权限（审批门、密钥管理）

• 自进化审批门：显式人在环，每次记忆/行为/技能变更都需要用户点击批准提案卡片（详见”自进化”节）。
• 外部动作（飞书）审批门：官方明确建议”发送、修改、写入等操作，先预览再确认”；明确反模式警告”不要让 AI 处于完全脱离人工干预的’全自动驾驶’状态”；建议先用个人账号试用再接入工作环境；建议遵循企业数据安全/隐私政策（blog-feishu-integration.md 行 114-121）。
• 权限/scope 授予：飞书集成走 OAuth 式流程——一键创建应用、一键批量添加所需 API 权限 scope，但授权生效前需在飞书开放平台手动”创建版本+发布”（点名最常漏掉的一步），随后扫码用户授权，再 /feishu auth 做全部 scope 的一次性批量授权（详见”工具体系”节）。
• “危险脚本智能拦截”：v1.9.0 changelog 中的命名安全功能，零实现细节披露（changelog.md 行 46）。
• 数据本地化声明：反复强调 AutoClaw 本地运行，“数据不出本机”，只有”必要的任务描述和模型调用信息”会为推理而传输——这是隐私/安全承诺，不是技术机制描述（落地页 FAQ）。
• 未找到密钥管理披露（落地页明确说内置模型不需要用户提供 API key；智谱如何管理自己后端的密钥自然不会披露）。

沙箱与执行隔离

官方未披露任何沙箱架构、容器/VM 边界或进程隔离设计。 唯一间接证据是 v1.9.0 的”危险脚本智能拦截”，暗示在 agent 决定执行脚本与实际操作系统级执行之间存在某种预执行检查层，但这是沙箱、静态/模式过滤器还是人工审批门，未说明。

产品运行形态是原生本地桌面客户端（Windows 10+/macOS 含 Apple Silicon），在宿主机上直接拥有文件/浏览器/代码执行权限——即披露的模型是”以真实本机权限运行”，而非”运行在隔离沙箱中”，这与云沙箱化的 coding agent harness 有本质不同的安全姿态。changelog 另提到一个未展开的”云龙虾”（cloud lobster）功能（v1.5.1，“休眠云龙虾上线，免费创建不消耗积分”），可能是本地执行之外的云托管执行环境替代方案，但没有找到任何架构细节。

结论：设计上基本”未沙箱化”（本机执行本身就是产品卖点），有一个未探索的云端替代方案（“云龙虾”）留作 gap。

与模型的协同设计

AutoClaw 默认捆绑智谱自家 GLM 系列模型，支持热切换到 DeepSeek 及其他模型（落地页技术规格块：“AI 模型: GLM 系列 · DeepSeek 系列 · 多模型热切换”）。

v1.9.0（changelog 记 2026-06-17）明确将默认捆绑模型升级为 GLM-5.2，宣称 1M token 上下文窗口，营销定位为直接解决 agent harness 的痛点：避免需求预压缩、避免分块处理导致的跨文件关系丢失、避免多轮生成的风格/结构漂移（blog-v1.9.0-glm5.2.md 行 37-57）。这体现的协同设计是”模型能力替代工程化上下文管理”（即”harness 发行版与模型发行版锁步绑定，靠更大原生上下文减少对 retrieval/压缩技巧的依赖”），而非”harness 工程师围绕模型局限做检索/压缩补偿”。

没有披露任何 AutoClaw 专属的模型微调、工具调用格式联合训练，或基于 harness 轨迹对 GLM 做 RL 的证据——目前证据展现的协同设计停留在产品集成层（捆绑 + 版本锁定的功能解锁），未触及训练数据/训练循环层面。

轨迹利用（session/trajectory 是否反哺训练/评测）

未找到 / 官方未披露。 检查过的来源中没有任何一处说明用户会话轨迹、Cluster Mode 中间笔记，或自进化日志是否被收集、聚合，或用于微调/评测 GLM 模型。

自进化机制（见前节）是仅限个体用户/个体 Agent 层面的轨迹利用（任务历史 → 蒸馏进该 Agent 自己的 SKILL.md/MEMORY.md/AGENTS.md），是本地的、按 Agent 隔离的持久化，官方明确声明这不等于”改进底层模型”（博客原话：“进化不是万能的：本质是’经验积累’，不是’能力提升’”）。

隐私政策/用户协议全文（autoclaw_privacy / autoclaw_agreement，托管于 autoglm.aminer.cn）在 stage 1 中只被链接、未被抓取阅读——这些法律文本可能披露使用数据是否用于训练模型，是一个明确的待补 gap，本次 stage 2 同样未去抓取（任务范围限定为基于既有 stage-1 材料整理成稿，未追加新一轮抓取）。

结论：无产品级”轨迹→训练”管线披露；只确认了”个体 agent 本地轨迹→记忆蒸馏”（自进化），且被官方明确排除在”模型能力提升”之外。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

1. 证据形态根本不同：本页所有结论来自营销博客/changelog，而非源码/commit——这本身就是与 aider、opencode 等开源 harness dossier 最大的差异，读者不能把本页的”披露”当作源码级事实。
2. 安全姿态是”反沙箱”而非”沙箱化”：以本机真实权限运行是产品卖点，与多数云端 coding agent harness（默认容器/VM 隔离）方向相反。
3. 自进化机制的透明度和克制程度在同类”记忆型/自我改进”agent 产品的公开材料中少见：三步审批门 + 显式冷却期 + 明确声明”经验积累非能力提升”的自我边界划定，值得作为跨 harness self-evolution 维度对比的一个正面样本（即便其实现细节完全黑盒）。

原始源码定位

• repo：无公开源码；官方站点 https://autoclaw.zhipuai.cn/ 仅为营销/博客/changelog 站点，非代码仓库
• commit/version analyzed：无 commit SHA；产品发行号 v1.10.0（changelog 标注”最新”，发行日期 2026-06-30）；本 dossier 引用内容跨越 v1.5.1 至 v1.10.0 changelog 条目及 7 篇官方博客
• 关键文件列表（相对路径）：无（闭源，无可读源码文件）

一手源存档（sources/）

全部位于 /Users/zhao/projects/self-wiki/ai-research/sources/harness/zhipu-autoclaw/：

• NOTES.md —— stage-1 逐维度调研笔记（含逐条引用行号）
• blog-what-is-autoclaw.md —— 源 /blog/product/what-is-autoclaw"/（2026-05-26）
• blog-hermes-self-evolution.md —— 源 /blog/product/Hermes/（2026-05-28）
• blog-multiagent.md —— 源 /blog/product/Mutiagent/（2026-05-28）
• blog-cluster-mode.md —— 源 /blog/product/clustermode/（2026-05-28）
• blog-feishu-integration.md —— 源 /blog/product/feishu/（2026-05-28）
• blog-v1.9.0-glm5.2.md —— 源 /blog/product/AutoClaw V1.9.0/
• blog-auto-design.md —— 源 /blog/product/Auto design/（2026-07-07）
• changelog.md —— 源 /changelog/，覆盖至 v1.10.0（2026-06-30）

未落盘但用于身份核实的辅助来源（详见 NOTES.md “What was actually read”一节）：AutoClaw 落地页本身、github.com/tsingliuwin/autoclaw（已排除的无关项目）、第三方 OpenClaw 介绍文章（仅用于给上游框架定性，不作为 AutoClaw 本身的证据）。