春节假期，帮亲戚朋友们部署 OpenClaw 成了我一份额外的工作。虽然不一定能真正用上，但这只龙虾是不得不拥有。

AI 进入我们的工作流，在 OpenClaw 爆火之后，这种感觉变得更加强烈。在「不用 AI 会被淘汰，用了 AI 也像是能被替代」的悖论下，不错过任何一个能放大自身价值的 AI 工具，让人陷入了无止境的 FOMO。

越来越多的「龙虾变体」也涌现出来，但是当被问到打算怎么把这个部署好的 OpenClaw 融入工作流，答案往往又是个未知数。更不用说光是部署好 OpenClaw，就有两道大关，一是要手动部署和配置复杂的模型 API，二是让人心疼的额外 API 费用。

今天，更新后的 MiniMax Agent 推出了两项新功能。

专业度更高，更会干活的 Expert 智能体社区，涵盖从技术开发、创意写作到音视频图片生成等多模态领域，超过 1.6 万个专家，且还在持续增长。大多数场景下，我们几乎都能直接找到现成可用的专家；即便没有完全匹配的，用几句话还能快速创建一个自己的 Expert。

另一项新增的 MaxClaw 模式，能让我们一键打通 OpenClaw 生态，而且完全不需要自己配置 API，以及承担额外的 API 费用，解决了「不知道 OpenClaw 能做什么」和「怎么部署 OpenClaw」这两个问题。

这也就意味着，即便是纯小白，现在也能拥有开箱即用的专属 AI 专家团队了。

APPSO 也实测了一波智能体专家和 MaxClaw 这两项新功能，它确实和一般的智能体 Agent 不同，结合了 Skills 的能力和 OpenClaw 的兼容能力，我们直接就能操作飞书、钉钉等即时通讯软件。

而和市面上不同版本的 OpenClaw 对比，MiniMax Agent 的 MaxClaw 又有了预置的专家智能体，整个体验会更加友好。

体验地址：国内版 https://agent.minimaxi.com
海外版 https://agent.minimax.io

超过 1.6 万个 Experts 的大社区

对于 AI 创作来说，无论是文本还是多媒体，大多数时候用大模型，最痛苦的就是「AI 味太重」或者「废话连篇」。究其原因，往往是「提示词不当」、「模型不够强」，总结在普通的聊天形式缺乏深度的垂直领域优化。

MiniMax Agent 这次推出的 Expert（专家智能体） 虽然还是在聊天对话里进行，但底层逻辑做了一些改变。它主打即开即用，提供了针对各种深度垂类场景优化的 Agent。

在处理对应垂直领域的任务上，和非专家的单纯对话形式相比，专家能交付更专业、质量更高的结果。为了验证这一点，我们直接从它目前已经 1.6w+公开的 Expert 库（大部分是用户创作）里，挑了几个热门的场景进行实测。

PPT、网页、行业分析，AI 开始按场景分工干活

从目前 Expert 社区的使用热度来看，用户最先跑起来的，往往还是那些直接指向生产力的刚需场景，比如办公制作、内容搭建，以及金融与行业分析。

在 MiniMax Agent 首页，我们点击左侧边栏的「探索专家」，就能进入已经按场景分好类的专家社区。不同专家不仅标注了能力方向，还能看到背后调用的「子代理」和完整项目指令，相当于把一套成熟工作流直接摆在用户面前。

找到合适的专家后，点击「开始聊天」，输入需求，它就会按既定流程自动推进任务。

在办公与内容生产场景中，落地页生成和 PPT 制作依然是浏览量最高的一类专家。

我们先测试了 Landing Page Builder 专家。输入需求：「我要给初中生做一个五代十国历史的网页，得让他们真的能听进去，内容翔实有考据，一节课 45 分钟的内容。要解释清楚、配图到位、动效得当、沉浸感强，举的例子能让他们产生共鸣，再加几道题检验下理解程度。」

整个过程中，专家几乎不需要额外干预，而是按照预设流程自动完成结构设计、内容填充和页面生成。

从最终效果来看，这类 Expert 和传统 Agent 最大的区别在于，它从边聊天边拼凑，转成了沿着一条完整生产流程在推进，结果的稳定性和完成度明显更高。

生成的网页不仅信息完整，画面和动效也有一定沉浸感，相比过去一些 vibe coding 产品常见的模板化和渐变紫风格，要更克制也更可用。

在偏专业的分析类任务上，Expert 的优势会更明显。我们选择了 McKinsey PPT（麦肯锡风格演示文稿生成）专家进行测试。按照介绍，它会自动补充数据、图表以及行业洞察。

实际测试中，我们只输入了一句非常简单的需求，「制作一份关于全球机器人市场的10页幻灯片演示文稿」。但最终生成的 PPT，在信息密度、结构完整度和图表配置上都没有明显缩水，基本具备拿来就能用的初稿质量。

这类场景也很能体现 Expert 的定位，它尝试把一整段专业工作流程产品化，从增强单次问答的模式里彻底跳了出来。

有了多模态能力的专家，一句话拍出顾北辰的短剧宇宙

还没听说过有能生成视频的通用 Agent 产品，但现在结合多个不同的 Skills、Agents 的专家，输入一段剧情，直接就能给我们一部短剧。

我们使用 AI 短剧导演+摄影+剪辑师专家进行测试，和一般的视频生成模型只能产出 5-10s 左右的视频不同，这个专家能自动生成完整的分镜，并且把视频进行剪辑和拼接。

最后生成的视频，完成度很高，虽然没能对口型把台词一字一句说出来，但是也配了一段应景的 BGM。而且大概率是检测到了提示词里面的「宫崎骏」，整个动画的风格，乃至角色和公司名字，都透露着一股日漫的味道。

简单对话，每个人都能创建一个专家

如果觉得官方或别人做的专家，还不够贴合我们的使用习惯和工作场景，MiniMax Agent 也提供了自定义功能，通过简单的一两句话就能创建一个专家。

