Marco Liu上周一个做硬件的朋友问我：现在的AI Agent是不是只能在云端跑？我说不是，你去看面壁智能那边搞的EdgeClaw Box，思路完全不一样。这个东西的定位很有意思，用我朋友的话说，它更像是一只在AI时代“两栖”的虾——本地设备上能活，云端也能活，不用非得绑死在服务器那头。
很多人第一次听到EdgeClaw Box这个名字，脑子里大概是“某个边缘AI开发套件”。我最初也这么以为。但仔细扒了一圈公开信息和面壁智能这几年的技术路线，我倾向于把它理解成：一个以“端侧小模型 + 云端大模型协同调度 + Agent工具调用”为核心的应用开发范式。换句人话，它的价值不在于给你一个更大的模型，而在于给你一整套让AI应用“既能在本地快速反应、又能在必要时上云求助”的干活框架。
这篇文章我不打算照抄官方文档去复述参数，因为公开技术细节其实不算多。我更想从一个常年折腾模型部署和应用开发的工程师视角，把EdgeClaw Box背后真正值钱的东西拆开来讲：为什么边缘AI和Agent会走到一起？所谓“两栖”在技术上到底怎么实现？如果你自己要搭一个类似架构的应用，该怎么下手、会在哪里踩坑。
如果你是做AI应用开发、想入门AI Agent工程，或者正在纠结“模型到底放本地还是放云端”，这篇应该能给你一个比较清晰的判断框架。我也会放一段可参考的实现思路，方便你拿回去改。
1. 拆开EdgeClaw Box这个名字：边缘、利爪与一个工具箱
1.1 Edge不是“轻量版”的意思，而是跑在数据发生的地方
“Edge”这个词在AI圈其实已经被用烂了，很多人一听“边缘AI”就觉得是“把大模型压缩一下放到手机里”。这话对了一半，但没说到本质。
边缘计算的真正出发点，是让计算发生在离数据最近的地方，而不是把算力集中在某个中心机房。为什么要在意这件事？因为当你的数据产生于手机、传感器、车机、摄像头时，把数据全部上传到云端再做推理，会产生三个绕不开的问题：第一是延迟，一次网络往返可能几百毫秒，但Agent在任务执行中通常要频繁决策，一次决策消耗几百毫秒，整体体验就跟不上；第二是隐私，很多数据用户本质上不愿意上传，或者按行业规定就不能上传，比如医疗记录、会议内容、个人习惯数据；第三是成本，所有请求都走云端大模型，调用量和credits会像流水一样跑掉。
所以EdgeClaw Box里这个Edge，我理解是一个很务实的立场：先把能本地解决的推理放在本地解决，把云端当成“外援”而不是“默认宿主”。
这个思路在行业里并不新鲜，但难点在于“怎么判断哪些事该留在本地、哪些事必须上云”，以及“端云之间怎么无缝切换上下文”。这两件事，才是真正考验功力的地方。
1.2 Claw指的是Agent的手：光有脑子还不够，还得会抓取和操作
再看Claw这个词。它字面是“爪子”，顺着这个意象往深想：任何一个真正可用的AI应用，光靠模型聊天是不够的。你让AI帮你订个会议室、查一下天气、调一下设备状态，它必须能对外部系统发起动作。这个“发起动作”的能力，在技术圈叫工具调用，也是现在AI Agent最核心的竞争点。
我见过很多团队把一个7B的模型部署到本地，跑起来对话还行，但只要一涉及工具调用就崩。要么模型输出的JSON格式不规范，要么参数张冠李戴，要么在对话历史稍微变长之后就忘了该调哪个工具。这说明什么问题？说明单纯的“语言能力强”和“能干活”之间，隔着一道工程鸿沟。
EdgeClaw Box把Claw放进产品名里，我猜他们是想强调一件事：这套东西不是给你一个能聊天的模型，而是给你一个能“上手干活”的智能体。它的模型能力、推理框架、工具注册与调用机制，应该是被深度绑定的，而不是模型一个模块、工具调用一个模块、部署又一个模块。绑定的好处在于，工具调用的成功率能从系统层面被优化，而不是指望大模型自己在推理时超常发挥。
1.3 Box的内核：把模型、工具与调度规则放进同一个盒子里
Box这个词最容易被忽略，但它恰恰决定了开发者的体感。用过各种端侧推理框架的人应该都有体会：把模型塞进设备只是第一步，后面还得自己写内存管理、上下文截断、网络请求调度、工具返回结果的拼装……整个链路串起来，工作量非常大。
所以EdgeClaw Box给我的感觉是，它想把“模型+工具+端云调度”打包。你可以不关心本地模型怎么加载、什么情况下触发云端切换、工具接口怎么暴露，框架层面直接给你一个相对统一的容器或SDK。
这种打包思路的好处是降低工程门槛。假如你是一个独立开发者，想做点AI应用，却要先把模型部署、量化、推理优化、工具调用全部搞定，大概率还没等到产品上线就放弃了。但如果有一个成熟的“Box”，你要做的事就变成了：定义你的工具、设定哪些数据必须留在本地、给Agent一个初始指令，然后放手让它跑。
我个人的判断是，EdgeClaw Box真正想占据的，不是“模型性能榜单”上的位置，而是“AI应用开发基础设施”的生态位。它不是用一个大模型去惊艳你，而是用一套标准化的方式，帮你应对“智能必须无处不在”这个工程难题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 端云两栖到底解决了哪些真实痛点：延迟、隐私与成本
2.1 本地态的生存逻辑：低延迟和隐私是硬需求
先看一个很具体的场景：你在手机上做一个AI语音助手，用户说了一句“帮我打开卧室灯并把空调调到26度”。这条指令如果走云端，语音识别一次、意图理解一次、工具调用一次，哪怕每次只要300毫秒，三四次串行下来也是秒级延迟。在智能家居这种需要“人一开口就立即有反馈”的场景里，这种延迟基本不可用。
但如果这个指令在本地完成呢？语音识别在端侧跑，意图识别由端侧小模型完成，开灯和调空调的动作也是本地接口直接调用，整个过程可以控制在几百毫秒以内，几乎感觉不到AI介入的痕迹。这才是用户欢迎的交互方式，而不是转圈圈等待。
隐私方面就更不用说了。你可以想象一个企业内部用的会议助手，它需要根据录音生成纪要和待办事项。这种音频数据如果默认上传到云端，很多企业法务根本无法接受。而端云两栖的设计里，会议录音可以一直留在本地，由端侧模型完成初筛、脱敏、结构化提取，只有在需要生成更完整总结时，再选择把已经脱敏的文本送到云端。敏感数据不出设备，处理结果照常产出，这是纯云端方案永远给不了的承诺。
2.2 云端的不可替代性：复杂推理与长尾知识还得靠大模型
当然，我不是在吹“端侧能搞定一切”。实际上端侧模型在复杂推理、创意生成、超长文本理解这些方向上，和云端大模型仍有明显差距。一个7B甚至1.5B的模型，能帮你做摘要、分类、指令抽取，但要让它写一篇像样的行业调研报告，或者基于很长的对话历史做多步逻辑推理，坦白说还是为难它。
这时候两栖设计就体现出优势了：本地解决不了的，自动或半自动地把请求切到云端。比如上面的会议纪要场景，用户如果在会议结束后说“帮我把这周所有会议整理成一份周报，按重要程度排序”，这个任务涉及的信息量已经超出了端侧上下文容纳能力。此时Agent可以把原始摘要作为上下文附件，交给云端大模型去做分析和重组，生成一份高质量周报。
这种“本地先做粗加工、云端再做深加工”的分工，比两种极端方案都合理。纯本地方案会在复杂任务上表现拉胯，让用户觉得AI“笨”；纯云端方案会牺牲隐私和响应速度，让用户觉得AI“远”。两栖虾从来不会被逼着选边站，这也是面壁给这幅路线图起名的用意所在。
2.3 切换逻辑的微妙之处：两栖不是“二选一”而是可感知的浮动
理想很丰满，麻烦就在切换上。什么时候该留在本地？什么时候该上云？这个决策如果做不好，体验会非常割裂——有时候秒回，有时候转圈十秒，用户完全没法预期。
我做过的端云协同项目里，常用的一套判断维度是三层漏斗：
第一层看网络状态。如果当前设备离线，或者网络质量极差，那就无条件使用本地模型。这个判断最简单，技术上也最容易实现，拿一个网络探测就能搞定。
第二层看任务复杂度。可以给Agent设计一个自评估步骤，让它先判断：“这个任务我自己的参数规模能不能完成？”如果只是信息抽取、简单的规则问答，就留在本地；如果涉及长文生成、深度推理、抽象总结，就标记为“需要上云”。这层判断可以通过一个独立的轻量分类模型来做，也可以在主模型输出里加一个路由标记。
第三层看用户隐私标签。有些请求即使云端处理效果更好，也必须留在本地。实际操作中我会给每个工具、每条会话数据打一个“允许出境”的属性位，Agent在规划时如果发现任何环节涉及不许出域的数据，就直接禁止整条链路访问云端。
这三个维度叠加起来，切换才不是靠“随机应变”，而是靠明确的规则和路由策略。这也是为什么我说EdgeClaw Box的价值在架构而不在某一个模型：它把端云两栖的调度逻辑抽象成了可配置、可控的模块，而不是让开发者每次从零临时拼装。
3. 为什么小模型在端侧也能扛事：压缩、推理与能力边界
3.1 从十几GB到几GB：蒸馏和量化是怎么把模型变小的
想跑在端侧，第一步得让模型体积降到设备能承受的范围。16比特FP16权重的一个7B模型，光参数就要占大约14GB内存，手机和开发板根本吃不消。所以大家通常做两步压缩：知识蒸馏和量化。
蒸馏的逻辑是“以大教小”——用云端大模型当老师，把它的输出行为变成训练数据，去训练一个小模型模仿它。学生模型虽然参数量小，但在训练阶段见过了老师在各种复杂指令下的回答模式，所以能学到不少“压缩过的智力”。面壁智能团队本身在端侧小模型上有不少积累，做这一套有天然优势。
量化则是直接动数值精度。把每个权重从FP16换成INT8或INT4，模型体积立刻降到原来的二分之一甚至四分之一。一个7B模型的INT4版本大约只需要3.5GB存储，这就完全可以放进一台16GB内存的电脑，或者一台高配手机。
不过量化不是没有代价。精度降得越低，模型就越容易出现“答非所问”或者输出不稳定。在我实测过的各种量化模型里，INT8几乎感知不到差异，INT4会偶尔有损失，尤其涉及JSON输出和函数调用时，参数错乱的概率会明显上升。所以如果你要做Agent，我建议先从INT8起步，而不是一上来就追求最小体积的INT4。
3.2 跑起来只是一半：内存复用、KV Cache与NPU适配
体积降下来之后，下一个问题是推理性能。模型在设备上跑推理时，不仅要加载权重，还要在计算过程中维护KV Cache——这是Transformer模型在生成每个token时都要保留的历史状态。上下文越长，KV Cache占的内存越大，速度也越慢。这也是为什么单纯堆模型参数没有意义，真正限制端侧体验的反而是内存带宽和显存容量。
具体操作上，我自己在做端侧部署时关注三件事：一是用滑动窗口或稀疏注意力限制历史长度，让KV Cache不会无限膨胀；二是尽量复用显存缓冲区，避免每轮推理都重新分配内存；三是把算子尽量映射到设备的NPU上跑，CPU兜底。不同设备的NPU指令集差异很大，这一块的适配工作量不比模型压缩小。
EdgeClaw Box这类套件存在的好处是，它大概率把这些优化都预置好了。开发者不需要知道具体怎么调KV Cache、怎么改算子，只要告诉框架“我的设备内存是多大、有没有NPU”，它自己会选一个跑得动的配置。
3.3 端侧模型的能力边界：认怂也是一种设计
讲到这我得泼一盆冷水：端侧模型的智力天花板是摆在那里的。一个三四B的模型，你再怎么调优，它在开放域创作、深度推理、复杂规划上的能力也比不上几百B的云端模型。客观承认这个差距，反而能把架构设计得更合理。
端侧小模型的正确使用姿势，是让它承担“高频率、低复杂度、强隐私属性”的任务。比如意图识别、实体抽取、命令路由、格式转换。这些任务看起来平凡，但它们是Agent跑起来最底层的骨架。判断一个端侧Agent好不好用，看的不是它能不能吟诗作对，而是它能不能稳定地把“把空调调到26度”映射成一条结构化的工具调用指令。
云端大模型的正确使用方式，则是处理“低频率、高复杂度、弱隐私属性”的任务。比如周报生成、代码架构设计、创意文案。这类任务每天可能只有几次，走云端就算贵一点、慢一点，也完全能接受。
把这两类任务分开，并由不同体量的模型分别承接，整体成本和效果就会进入一个比较理想的区间。这也是我一直强调“两栖”的真正含义：不是拿一个模型同时做所有事，而是不同模型干各自擅长的事，再由框架把它们粘成一个对用户无感的整体。
4. 让Claw动起来：Agent工具调用链与工程化落地细节
4.1 Function Calling的基础机制：先学会定义工具
Agent能不能干活，得看它能不能调工具。目前主流的做法是让模型输出一个结构化的调用请求，开发者在请求里告诉它有哪些工具、每个工具的参数是什么，然后模型根据用户的输入生成一个填充好参数的工具调用。
这里最关键的是工具描述写得好不好。很多团队第一次做Agent时工具定义写得很随性，比如只给一个名字和一个笼统的描述，然后指望模型自己理解。结果是模型在真实运行时经常选错工具或漏填参数。写得足够清楚的工具描述应该包含几部分：工具名称、一句话说明“在什么场景下用”、每个参数的schema约束、必填项和可选项、边界条件。
举一个我自己项目里的例子。假设要给Agent加一个“查询附近餐厅”的功能，只有一句话“查餐厅”是不够的。一份合格的描述会写成：
- 工具名称：search_restaurants
- 用途：当用户想查找附近可吃饭的地方时使用
- 参数：location字符串（必填，用户所在地址或商圈）、cuisine字符串（选填，菜系）、price_level整数（选填，1到4，代表消费档次）、limit整数（选填，默认5）
模型看到这样的定义，出错的概率会低很多。这个经验对端侧小模型尤其重要，因为小模型的指令遵循能力弱，如果工具描述本身模棱两可，它很可能给你一个格式正确但语义完全跑偏的调用。
4.2 Agent主循环：从“会聊天”到“会办事”的关键一步
有了工具定义，下一步就是搭建Agent的主循环。这个循环本质上是一个“观察-决策-执行-再观察”的过程。
以我给本地硬件写的Agent为例，主循环大概长这样：
- 接收用户输入，把它拼进当前对话上下文。
- 模型在推理时输出两种结果之一：要么直接生成最终回复；要么输出一个function_call，附带需要调用的工具名称和JSON格式的参数。
- 如果是function_call，框架拦截它，在本地执行对应函数，比如操作设备、查询数据库、请求外部API。
- 把函数执行结果作为observation，拼回对话上下文，重新交给模型。
- 模型再决定是继续调用下一个工具，还是给出最终的文本回复。
我把这个循环实现成一个Python状态机，核心代码逻辑大概是这样的（伪代码，仅作思路参考）：
python复制# 工具注册表：名称到函数的映射
tool_registry = {
"turn_on_light": turn_on_light,
"set_ac_temperature": set_ac_temperature,
"get_room_sensor": get_room_sensor,
}
def agent_loop(session, user_input):
# 决定本次任务是否允许走云端
privacy_allowed = session.get("privacy_mode") != "strict_local"
max_steps = 5
messages = session.get_messages() + [{"role": "user", "content": user_input}]
for step in range(max_steps):
response = model.chat(messages, tools=list(tool_registry.keys()))
if response.is_function_call():
tool_name = response.tool_name
tool_args = json.loads(response.tool_args)
if not privacy_allowed and tool_name in session.get_no_cloud_tools():
# 涉及隐私的本地工具不允许被云端部分间接调用，直接拒绝
messages.append({"role": "tool", "content": "该操作被本地隐私策略拦截"})
else:
# 真正执行工具的代码
result = tool_registry[tool_name](**tool_args)
messages.append({"role": "tool", "content": result})
else:
return response.get_final_text()
return "任务步骤过多，已中止"
代码不复杂，但实际工程里有几个地方很容易翻车。最典型的是函数执行超时和异常没处理，Agent卡在一个坏工具上反复重试，把整个对话流程拖死。我的建议是每个工具都包一层超时控制，超过预期时间直接返回一个标准错误结果，让模型自己决定换一条路径走。
4.3 工具调用稳定性：让模型每次都输出一个能用的JSON
做Agent遇到最多的坑，不是工具不够多，而是工具调用的输出不稳定。尤其端侧小模型，经常出现三种症状：一是凭空捏造参数，比如用户没给具体时间，它编一个“今天19:00”填进去；二是JSON少个花括号，直接解析失败；三是明明有两个工具可选，它非要自己发明第三个工具名。
针对这些问题，我用过几种有效的工程手段：
第一是给工具调用加JSON Schema后处理层。模型输出后先做一次宽松解析，如果JSON不完整就尝试用正则或简单修复器“抢救”一下，比如补全缺失的花括号、修正单引号为双引号。这听起来很土，但实测能把正常运行时的解析成功率提高不少。
第二是设置参数来源规则。凡是工具定义中标为“用户未提供”的参数，框架在传给函数前强制置为None，而不是让模型去猜。这个规则能消灭很大一类“参数幻觉”问题。
第三是强行约束模型的输出格式。有些推理框架支持基于GBNF或其他格式语法来做结构化生成，也就是在模型解码时只允许它输出符合JSON语法或特定schema的token序列。如果条件允许，优先用这种方案，等于从根上杜绝了格式错误。
第四是在规划阶段问模型一句“你确定你选对了工具吗？”——听起来有点傻，但实际上把工具选择作为一次显式的再评估，可以显著降低误选率。代价是多消耗一次模型调用，但在关键任务上值得。
5. 一个完整的参考实践：搭一个会议纪要类的端云协同Agent
5.1 需求拆解：什么必须本地做，什么可以上云
理论说了不少，接下来拿一个具体的应用来串一串：给公司内部做一个会议纪要Agent。输入是会议录音，输出是要点摘要、行动项清单和负责人。
第一步不是写代码，而是做隐私和任务拆分。会议录音绝对不出公司设备，这是底线。但光录音的本地转写，普通端侧模型基本干不了。嗯，好在这类任务不一定非要跑大模型，目前很多成熟的本地语音转写工具箱已经能做得不错，先把语音转成文本，这一步可以完全离线完成。
语音转出来的原始文本存在哪里？还是本地。这时候端侧小模型可以先把文本做一道粗加工：分段、去掉语气词、识别说话人标签，然后把结构化之后的纯文本提供给上层Agent。这时候再判断任务分级：如果是简单任务，“帮我提取这段会议里的决定事项”，本地小模型自己就能干；如果是复杂任务，“写一封邮件给没来参会的同事，说明会议背景、你的分工和下周三之前需要他配合的事项”，这就建议上云，交给大模型综合生成。
5.2 实现路径：端侧、云端与Agent骨架怎么拼
下面给一个可参考的实现骨架。我用Python描述，核心点在于把本地推理和后端大模型调用封装成同一个model接口，用配置项做切换。
python复制# 第一次粗加工，在端侧完成
from whisper_local import transcribe
from local_models import LocalMeetingCleaner, LocalActionExtractor
text = transcribe("meeting_20250520.wav", language="zh")
cleaner = LocalMeetingCleaner()
structured = cleaner.clean(text) # 输出分段文本+说话人标签
# 判断复杂度，决定是否走云端
from policy_router import RoutePolicy
route = RoutePolicy(privacy_hint=structured.has_privacy_sensitive_field)
if route.should_call_cloud(task="generate_recap_email"):
cloud_agent = CloudAgent(endpoint="https://internal-llm.example.com/v1")
recap = cloud_agent.run(
system_prompt="你是会议助手，基于下面的会议记录写一封邮件……",
user_content=structured.text,
)
else:
local_agent = LocalAgent(model=LocalActionExtractor)
recap = local_agent.run(structured.text)
在路由策略上，我建议判定的默认值是“本地优先”，只有任务类型明确属于“生成、改写、抽象总结”这些高复杂度类别时才上云。如果任务类型模糊，可以再补一次云端分类判断，而不是把不确定的文本直接丢给大模型，毕竟大模型调用越多，隐私暴露面就越大。
5.3 我实际遇到过的三个问题与处理方案
这个项目我从零搭到能跑，中间至少遇到三个记忆深刻的问题。
第一个问题是端侧模型对会议文本的分段不够准确，经常把两个说话人的内容拼在一段里。试过换更大一点的量化模型，有效果但提升有限，后来干脆在语音转写阶段就把说话人信息作为元数据传到下游，让分段逻辑优先参考元数据而不是让模型从头推断。
第二个问题是端云切换时上下文的衔接。端侧模型先做了粗加工，云端模型拿到的是处理后的文本，它并不知道端侧做过什么处理，有时候会“自作聪明”补出一些原本没有的内容。解决方法是云端模型的系统提示词里必须显式说明“你收到的内容是本地系统预处理过的，只允许基于给定内容改写，禁止补充事实”。
第三个问题是成本失控的风险。云端大模型调用就像一个没有水表的水龙头，一旦Agent循环里出现异常循环调用，费用会悄无声息地涨上去。我的处理方案是两条硬限制：单个任务的模型调用次数不超过5次；单次会话累计云端token数设一个上限，超过直接降级为本地模型继续处理。宁可让总结质量差一点，也不能让账单失控。
这三条方案没有一个是高深的技术，但都是线上跑过之后才总结出来的真实经验。
6. 给想上车的人一句实话：EdgeClaw Box适合谁，以及更适合怎么吃
6.1 适合的场景无一例外都有“高频+隐私+实时”的共性
如果你问我什么样的团队应该第一时间研究这类端云协同架构，我的答案是：产品里存在“高频调用、隐私敏感、对延迟有硬要求”这三要素中任意两个的场景。
典型代表是智能家居入口。用户每天要对助手说几十次指令，每条指令都涉及家庭环境和行为习惯数据，而且必须秒回。这种场景里，本地意图识别加云端复杂对话几乎是唯一合理解。
第二类是车机助手。车机网络环境不稳定，隧道、地下车库经常断网，但用户对导航、空调、车窗的控制要求极高可用性。本地先执行，云端后补知识，这种“先干再说”的体验会让用户明显感觉车机比手机助手更可靠。
第三类是办公协同辅助工具。会议录音、文档草稿、日程安排，数据敏感程度高，但用户偶尔又需要高质量长文生成能力。端云两栖能让敏感数据不出域，同时在用户明确允许的情况下享受大模型的能力加成。
这些场景的共同点是，它们不像通用聊天机器人那样“什么都能聊”，而是有明确的任务边界和工具集合。正因为任务边界可控，端侧小模型才扛得住；正因为扛得住，整套架构才有资格上场。
6.2 不适合的幻觉：别指望它一夜之间造出全知全能的天网
我也得把丑话说在前面。如果你理解中的AI应用是一个类似“通用个人助理”的产品，用户可能问历史、可能问代码、可能问情感建议、可能要求写小说，没有一个明确的任务半径，那以当前端侧模型的能力，光靠本地绝对撑不起这样的体验框架。哪怕是端云协同，云端的成本也会让你很头疼。
另外，如果团队里没有至少一个人能搞定模型推理框架的调试、没有愿意仔细写工具定义的人，那再好的Box给你也发挥不出来。这类基础设施的价值，是在一个清晰的产品逻辑之上才能放大的。
6.3 我的建议：从小闭环试起
我个人建议想尝试的人不要一开始就奔着“整体接入”去。先拿一个最核心、最高频的小任务跑通闭环。以我自己为例，我最初只做了“天气查询”一个工具，加一个本地意图识别模型，然后用云端模型兜底闲聊。跑通之后我才逐步加工具、加隐私策略、加成本控制。
这样做的原因是，Agent的每一个环节互相牵制，模型、工具、路由、成本四者必须相互调优。你需要在小闭环里去感受它们之间的牵制关系，才知道你的产品最适合在哪一层选择端云切换策略。
EdgeClaw Box这类产品给我的启发，不止在于“端侧模型终于能跑Agent”这件事本身，更在于它把一种新型的软件架构思路具体化了。AI应用不应该被锁死在“要么本地什么都干不了、要么云端什么都说了算”的两难里。一定有第三种形态，像那只两栖虾一样，哪里更适合生存就游向哪里。我踩了这么多坑之后最大的体会是：做AI产品，真正值钱的能力不是训练一个大模型，而是知道在什么场景下用多大的模型、让它干多少活、以及什么时候提醒自己别贪心。