AI代码助手 VS 通用助手

许育瑜

411人浏览 · 2026-03-31 00:40:32

许育瑜 · 2026-03-31 00:40:32 发布

是什么？

AI代码助手VS Claw助手

产品定位不同

ClaudeCode定位：
- Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. Available in your terminal, IDE, desktop app, and browser.
OpenCode定位：
- OpenCode 是一个开源代理，帮助您使用任意 AI 模型**编写和运行代码。**它提供终端界面、桌面应用及 IDE 扩展。

===========================

ClaudeCowrk定位：
- Claude Cowork handles tasks autonomously. Give it a goal and Claude works on your computer, local files, and applications to return a finished deliverable. If it’s repetitive, messy, or just taking too long, assign it to Claude.
- 操作范围更广，不局限于某个项目，还能操作app等
openclaw主页定位：
- Clears your inbox, sends emails, manages your calendar, checks you in for flights.
  All from WhatsApp, Telegram, or any chat app you already use.
- openclaw能力更宽、内置能力更多 （接通IM工具，7x24在线候命/执行任务）
- 运行需要注意安全性的问题，比如网关怎么设置
- 这里的网关指的是应用层网关，将各个平台的消息转发给哪个agent处理【频道、用户、私聊】
阶跃AI桌面伙伴
- 操作系统级别的Agent，可以自主完成跨文件和网页的信息获取、处理和分析任务，还可以帮你设置系统提醒和备忘录，以及帮你文件整理和搜集.

============================

代码助手： 专业、精确
通用助手： 功能齐全、操作范围广、可通过IM工具访问

国内通用助手的产品

为什么目前基本上桌面AI助手都是需要付费的？免费版也只试用期（来源：deepseek）

产品名称	所属公司	免费额度	付费方案	单位成本参考
WorkBuddy	腾讯	新用户5000 Credits体验额度	暂未公布正式订阅价	积分制，按任务消耗
QoderWork	阿里	新用户限时2周免费试用	Pro版：$20/月（约145元） Pro+版：$40/月（约290元）	Credits消耗制，任务失败不扣费
阶跃AI桌面伙伴	阶跃星辰	内测免费	59-199元/月	按月付费
MiniMax Agent 2.0	MiniMax	限时免费（当前阶段）	会员订阅制，专业任务消耗积分	积分制，具体价格未公布
DuClaw	百度智能云	无明确免费额度	首购特惠：17.8元/首月原价：142元/首月	订阅制
ArkClaw	字节跳动	购买Lite Plan送7天免费试用	Lite Plan：9.9元/首月（原价待查） Pro Plan：200元/月，首月49.9元	按请求次数计费 Lite：约1.8万次/月 Pro：约9万次/月
AutoClaw	智谱AI	初期提供免费额度	后期积分收费，支持自带API Key	积分制，可接入DeepSeek/Kimi等模型
KimiClaw	月之暗面	无公开免费额度	仅限199元/月及以上订阅用户使用	捆绑订阅制
Skywork桌面版	昆仑天工	无明确免费额度	最低会员价：19.99元/月	订阅制，支持Gemini/Claude等模型切换

用户规模尚小： 仍处于早期探索阶段，无法形成规模效应摊薄成本，主要是大多数人还不清楚具体用途。
Token消耗大： 一个完整的桌面任务（如批量处理Excel、自动爬取数据）往往需要多次模型调用，成本自然水涨船高。

怎么实现的？

参考文档

https://github.com/shareAI-lab/learn-claude-code
- 有动态动画
https://github.com/shareAI-lab/claw0

工具使用

交互、反馈，手指的是多了个bash，自己执行代码：
- 新开进程/线程
- 借助cmd指令

run_bash的实现：

def run_bash(command: str) -> str:
    dangerous = ["rm -rf /", "sudo", "shutdown", "reboot", "> /dev/"]
    if any(d in command for d in dangerous):
        return "Error: Dangerous command blocked"
    try:
        r = subprocess.run(command, shell=True, cwd=os.getcwd(),
                           capture_output=True, text=True, timeout=120)
        out = (r.stdout + r.stderr).strip()
        return out[:50000] if out else "(no output)"
    except subprocess.TimeoutExpired:
        return "Error: Timeout (120s)"

任何额外的工具（read_file、write_file 等）都只是 bash 已有能力的子集。 增加工具并不会解锁新能力，只会增加模型需要理解的接口。模型只需学习一个工具的 schema，实现代码不超过 100 行。这就是最小可行 agent：一个工具，一个循环。