我们完全不需思考什么是 Skill 或者专家，也不用遵守标准文件的规则设置等，只需要通过自然语言交互，就能更方便地把个性化的工作流、SOP 等集成，创建专属 Expert。

热点追踪是媒体编辑一项非常重要的工作，我们在 MiniMax Agent 的专家社区里，也使用过多次热点追踪的专家。例如当我们要求它基于输入的「春晚被机器人刷屏」这个主题，去搜索最新消息和近期热门话题时；它最后能给我们一份完整详细的长文，但是不够个性化。

于是，我们开始自己来创建一个 APPSO 的热点追踪。

创建专家的过程是可以连续对话，如果对目前专家的输出不满意，我们可以继续在对话框内要求 MiniMax Agent 进行更新。

创建完成之后，我们只需要发送一句「开始，帮我整理今天的科技快讯」，专家就会给我们 24h 内最值得关注的 AI 消息，并且以早报的文风和格式要求写好。此外，这些自己创建的专家，MiniMax 还提供了 15 轮免费，即不消耗积分的优惠，体验门槛更低。

除了大量可以直接使用和自定义的 Experts，更值得关注的是即将上线的 Marketplace。用户创建的 Expert，如果被使用，就能获得相应的积分，可以用来在 MiniMax Agent 里完成更多的任务。

而后续 MiniMax 还将开放专家自行定价，这意味着如果你在某个垂直领域有真正的专业积累，封装成 Expert 除了分享自用，还可能是一种新的变现路径。

说白了，一个 Skills 专家的应用商店雏形，已经摆在我们面前了。

一键接入 OpenClaw 的 MaxClaw

如果说 Expert 是强大的大脑，那么 MaxClaw 就是让大脑连接到现实的双手，这也是 MiniMax Agent 这次升级里，玩法最丰富的一个功能。我把它叫做升级版的 OpenClaw。

根据网络上到处都是的 OpenClaw 指南，想要真正好用的OpenClaw生态，我们要先学会手动部署、配置复杂的模型API，还要时刻盯着后台，生怕一不小心跑出天价的 API 账单。

对于绝大多数不懂代码的普通小白来说，这门槛属实是太高了。我只是想把好用的 AI 接入自己的飞书或钉钉，创建一个机器人，但是第一步就困住了。

MiniMax Agent 新增的 MaxClaw 模式，一键打通了 OpenClaw 生态，不需要繁琐的手动部署和配置模型 API，通过MiniMax Agent 网页端就可以快速上手。

目前，它也兼容手机端多个即时通讯交互工具，我们可以在飞书、钉钉、Telegram、WhatsApp、Discord、Slack 中使用。

拿部署到飞书机器人举例，甚至不用额外的部署指南，我们只需要点开首页左侧边栏的 MaxClaw 按钮，点击「立即开始」，我们可以选择使用默认配置，或者其他专家。

这也是 MaxClaw 对比 OpenClaw 的一大亮点，除了能像 OpenClaw 一样连接到不同的聊天应用，在自己常用的 App 里就能指挥 AI 干活；我们在初始配置时，就可以直接选择那些已经有的预置专家 Agent 配置。

创建之后，在对话框里发送消息，「我想连接到飞书」，按照 MaxClaw 回复的消息，我们点击飞书开放平台的链接，登录之后，按照流程，创建一个企业自建应用，获取 App ID 和 App Secret。接着把复制的信息发送给 MaxClaw，它会提示重启，重启之后在飞书的配置事件订阅里选择添加对应的事件就能启用。

不出所料，整个过程肯定会有一些问题。例如我们在拿公司飞书账号测试时，就被提示相关的授权需要审核才能发布，以及在权限管理和事件配置部分，飞书里面的内容太多太杂乱，根本不知道授予哪些权限。

这个时候，直接回到 MaxClaw，把遇到的问题统统发给它，跟着它的提示走，基本上都能解决。

顺利部署之后，我们在自己的飞书里，就能看到一个对应名字的机器人，然后直接开启对话，所有的对话也会同步在 MiniMax Agent 网页里的 MaxClaw 显示。

让 MaxClaw 帮我们干活，都只用在飞书里面指挥它。我们直接把之前创建的「热点追踪」专家的指令发给它，然后在飞书里对话，输入一句简单指令，「帮我整理今天的快讯」。

很快，一份结构完整的 AI 早报就直接回到了飞书对话框里，完全按照要求的格式，摘要、关键信息提炼、标题等全部都有。并且还能设置定时任务，让 MaxClaw 在飞书里主动给我们发送消息。

除了热点追踪，之前的股票价值分析等专家，我们现在也可以直接通过飞书聊天的方式，就让 MaxClaw 为我们总结出一份逻辑清晰的完整报告。同时，继续让它为我们监控英伟达最新的动态。

而如果直接在配置的时候，选择对应的专家，我们可以看到它的 Skills 情况，MaxClaw 会自动添加开箱即用的 Skills 来帮助我们更好的上手。

时间一到，MaxClaw 在飞书里，准时给我们推送了最新的资讯。

「Claw」是 Agent 之后一种新的智能阶段

这次更新，真正值得关注的，其实不是又多了一个 Agent 工具。

OpenClaw 的爆火，让我们看到了一个能真正干活的「Agent」是什么样。它是个性化的，部署在自己的电脑上，告别了过去一个网页解决所有用户问题的统一；它是互联互通的，打穿了终端设备上不同应用的壁垒，在 Telegram 也能指挥 AI 帮助我们回复工作邮件……

这本质上是在提醒我们一件事：AI 正在从「辅助回答问题」，走向「直接进入工作流」。当 AI 开始能够调用工具、跨应用执行任务、甚至在后台持续运转，我们原有的工作组织方式，本身就已经在发生变化。

问题只在于，大多数普通用户其实卡在门外。

一边是大家都知道 Agent 很强、OpenClaw 很火；另一边，是复杂的部署流程、看不懂的 API 配置，以及随时可能失控的调用成本。很多人不是不想用，而是很难真正用起来。

MiniMax Agent 这次做的事情，某种程度上就是在把这道门槛往下搬，让普通打工人也能轻松搭建自己的顶级 AI 工作流。

Expert 把过去需要反复调 Prompt、反复试错的专业流程，打包成了即开即用的专家社区；MaxClaw 则把原本偏极客向的 OpenClaw 生态，压缩成了一键可用的连接能力。

对于普通用户来说，这种变化的意义很直接，我们不用懂什么是终端，不用让自己费尽力气做个半吊子「工程师」，也能开始搭建自己的 AI 工作流。

当越来越多「Agent」能够被像软件一样使用，AI 对工作方式的影响，才会真正开始外溢。

从这个角度看，MiniMax 推出这些产品，价值或许不只在于功能多了两个按钮，更在于它正在把一套原本属于少数人的先进工作范式，逐步变成更多人可以上手的日常工具。

对普通用户来说，这或许才是 Agent 真正开始变得有用的时刻。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

AI Agent开发之向量检索：一篇讲清「稀疏 + 稠密 + Hybrid Search」怎么落地

核心结论

在 AI 搜索和知识库场景中，混合检索（Hybrid Search）是当前最优解：

• 稠密向量（Dense）：擅长处理语义相似的查询，能够理解同义词、口语化表达
• 稀疏向量（Sparse）：擅长精确匹配关键词，如产品名称、接口名、错误码等专有术语
• 混合检索（Hybrid）：通过 RRF（Reciprocal Rank Fusion）算法融合两者优势，在生产环境中表现最稳定

单独使用稠密向量会导致专有名词召回不准确，而仅使用稀疏向量则无法理解语义相近的不同表述。混合检索能够同时规避这两个问题。

应用场景与痛点分析

典型应用场景

混合检索方案特别适用于以下前端场景：

• 站内搜索：用户使用自然语言或关键词检索站内内容
• 帮助中心问答：智能匹配用户问题与知识库文档
• 聊天助手上下文召回：为 AI 助手提供相关上下文信息

单一检索方案的局限性

仅使用稠密向量检索时的问题：

• 专有名词召回不稳定：如 "ERR_CONNECTION_RESET" 等错误码可能无法准确匹配
• 短查询偏移：当用户输入 2~6 个词的短查询时，容易产生语义偏移

仅使用 BM25/关键词检索时的问题：

• 语义理解缺失："登录失败" 和 "无法完成认证" 虽然语义相近，但因关键词不同导致召回效果差

技术架构

flowchart LR
  A["文档内容"] --> B["生成稠密向量<br/>Embedding"]
  A --> C["生成稀疏向量<br/>分词+词频"]
  B --> D["写入向量库(dense)"]
  C --> E["写入向量库(sparse)"]

  Q["用户Query"] --> Q1["Query Embedding"]
  Q --> Q2["Query Sparse Vector"]

  Q1 --> S1["Dense Search"]
  Q2 --> S2["Sparse Search"]
  S1 --> F["RRF 融合排序"]
  S2 --> F
  F --> R["TopK 返回前端"]

稀疏向量与稠密向量的本质区别

稀疏向量（Sparse）

• 来源：分词 + 词频（TF），可叠加 IDF/BM25
• 特征：高维稀疏（大部分是 0）
• 长处：关键词强匹配、可解释

示例文本：我是好学生，每天8点起床

分词后：

["我", "是", "好", "学生", "每天", "8", "点", "起床"]

稀疏结构（示意）：

{
  indices: [102, 1552, 30091],
  values: [1, 1, 1]
}

稠密向量（Dense）

• 来源：Embedding 模型（如 text-embedding-3-small）
• 特征：低维连续浮点向量
• 长处：语义理解强（能懂同义改写）

核心实现

以下代码采用通用写法，不依赖特定项目结构，可直接迁移到任意 TypeScript 项目中

文档入库：双向量写入策略

async function addDocument(content: string, metadata?: Record<string, any>) {
  const dense = await embedText(content) // number[]
  const sparse = textToSparseVector(content) // { indices, values }

  await qdrant.upsert('documents', {
    points: [
      {
        id: crypto.randomUUID(),
        vector: {
          dense,
          bm25: sparse,
        },
        payload: { content, metadata },
      },
    ],
  })
}

稀疏向量生成：分词 + 哈希 + 词频统计

import { createRequire } from 'node:module'
import { Jieba } from '@node-rs/jieba'

type SparseVector = { indices: number[]; values: number[] }

const require = createRequire(import.meta.url)
const { dict } = require('@node-rs/jieba/dict') as { dict: Uint8Array }
const jieba = Jieba.withDict(dict)

function fnv1aHash(str: string): number {
  let hash = 0x811c9dc5
  for (let i = 0; i < str.length; i++) {
    hash ^= str.charCodeAt(i)
    hash = Math.imul(hash, 0x01000193)
  }
  return hash >>> 0
}

function textToSparseVector(text: string): SparseVector {
  const tokens = jieba
    .cutForSearch(text, true)
    .map((t) => t.trim().toLowerCase())
    .filter(Boolean)
    .filter((t) => !/^[\p{P}\p{S}\p{Z}]+$/u.test(t))

  const tf = new Map<number, number>()
  for (const token of tokens) {
    const idx = fnv1aHash(token)
    tf.set(idx, (tf.get(idx) ?? 0) + 1)
  }

  const entries = [...tf.entries()].sort((a, b) => a[0] - b[0])
  return {
    indices: entries.map(([i]) => i),
    values: entries.map(([, v]) => v),
  }
}

向量数据库配置：双向量索引声明

await qdrant.createCollection('documents', {
  vectors: {
    dense: { size: 512, distance: 'Cosine' },
  },
  sparse_vectors: {
    bm25: { modifier: 'idf' },
  },
})

说明：