四个工具分别是 bash、read_file、write_file 和 edit_file，覆盖了大约 95% 的编程任务。
- Bash 处理执行和任意命令；
- read_file 提供带行号的精确文件读取；
- write_file 创建或覆盖文件；
- edit_file 做精确的字符串替换。
- 工具越多，模型的认知负担越重——它必须在更多选项中做选择，选错的概率也随之增加。更少的工具也意味着更少的 schema 需要维护、更少的边界情况需要处理。

模型怎么知道什么时候需要使用工具？

本地把定义好的工具告诉他，然后LLM自行选择

TOOLS = [    {"name": "bash", "description": "Run a shell command.",     "input_schema": {"type": "object", "properties": {"command": {"type": "string"}}, "required": ["command"]}},    {"name": "read_file", "description": "Read file contents.",     "input_schema": {"type": "object", "properties": {"path": {"type": "string"}, "limit": {"type": "integer"}}, "required": ["path"]}},    {"name": "write_file", "description": "Write content to file.",     "input_schema": {"type": "object", "properties": {"path": {"type": "string"}, "content": {"type": "string"}}, "required": ["path", "content"]}},    {"name": "edit_file", "description": "Replace exact text in file.",     "input_schema": {"type": "object", "properties": {"path": {"type": "string"}, "old_text": {"type": "string"}, "new_text": {"type": "string"}}, "required": ["path", "old_text", "new_text"]}},]


response = client.messages.create(
           model=MODEL, system=SYSTEM, messages=messages,
           tools=TOOLS, max_tokens=8000,
       )

skill的具体实现

渐进式加载：
- 开始的是时候load了skill的描述
- 加载整个skill，设计成了一个新的工具
load_skill工具：
- LLM决定使用哪个skill，返回tool_use: load_skill, name

上下文压缩

能省一点是一点
- JSONL vs 纯文本
  - 持久化保存的时候用的是JSONL
  - 发送的时候，会转换成纯文本
- 以前的tool call，可以只保留名称，不需要把参数啥的都带来带去
被动压缩：
- 预估当前使用了多少token，超过一定限度的时候，让LLM进行摘要（当然摘要本身也需要花费token）
- 不同实现，可能略有差异，比如：是否保留最近的上下文
主动压缩：
- /compact 指令

记忆系统

会话隔离

把会话持久化保存为JSONL
代码助手一般来说是会话隔离的
通用助手，会话本身有记忆，但也还会使用 【全局记忆+记忆搜索——比如Gemini这种网页版的会记得之前一些会话内容】

全局记忆

保留全部记忆为JSONL
摘要保留用户一些特有的习惯行文记忆

记忆搜索

每次输入提示词的时候，自动搜索相关记忆
类似于RAG，采用TF-IDF + 余弦相似度之类的方法
为什么要记住那么多东西？
- 个人习惯，各种事情，比如任务安排，会有冲突
但是全局记忆那么多，是怎么取舍的？
- 建立向量索引：将所有记忆文件（MEMORY.md、daily notes）切片、嵌入、存入SQLite+向量索引
- 按需检索：每次对话开始时，用用户的消息作为查询，检索出最相关的5-10个记忆片段
- 注入上下文：仅将这些片段注入LLM，而不是全量加载
关键数据：默认检索返回约400 token/片段，通常只取前5个。这意味着记忆部分对上下文的贡献只有2000-4000 tokens，远小于模型窗口（如Claude的200K）。
可以理解为全局的摘要/向量化检索的片段+提示词搜索到的记忆片段
- 可以当成是一种RAG

项目代码检索

建立项目代码索引数据库 vs 直接搜索
- 向量检索不一定对
- grep等搜索，要时刻以来模型自己判断，token消耗高（如果模型能力强的话，可以依赖）
- 混合：模型需要更准确的，就会走工具调用路线；如果不需要，那么直接向量库检索也可以。

维度	RAG 路线	工具调用路线（Agentic Search）
代表产品	Cursor、OpenCode（支持）、Cline（部分）	Claude Code、Gemini CLI
核心机制	预先建立向量索引，语义检索	实时用 grep、glob、read 等工具探索
代码理解方式	"一次性"检索相关片段	多轮试探、动态调整搜索策略
Token 消耗	单次检索，消耗较低	多轮交互，Token 堆积严重
基础设施	需要向量库、嵌入服务、索引维护	零依赖，即开即用
数据新鲜度	有延迟（需增量更新）	实时读取当前文件
可解释性	黑盒（向量匹配）	透明（能看到执行的 grep 命令）

任务系统