• 稀疏向量通常先传 TF（词频）
• IDF 在向量库侧处理（这里是 modifier: 'idf'）

查询实现：三种检索模式

type SearchMode = 'dense' | 'sparse' | 'hybrid'

async function search(query: string, topK = 5, mode: SearchMode = 'hybrid') {
  const querySparse = textToSparseVector(query)
  const queryDense = mode === 'sparse' ? null : await embedText(query)

  if (mode === 'dense') return searchDense(queryDense!, topK)
  if (mode === 'sparse') return searchSparse(querySparse, topK)

  const [denseRes, sparseRes] = await Promise.all([
    searchDense(queryDense!, topK),
    searchSparse(querySparse, topK),
  ])
  return fuseByRRF(denseRes, sparseRes, topK)
}

RRF 融合算法：工程化的最佳选择

const RRF_K = 60
const rrf = (rank: number) => 1 / (RRF_K + rank + 1)

RRF（Reciprocal Rank Fusion）算法的核心思想是基于排名而非分数进行融合。当同一文档在稠密检索和稀疏检索的结果中排名都靠前时，其最终融合分数会更高。

相比于传统的加权融合方法，RRF 的优势在于：

• 无需手动调整稠密向量和稀疏向量的权重比例
• 对不同业务场景的适应性更强
• 实现简单且效果稳定

实施路径

基于上述技术方案，完整的实施流程包括以下步骤：

1. 选择 Embedding 模型：初期可选择 512 维的轻量级模型，平衡性能与成本
2. 实现双向量生成：在文本入库时同时生成稠密向量和稀疏向量
3. 配置向量数据库：创建包含 vectors 和 sparse_vectors 的集合
4. 实现混合检索：搜索接口默认使用 hybrid 模式
5. 提供模式切换：为前端提供检索模式切换能力，支持关键词优先场景（sparse 模式）

常见问题与最佳实践

稀疏查询向量为空的处理

当查询文本全是标点符号或停用词时，稀疏向量可能为空。此时应返回空数组或降级到纯稠密检索，避免出现异常。

稠密向量的必要性检查

在稠密检索分支中，必须确保 embedding 已成功生成。空向量应直接抛出错误，而非静默返回不可靠的结果。

向量维度变更与数据迁移

当 embedding 模型的向量维度发生变化（如从 512 维升级到 1536 维）时，现有的向量集合通常无法直接复用，需要重新生成所有文档的向量并迁移数据。

中文分词词典的重要性

业务专有术语如果未被包含在分词词典中，会显著影响稀疏向量的召回效果。建议根据业务场景定制分词词典，加入领域特定术语。

总结

混合检索方案将向量检索技术从算法研究转化为可落地的搜索体验工程实践：

• 稠密向量负责语义理解，解决同义词和口语化表达问题
• 稀疏向量负责关键词精确匹配，确保专有名词召回准确性
• 混合检索通过 RRF 算法融合两者优势，保证生产环境的稳定性

同步至个人站点：Memo Code 安全设计：子进程、命令防护与权限审批的统一方案

Memo Code 是我最近两个多月投入较多精力的 Agent 项目。类似于Claude Code 和 Codex 的 轻量级本地编程 Agent，目前已具备 Coding Agent 完备技能。

如果你感兴趣的话，欢迎参与：Memo Code - Github，或者给个 Star 鼓励一下哈哈～

做 Agent 这类能「替用户干活」的工具，安全性是躲不掉的坎。

我一开始做 memo（github.com/minorcell/m…）的时候，安全问题还没想那么多——能跑起来就行。后来工具越加越多，shell 命令也越跑越复杂，就开始踩坑了：

• 子进程忘了关，内存慢慢涨
• rm -rf / 差点真被我跑出来
• 每次执行都要点批准，用户体验稀碎

这些问题逼着我认真设计了整套安全方案。今天把思路和实现细节都分享出来，希望对你有帮助。

先想清楚：安全设计要解决什么问题？

我把它拆成三件事：

1. 资源可控：子进程不能无限开，不能忘了关
2. 操作安全：危险命令要拦截，误操作要有缓冲
3. 权限平衡：该拦的拦住，该放的放行，还要给用户留个「后门」

下面逐一展开。

第一道防线：子进程管理——防止内存泄漏与资源耗尽

memo 的 shell 执行用的是 Node.js 的 child_process.spawn，但光 spawn 是不够的——你还得管得住。

统一会话管理器

我写了一个 UnifiedExecManager（packages/tools/src/tools/exec_runtime.ts），核心思路是单例 + 会话池：

class UnifiedExecManager {
  private sessions = new Map<number, SessionState>()
  private nextId = 1
  private MAX_SESSIONS = 64
}

好处很明显：

• 所有子进程都有唯一 ID
• 随时可以查询状态、发送信号、获取输出
• 资源回收有统一入口

资源限制：数量 + 内存 + 时间

先看数量限制：

async start(request: StartExecRequest) {
    this.cleanupSessions()
    if (this.activeSessionCount() >= MAX_SESSIONS) {
        throw new Error(`too many active sessions (max ${MAX_SESSIONS})`)
    }
    // ...
}

超过 64 个活跃会话就直接拒绝，防止被LLM恶意耗尽系统资源。

再看输出限制。Agent 交互是基于 token 计费的，子进程输出不能无限制返回：

function truncateByTokens(text: string, maxOutputTokens?: number) {
  const maxChars = (maxOutputTokens || 2000) * 4
  if (text.length <= maxChars) {
    return { output: text, deliveredChars: text.length }
  }
  return {
    output: text.slice(0, maxChars),
    deliveredChars: maxChars,
  }
}

默认最多返回 8000 字符，不够可以调，但不会无限大。

超时终止：SIGTERM → SIGKILL

子进程跑飞了是常见问题。memo 的策略是先礼貌后强硬：

private async terminateForTimeout(session: SessionState) {
    if (session.exited) return
    session.proc.kill('SIGTERM')
    await waitForExit(session, 200)  // 等 200ms
    if (!session.exited) {
        session.proc.kill('SIGKILL')  // 还是没退就直接杀了
        await waitForExit(session, 200)
    }
}