我们不让模型在思维链中默默规划，而是强制通过 TodoWrite 工具将计划外化。
每个计划项都有可追踪的状态（pending、in_progress、completed）。
这有三个好处：(1) 用户可以在执行前看到 agent 打算做什么；(2) 开发者可以通过检查计划状态来调试 agent 行为；(3) agent 自身可以在后续轮次中引用计划，即使早期上下文已经滚出窗口。
持久化

如果任务只存在于内存中，会面临三个致命问题：
- 断电即失：如果服务器重启或进程崩溃，AI 正在进行的复杂调研（Explore 代理的任务）会全部丢失。
- 上下文爆炸：如果把所有历史任务都塞进 Prompt，Token 会迅速耗尽且导致 AI 记忆混乱。
- 缺乏“责任感”：AI 无法在明天早上 8 点主动提醒你昨天未完成的音频调试任务，因为它根本不记得“昨天”。

后台任务

后台任务：
- 开一个线程或者进程去执行任务，然后执行状态反馈给消息队列，agent在每次交互前，检查消息队列里面的内容

多智能体

子agents
- 将前置上下文交给子agents，只接收子agents的执行结果（成功/失败），不共享上下文。
- Task 工具不包含在子代理的工具集中。子代理必须直接完成工作，不能继续委派。这防止了无限委派循环：没有这个约束，一个代理可能创建子代理，子代理又创建子代理，每一层都用略微不同的措辞重新委派同一任务，消耗 token 却毫无进展。一层委派足以处理绝大多数场景。如果任务对单个子代理来说太复杂，应该由父代理重新分解。
团队智能体
- 有人指挥，有人干活？
  - 负责创建、关闭、分配任务等等
- 通过messagebus进行通信，一般通过文件进行通信
- 干活如何不互相影响？
  - git worktree指令
  - 替代git stash，然后切换到需要干活的分支

7x24小时工作

心跳机制：
- 原理：系统内部设定了一个定时触发器（通常是每 30 分钟一次）。即使你没跟它说话，心跳也会强制启动一个 AI 会话。
  
  行为：AI 会读取一个名为 HEARTBEAT.md 的清单，检查诸如“是否有未读邮件”、“监控的网页是否有更新”、“日程是否有冲突”等任务。
消息和事件机制：
- 即时响应：当你在微信、Telegram 或飞书给它发消息时，平台的消息回调（Message Event）会立刻唤醒它。
- Hook 钩子：除了聊天，它还可以监听 GitHub 的提交、邮件到达、甚至是智能家居的传感器数据。

IM频道通信

官方是否提供bot-api
- https://core.telegram.org/api
- https://open.feishu.cn/api-explorer?apiNamexxx
微信这种目前对个人开发者没有提供，可能给企业或者内部开发提供了接口

网关路由

在claw0中，Agent的数量、特性和路由规则都是用户/管理员预先配置的，AI模型只负责在分配到的Agent角色内进行对话，不决定Agent的创建或数量。

# OpenClaw Gateway Configuration (2026 Standard)
gateway:
  name: "Main_Entry_Portal"
  platform: 
    type: "telegram"
    token: "YOUR_BOT_TOKEN_HERE"
    webhook_url: "https://your-domain.com/tg-hook"

# 消息分发逻辑 (Routing)
routing:
  default_agent: "General_Manager"  # 默认入口 Agent
  priority_rules:
    - match: "^/research"          # 匹配特定指令
      target: "Explore_Agent"      # 转发给探索型代理
    - match: ".*(bug|error).*"     # 匹配关键词
      target: "Debug_Specialist"

# 插件/能力集 (MCP Servers)
mcp_servers:
  - name: "audio_processor"
    endpoint: "http://localhost:8080/mcp/audio"
    capabilities: ["stft", "diarization", "vad"]

# 状态监控 (Heartbeat)
persistence:
  strategy: "daemon"
  heartbeat_interval: 1800s # 每 30 分钟自检一次

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

从手动点屏幕到自然语言驱动：我用 Trae + Playwright MCP 跑了一次 AI 自动化测试

AtomGit开源社区

从直播赋能到全域AI落地，播丫科技深耕数智新赛道

AtomGit开源社区

还在盲目找半导体 AI？业内落地好用的研发工具汇总

摘要：与非AI工具（www.eefocus.com/ai-chat/）为PCB设计提供高效解决方案，其1.1亿标准化ECAD模型库关联原厂数据手册，支持Altium/KiCad等主流EDA格式一键导出，省去手动绘制封装时间。相比传统方式，它能快速获取冷门器件封装及3D模型，并附带替代料、规格书等数据，所有模型均可溯源确保准确性。该免费工具尤其适合紧急项目，显著提升设计效率，避免因封装错误导致生产问