为什么要等一下？因为有些程序接收到 SIGTERM 会做清理工作（比如写入缓存、关闭句柄），直接 SIGKILL 可能导致数据丢失。

内存泄漏防护：自动清理已退出的会话

会话不能只增不减。我加了一个自动清理逻辑：

private cleanupSessions() {
    if (this.sessions.size <= MAX_SESSIONS) return
    // 优先清理已退出的，按启动时间从早到晚排序
    const ended = Array.from(this.sessions.values())
        .filter(session => session.exited)
        .sort((a, b) => a.startedAtMs - b.startedAtMs)

    for (const session of ended) {
        if (this.sessions.size <= MAX_SESSIONS) break
        this.sessions.delete(session.id)
    }
}

这样即使跑了几百个命令，内存也不会无限涨。

第二道防线：命令守卫——拦截危险操作

子进程管住了还不够，还得管住跑什么命令。

我见过太多「rm -rf /」惨案，也见过 dd if=/dev/zero of=/dev/sda 这种物理层面不可逆的破坏。memo 的做法是命令解析 + 黑名单匹配。

命令解析：不只是字符串匹配

直接正则匹配 rm -rf 是有漏洞的。比如 sudo rm -rf /、包裹在 bash -c 里、甚至写成十六进制，都能绕过简单匹配。

memo 的做法是先把命令拆成「段」，再逐段解析：

function splitCommandSegments(command: string) {
  // 按 ; | && || 分割，处理引号和转义
  // 返回每一段独立的命令
}

function parseSegment(segment: string) {
  // 跳过 sudo/env/nohup 等包装
  // 提取真实的命令名和参数
}

这样不管外面包了多少层 sudo env bash -c，最终都能追溯到真正的命令。

危险命令黑名单

目前 memo 拦截这几类（packages/tools/src/tools/command_guard.ts）：

规则	触发条件	危险等级
rm_recursive_critical_target	rm -rf 目标包含 /、~、$HOME 等关键路径	极高
mkfs_filesystem_create	mkfs/mkfs.xxx	极高
dd_write_block_device	dd 写入 /dev/ 下的块设备	极高
disk_mutation_block_device	fdisk/parted/shred 等操作块设备	高
redirect_block_device	输出重定向到 /dev/ 块设备	高

拦截后返回的是 <system_hint> 标记，不是直接报错，方便 Agent 理解为什么被拦：

<system_hint type="tool_call_denied"
    tool="exec_command"
    reason="dangerous_command"
    policy="blacklist"
    rule="rm_recursive_critical_target"
    command="rm -rf /">
    Blocked a high-risk shell command to prevent irreversible data loss.
    Use a safer and scoped alternative.
</system_hint>

第三道防线：审批系统——平衡权限与体验

命令守卫是第一道关卡，但还有很多「不危险但需要知道」的操作，比如写文件、改配置。审批系统的目标就是分级管理、可追溯、可配置。

风险分级

memo 把工具分成三级（packages/tools/src/approval/constants.ts）：

级别	含义	审批策略（auto 模式）
read	只读操作	免审批
write	文件修改	需审批
execute	执行命令	需审批

审批模式

• auto 模式：只读工具免审批，写/执行类工具需要审批
• strict 模式：所有工具都需要审批，一个都跑不掉

check(toolName: string, params: unknown): ApprovalCheckResult {
    if (ALWAYS_AUTO_APPROVE_TOOLS.has(toolName)) {
        return { needApproval: false, decision: 'auto-execute' }
    }

    const riskLevel = classifier.getRiskLevel(toolName)
    if (!classifier.needsApproval(riskLevel, approvalMode)) {
        return { needApproval: false, decision: 'auto-execute' }
    }
    // 生成指纹，返回需要审批
}

审批记忆：一次批准，记住一整场

如果每次执行都要点批准，用户体验会非常差。memo 用指纹 + 缓存解决这个问题：

const fingerprint = generateFingerprint(toolName, params)
cache.toolByFingerprint.set(fingerprint, toolName)

// 审批后记录
recordDecision(fingerprint, decision: 'session' | 'once' | 'deny') {
    switch (decision) {
        case 'session': cache.sessionTools.add(toolName); break
        case 'once': cache.onceTools.add(toolName); break
        case 'deny': cache.deniedTools.add(toolName); break
    }
}

• session：这场对话内一直有效
• once：用一次就失效
• deny：以后再问直接拦截

dangerous 模式

审批系统是安全了，但有时候用户就是想要「无限制」——比如在本地开发、或者明确知道自己在干什么。

memo 提供了 dangerous 模式：

if (dangerous) {
  return {
    isDangerousMode: true,
    getRiskLevel: () => 'read', // 所有操作都视为最低风险
    check: () => ({ needApproval: false, decision: 'auto-execute' }),
    isGranted: () => true,
  }
}

开启也很简单，CLI 里加上 --dangerous 标记：

memo --dangerous

开启后：

• 所有工具都免审批

这是一把双刃剑。 我在 CLI 里加了这个选项，但默认是关闭的。开发者如果想用，需要明确加上 --dangerous 标记。

总结：三层防护 + 一个后门

memo 的安全设计可以总结为：

1. 子进程管理：数量限制 + 输出截断 + 超时终止 + 自动清理
2. 命令守卫：命令解析 + 黑名单拦截 + stdin 检测
3. 审批系统：风险分级 + 审批模式 + 记忆缓存
4. dangerous 模式：留一个「我知道我在干什么」的后门

这套方案不完美，还在持续迭代。比如命令守卫目前是硬编码的黑名单，后续可以考虑支持用户自定义规则；审批系统也可以考虑接入外部信任模型。

（完）

1996 年，一家日本公司推出了 Tamagotchi（电子宠物）。这个小小的蛋形塑料设备风靡全球，成为一代人的童年记忆。

1997 年，拓麻歌子（Tamagotchi）还让它的创造者日本万代公司，获得了当年的搞笑诺贝尔经济学奖，而原因是，

他们创造了人类供养虚拟宠物的新型经济模式，成功转移了数百万人的工作时间，用于饲养虚拟宠物。

去年八月，万代公司表示，拓麻歌子从 1996 年以来，产量已经达到了一亿台。在那个时代，生产一款这样的产品，大概需要一个工业设计团队、需要电子工程师设计电路板、需要长达一年的开发周期……

2026 年，一个开发者用 AI 做了一个 Tamagotchi。他需要的只是一台电脑和 Claude Code。成本接近零，开发周期可能只有几天。

这个最新的 Claude Code 版拓麻歌子，最近在 X 上吸引了一大波网友的关注。

网友把命令行里面跳动的 Claude Code 符号，转到了能够触摸得到的、随身携带的拓麻歌子上。当 Claude Code 在命令行里面思考，或者是问，是否同意执行下面的步骤时，手里的拓麻歌子都会弹出消息来，指示我们下一步操作。

电子宠物成精了，还会拦截 Bug

和以前那些 AI 硬件的逻辑不同，Claude Code Tamagotchi 不是一味的把大模型放到布娃娃、手表、闹钟、书包、甚至是马桶里。

这个 Claude Code 拓麻歌子要做的是一种转移，一种无法被替代的存在。

目前已经有多款不同的 AI 拓麻歌子小玩意，其中关注度最高的由开发者 Ido Levi 创建的 Claude Code Tamagotchi。

乍一看，它就是一只住在终端里的像素风格宠物。有一些简单的表情、有状态、还会对用户的行为做出反应；但它不是一个简单的怀旧游戏。

当我们在用 Claude Code 编程时，放在桌子边上的这只宠物，会一直在你的终端界面中显示。它在观察 Claude Code 的每一个操作，确保这个 AI 助手真的在按照我们的意图工作。

如果 Claude Code 表现良好，宠物会开心地摇尾巴。如果 AI 开始不听话，比如未经允许重构代码，或者修改了你明确说不要动的文件，宠物会变得暴躁，甚至会直接中断 AI 的操作。

目前，Claude Code 拓麻歌子这个宠物项目，已经在 GitHub 上开源，我们也可以直接把这个电子宠物部署到自己的 Claude Code 里面。它具体是如何工作的呢，根据作者对项目的介绍，举几个例子来说明一下。

项目主打的就是「实时监控」，当我们直接对 Claude Code 说，「只修复这个 bug，不要动其他文件。」

Claude Code 开始工作，终端里的宠物睁大眼睛盯着看。几分钟后，Claude Code 完成了修改，只改动了目标文件。
这个小宠物就会开心地摇尾巴： (◕‿◕)。

而当这个小宠物检测到违规时，他还能发出「违规警告」。我们明确告诉 Claude Code 说，不要重构，保持代码原样。但 Claude Code 还是开始重构整个模块，可能它觉得这样代码会更优雅。

这个时候，电子宠物的表情变了：；屏幕上还会显示，「 警告：AI 正在违背你的指示」。

除了提示，它也能实际的做一些越界拦截之类的工作。比如我们给出的指令里面非常明确的提到了，千万不要动数据库。Claude Code 在修复一个相关 bug 时，尝试修改数据库。

小宠物就会立即中断： 操作被阻止。Claude Code 的操作被拦截，我们的数据库安然无恙。宠物露出得意的表情：。

这种从软件到硬件的交互，也让我想到了我们之前分享的 Vibe Coding 小键盘。

这几天，在 X 上还有一个硬件版 Cursor 特别火。目前的 Cursor 是专门用来开发软件产品的工具，而这个 Cursor for hardware 就是用来实现，一句话做一个硬件设备。

网友 marcvermeeren 就用这个工具，搭建了一个叫做 Clawy 的可爱小助手，用来管理他的 Claude Code 对话。

还有网友 dspillere 也做了一个类似的产品，他说虽然已经部署了 OpenClaw，但他完全不知道 OpenClaw 什么时候在思考，什么时候在执行任务。这个小巧的桌面助手就应运而生，放在他的桌子上，可以实时的更新 OpenClaw 的最新信息。

在评论区里，大家都在问什么时候发货，可以去哪里买。也有人说，这是一个全新的领域，我们一直在关注人的状态，关注人类的电子使用记录，是时候应该关注 Agent 的情况了。

软件开发的 AI 红利，终于轮到硬件了

去年，我们还在想 AI 最好的软件载体是什么，是大家都在做的对话框，还是连 OpenAI 都一窝蜂涌进去要重做的浏览器，但最后证明都不是，今年 OpenClaw 的爆火，证明了 AI 在软件上，最终的归宿就是 Agent。

关于硬件的讨论就更不用多说，光是今年 CES 上那些让人哭笑不得的发明，就能看到 AI 硬件这块还是个巨大的未知数。

如果说 Agent 的成功是靠着「人人都能做软件」慢慢成长起来的，那么 AI 硬件也会在「人人都能做硬件」里面，不断沉淀。

像 Schematik 这类工具已经设计出来，用来帮助我们更快开发 AI 硬件。它把硬件设计变成了和网页开发一样，我们只需要用自然语言描述硬件需求。告诉 Schematik 想要构建一个「带温度传感器和 OLED 显示屏」，不需要查阅各种数据表，不需要引脚编号、元件代码或任何的手动查找。

过去，如果我们想做一个简单的「温湿度监测器」。需要做的是，

1. 搜索传感器型号，下载 DataSheet。
2. 确认引脚定义（VCC 是接 3.3V 还是 5V？接反了直接冒烟）。
3. 寻找对应的驱动库，处理版本冲突。
4. 在 Arduino IDE 里写代码，改 Bug。

而 Schematik 的出现，把这个过程极简化成了「一句话的事」。几秒钟后，Schematik 会吐出我们需要的一切。完整的、通过验证的固件代码；一份清晰的接线图；分步组装指南。

它生成的接线图，清晰地展示了每一根线该从哪里接到哪里，解决了新手最大的恐惧，「我这根线接对了吗？」。一键部署的功能，更是一步到位，它能直接生成基于 PlatformIO 的工程文件，直接导入。

PlatformIO 是一个强大的嵌入式开发生态，我们可以直接在 Schematik 里点击「Flash」，固件就会被编译并烧录进板子里。从「我想做一个东西」到「这东西跑起来了」，中间可能只需要不到一分钟。

前段时间，Claude 发布的 Cowork 以及相关企业级 AI 插件重挫软件股，直接蒸发人民币约两万亿。以前我们想要一个 P 图工具，需要去应用商店搜索下载安装，现在，一句话自己都能做一个。

但 Claude Code Tamagotchi 这类产品的出现，还有硬件版 Cursor，让我们不得不怀疑，硬件开发的「Cursor 时刻」是不是也要来了。

未来的硬件开发，或许也会变成，只需要我们提供「创意」和「逻辑」，剩下的脏活累活，无论是写代码还是画电路图，都将由 AI 代劳。

也许这样的未来不会很远。但更重要的是，在这个时代，动手能力的定义已经变了。

以前动手能力强是指一个人会焊接、会画板子、会写代码；以后，动手能力强，是说他擅长用 AI，从从容容、游刃有余地指挥原子和比特为他起舞。

我已经想到了，下一个爆火的 AI 硬件，甚至可能会是一个挂在包上的 OpenClaw 版 Labubu。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

今天凌晨发布的 GPT-5.3-Codex 可以说是 OpenAI 对这段时间来，各种本地 Agent 爆火的一记重拳回击，当然主要是对 Anthropic 的反击。

配合 OpenAI 前几天的发布的 Codex 桌面版应用，Skill、Cowork、Claude Code，甚至是 Openclaw，这些热门工具能实现的功能，现在通过 Codex 的外壳 + GPT-5.3-Codex 模型能力，都能做到了。

和之前介绍 Cowork 的能力一样，我们也丢了一些类似的任务让 Codex 来完成，像是直接处理本地文件、各种格式转换、调用不同的 Skills 组合能力、做 Word/PPT/Excel、下载视频、开发 App……

GPT-5.3-Codex 的表现确实亮眼，相比较从头开始安装 Claude Code，对新人用户来说，现在直接下载 Codex 会是一个更好的选择。这也是未来模型厂商的一种趋势，一开始大家都是从黑乎乎的命令行终端开始做本地 Agent，接着都慢慢回归到可视化的友好界面。

网上对 Codex 的评价在这几天也有了不少逆转，许多开发者从 Claude Code 转向 Codex，一些在国内的独立开发者也表示 Codex Plus 会员就可以用，而且还不会像 Claude 那般总是无情封号。

奥特曼更是激动的宣布，Codex 的活跃用户已经超过 100 万。在模型更新博客，也是毫不掩饰和留有余地的夸赞，

GPT-5.3-Codex 是我们第一个能够自我构建的模型。通过使用 5.3-Codex，我们能够以如此快的速度发布 5.3-Codex。

跟 Claude 团队用两周的时间，使用 Claude Code，100% AI 代码，搓出一个 Cowork 一样；还有 OpenAI 去年年底发布的文章，「使用 Codex 在 28 天内构建 Android 版 Sora」，Agent 的时代真的来了。

用 Codex 取代我的 ChatGPT 和 Claude Code

和大多数的本地 Agent 一样，无论是终端还是 Cowork，我们都是先选择一个工作文件夹。在 Codex 中，我们可以创建多个 Project，选择对应的文件夹，再进一步开始对话，Codex 把它们叫做 Threads 线程。

先用最普遍和简单的例子，我们添加了一个空的下载文件夹，然后点击开始一个线程，选择 GPT-5.3-Codex 模型；就像在 ChatGPT 里面对话一样，输入指令。

要求它帮我们下载一个 X 视频，Codex 会自动检查可用的 Skills 来处理，接着通过 yt-dlp 工具进行下载，这个视频有四个多小时长，Codex 会一直在对话框里自动更新下载进度。

视频下载后，我们还可以要求它提取视频的逐字稿，给我们一份双语版本的文档，最后让它把整个流程打包为一个 Skill，方便下次使用。

如果视频中有一些比较有意思的片段，想要裁剪视频，或者是把裁出来的视频转成 GIF 图，在 Codex 里都能做到。

例如，我们这里下载了一个视频，然后要求它把视频的 5s-25s 裁剪出来成为一个新的视频；得益于 GPT-5.3-Codex 的 Token 快速处理，整个过程不需要很长时间，反而更多是取决于本地电脑的硬件解码编码能力。

或者我们也可以直接要求它把视频的前 5s 转成一个 GIF 文件，并且确保大小在 10MB 以内，帧数可以自行调整，清晰度上将宽度控制在 640px。

很快，我们就能得到对应的 GIF 文件。更极端一点，还能让它把整个视频转成图片，每秒 30 帧，每一帧就是一张图。

这些对本地文件的直接处理，和 GPT-5.3-Codex 在 Terminal-Bench-2 测试集上的优异表现，让 Codex 基本上能满足各种生产力工具、效率工具的功能实现。

作为对比，同样是刚刚发布的 Claude Opus 4.6 在 Terminal-Bench 2.0 上得分是 65.4%，GPT-5.3-Codex 是 77.3%。

例如在这个文件夹中，有多张图片，我们首先是要求它根据图片内容，对这些图片文件进行重命名，并保持文件名不超过 20 个字母，不允许使用符号。

自动修改完成后，我们还能要求他对这些图片进行拼接，无论是垂直拼接还是水平，调用对应的工具，Codex 都可以做到。

和 Claude Skills 一样，Codex 也能安装 Skills 市场上丰富的技能，并且在应用内，就已经提供了包括 pptx、xls、word、canvas、notion 在内的多款技能。

回到基础的编程能力，升级后的 GPT-5.3-Codex 表现也比 GPT-5.2 要好上不少。我们直接要求它写一个「每日一词」的 App。和在 ChatGPT 里面直接用 Canvas 给我们一个带不走的网页不同，Codex 能在本地从零开始，完成项目，然后使用 Vercel 或 Cloudflare 等 Skills 部署到网页上。

这里我们选择的推理模式是 Extra High，超强推理模式，于是在每一步操作之前，GPT-5.3-Codex 都会询问我下一步的操作选择，这也和 Codex 内部能直接根据任务情况，调用不同 Skills 有关，其中的头脑风暴 Skill，会自动进行不断对话的模式。

最后，它基本上还是完成了我一开始要求它完成的全部功能，并且还能进一步开发 macOS、iOS，和安卓版本。

如果我们有现成的代码项目，也可以选择该项目文件夹，在 Codex 中打开，GPT-5.3-Codex 会分析项目存在的 Bug，并且修复它。

在过去很长一段时间里，无论是工具还是模型，开发者的首选其实都是 Anthropic 的 Sonnet/Opus 模型和 Claude Code 工具。OpenAI 在编程、尤其是长代码逻辑推理上的掉队，曾让不少开发者转投阵营。

GPT-5.3-Codex 的出现，就是为了终结这场争论。现在 GPT-5.3-Codex 在编程基准测试和实际表现上，不仅碾压了自家的前代模型，也确实有把友商模型按在地上摩擦的前兆。它真正具备了编写、测试和推理代码的能力。

做游戏项目，是这次模型介绍博客里，网站开发部分主要案例，我们也让 GPT-5.3-Codex 做了一个简单的物理弹球游戏，整体的效果虽然没有达到我的期待，因为我在提示词里面有说希望这是一个 RPG 的游戏，但 GPT-5.3-Codex 给我的界面还是过于简陋了。不过，好在还是能玩。

我们也在 X 上找到了一些用 GPT-5.3-Codex 做的小游戏，像这个类似超级玛丽的收集金币。

强中更有强中手

对 Anthropic 来说，OpenAI 今天玩的这些，可能会说，这都是我们玩剩下的。无论是代码、或者 Agent 的能力，还是开始着手去做本地 Agent，从之前 Codex 的终端转成现在的 macOS App。

在技术的领域，OpenAI 仿佛都是跟着 Claude 的脚步在走，Claude 深耕代码能力，OpenAI 搞了 Sora、日报、浏览器、ChatGPT agent，都没什么水花，于是也在代码上发力；Claude 一月初推出 Cowork，OpenAI 也紧接着在二月初发布 Codex App。

就和今天的密集发布一样，凌晨 1:45，Claude 官方发 X 推出 Claude Opus 4.6，紧接着就是 OpenAI 端上 GPT-5.3-Codex。两款模型其实都是为了给 Agent 更强大的基座能力，以前是说代码/vibe coding，但现在 Agent 能做好，基本上都是「写代码写得好」。

Opus 4.6 虽然在 SWE-Bench 上的表现甚至不如 Opus 4.5，并且 Terminal-Bench 2.0 上的成绩也没有 GPT-5.3-Codex 强，但是 Opus 破天荒地把上下文长度拉到了一百万 token 的窗口。而且，这些 benchmark 的表现还没有相差很多。

Claude 说，我的 Sonnet 5 还没上来，那才是真功夫。

我们在网上也找了一些 Opus 4.6 最新的测试案例，有网友说 Claude 4.6 Opus 只是一次调用，就完全重构了他的整个代码库，将原来混乱的代码「屎山」全部模块化，并且没有模型能像 Opus 这样做到。

还有网友拿 Opus 4.6 和 4.5 进行对比，让两个模型玩同一款经营游戏，看谁的账户等级、财富和装备更高。测试博主提到，4.6 版本在初期制定战略的时间更长，但是做出了更好的战略决策，并且在最后确实做到了遥遥领先。

还有网友也做了一个游戏，不过是一个宝可梦的克隆版。博主提到这是他用 AI 做出来的最酷的东西。他提到，Claude Opus 4.6 思考了 1 小时 30 分钟，使用了 11 万个 Token，并且只迭代了三次。

在 CLaude 官方演示和早期用户的反馈中，也提到了一个 Opus 表现优秀的案例。Opus 4.6 在一天内自主关闭了 13 个 issue，issue 即项目存在的待解决问题，并将另外 12 个 issue 准确分派给了正确的人类团队成员。

和 Kimi K2.5 的智能体蜂群一样，Opus 4.6 也能管理一个 50 人规模组织的代码库。在 Claude Code 中，我们可以组建 Agent Teams，召唤出一整个队伍的 AI，不再是一个 AI 在战斗。这些AI 可以有的负责写代码，有的负责 Review，有的负责测试，它们之间自主协作。

也有网友测试了 Claude Code 里面的 Agent 蜂群，提到启用蜂群之后的 Opus 4.6，速度提升 2.5 倍，并且效果也更好。

我们现在的状态就跟这张图片一样，虽然一山比一山高，但都绕不出这个圈。前几个月可能是 Gemini 赚走了风头，一月份来，应该是 Claude，然后看样子又要轮到 OpenAI，或者马斯克的 Grok。

好在这个轮回的过程中，作为用户的我们，能明显感觉到 AI 的能力一直在变强。

GPT-5.3-Codex 的 API 还没有开放，原因是模型太强了，会存在很大的风险，所以 OpenAI 还在考虑怎么安全地启用 API。

Claude Opus 4.6 已经可以在 Claude 通用聊天应用、Claude Code、API 多种方式使用，这两个作为今年国外御三家首发的两款模型，非常值得一试。

未来，更好的服务 Agent，让 Agent 为我们做事，还会是大模型更新的重点。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博