端侧模型时代的 Agent 基础设施：当模型退化，Harness 如何升级

May 20, 2026

当模型从云端几千亿参数下沉到手机、眼镜、IoT 设备上的 1-7B 参数，Agent 基础设施面对的挑战将从 "模型会处理好" 翻转为 "模型一定会出错"。这不是渐进优化，而是设计哲学的根本转向。本文将系统分析端侧模型的能力衰减维度，提出 7 项 Agent 必须掌握的核心技术，并给出 Harness 架构的升级路线图。

一、能力衰减：端侧模型的真实面貌

维度	云端 (GPT-5/Gemini 3.5)	端侧 (1-7B Q4)	衰减
推理深度	10+ 步链式推理	2-3 步后漂移	~5x↓
上下文窗口	1M tokens	32K-128K	10x↓
工具调用准确率	95%+ 格式正确	60-80%，参数幻觉	~30%↓
指令遵循	复杂多约束	单约束，冲突时随机选	显著↓
多模态	原生全模态	文本为主，视觉退化	取决于硬件
延迟	200-500ms	10-50ms (NPU 本地)	10x↑ (利好)
可用性	99.9% SLA	离线/间歇网络	新约束

注意延迟这一项：端侧 NPU 推理比云端 API 调用快 10 倍以上。这为数倍的计算开销（验证、重试、多模型投票）提供了空间——我们可以用延迟优势换取可靠性。

二、需要的 7 项关键 Agent 技术

1. 层级委托与混合路由

这是端侧 Agent 最重要的能力：简单任务本地解决，复杂任务透明升级到云端。

Task → Capability Router → 三类路径:
  ├─ 本地模型可处理 (80%) → 端侧执行, <50ms延迟
  ├─ 需要推理深度 → 云端代理, 异步返回
  └─ 需要确定性 → 规则引擎, 零延迟

Harness 需要实现：

任务复杂度分类器（token 数、工具链深度、历史相似任务难度）
云端/本地透明切换（用户无感）
连接中断时的优雅降级队列——离线任务排队，上线后自动同步

2. 验证执行而非信任输出

当模型只有 70% 的工具调用准确率，harness 必须在执行前、执行中、执行后三层验证，而非信任模型输出。核心原则：模型输出是 suggestion，harness 是 executor + enforcer。

Tool Call → Schema Validation → Sandbox Dry-Run → Commit/Rollback
                ↓                    ↓
          Pydantic/JSON     bash -n / python -c "compile()"
          Schema 校验         语法/副作用检查

关键机制：

Double-check pattern：关键操作（文件写、命令执行）要求模型生成校验和，harness 回读验证 hash(content)
输出签名验证：write_file(path, content) → 写入后立即 hashlib.sha256(read(path)).hexdigest() 比对
Sandbox 试运行：Docker/Wasm 隔离环境中先执行，验证无副作用后再提交到真实文件系统

3. 确定性后备与规则引擎

当模型工具调用格式错误或参数不可恢复时，不重试（重试在低准确率模型上是浪费 token），直接走确定路径。

# 不是：重试 3 次 → 放弃
# 而是：解析失败 → 规则引擎模板匹配 → 直接执行
TOOL_FALLBACKS = {
    "run_command": lambda args: safe_command_whitelist.get(
        args.get("command", "").split()[0], 
        deny
    ),
    "write_file": lambda args: write_if_path_in_workspace(args),
}

设计原则：永远有一条确定性后备路径。模型不可靠时，harness 接管决策。

4. 激进上下文管理

端侧 32K-128K 上下文极其珍贵。Harness 必须从 "压缩辅助" 变成 "上下文守门人"。

策略	云端做法	端侧做法
工具输出	全量返回	只返回 exit code + 首行 + 尾行
对话历史	滑动窗口	结构化摘要 + 关键决策点
错误信息	完整 traceback	错误类型 + 建议（不含堆栈）
系统提示	2000 tokens	500 tokens，最多 3 条规则

具体技术：

Structured summarization：每个 turn 后自动生成 <决策点, 结果, 下一步> 三元组替代原始对话
Tool output truncation：ls -la 返回文件计数 + 最近修改的 5 个文件，不返回完整列表
Dynamic system prompt：根据当前任务只注入相关规则，不是全量注入——if task == "code_review": inject(rules.code_review)

5. 预编译技能包

端侧模型的推理能力不足以 "从零规划"。需要将复杂工作流 预编译为状态机，模型只做参数填空。

云端: "帮我部署这个项目" → 模型自己规划 10 步
端侧: "帮我部署这个项目" → 匹配 skill "deploy-python-app"
      → 执行预定义状态机 (5 步)
      → 每步验证，模型只负责填空（端口、路径）

Harness 需要支持：

Skill registry：可检索的技能库，按任务类型索引
参数化模板：deploy(app_type="python", port={{model_suggest}}, path={{model_suggest}})——模型只填空，不规划
Skill → 状态机编译：将 skill 描述编译为可执行的状态机，减少模型自由度

6. 多模型协同

单一端侧模型无法覆盖所有场景。Harness 需要管理 多个专用模型的协同工作。

Agent Request
    ├─ Router: 任务类型分类
    ├─ 代码生成 → CodeGemma-7B (专用)
    ├─ 摘要/翻译 → Phi-4-mini (低延迟)
    ├─ 推理/规划 → Llama-4-7B (通用)
    ├─ 嵌入/检索 → nomic-embed (本地)
    └─ 复杂任务 → 异步升级云端

Harness 升级要点：

模型池管理（load/unload 策略，内存预算——端侧通常只有 4-8GB 可用）
任务→模型映射表（基于实际准确率数据，非基准测试——实测数据比 benchmark 重要 10 倍）
模型热切换（同一对话中根据子任务类型切换最优模型）

7. 人机协同升级

端侧模型的 "未知" 率远高于云端。Harness 必须知道 什么时候该闭嘴问人，而不是强行给出错误答案。

置信度评估:
  ├─ High (>0.9) → 自动执行
  ├─ Medium (0.7-0.9) → 执行 + 通知
  ├─ Low (0.5-0.7) → 生成建议 + 等待确认
  └─ Very Low (<0.5) → "我不知道，建议升级到云端或人工处理"

这不是简单的 ask_user 工具。Harness 层面需要：

Schema 匹配置信度：工具调用格式与预期的匹配程度
参数合理性检查：路径在白名单内？命令在允许列表？参数值在合理范围？
历史相似操作成功率：同样类型的工具调用，过去 10 次的成功率

三、Harness 架构升级路线图

从 "云端假设" 到 "失效假设"，Harness 需要新增 8 个核心组件：


当前 Harness (云端假设):
  Model → Prompt → Tool Call → Execute → Return
  ─────────────────────────────────────────────
  
端侧 Harness (失效假设):
                    ┌─→ 本地执行 (80%)
  Task → Router ────┤
                    ├─→ 云端委托 (15%)
                    │
                    └─→ 规则引擎 (5%)
                              │
  Model → Suggestion ─────────┤
                              ├─ Schema 验证
                              ├─ Sandbox 试运行
                              ├─ 输出签名校验
                              │    ↓
                              ├─ 成功 → 提交
                              └─ 失败 → Fallback 规则 / 用户确认 / 云端升级

组件	职责
Capability Router	任务复杂度评估 + 路由决策（本地/云端/规则）
Model Pool Manager	多模型加载/卸载/热切换，内存预算控制
Validation Layer	Schema + 语法 + Sandbox 三层验证
Context Budget Controller	激进的 token 预算管理，结构化摘要替代滑动窗口
Fallback Engine	模型失败时的确定性后备路径，规则模板匹配
Confidence Estimator	工具调用 + 输出的置信度评分，驱动执行决策
Skill Compiler	将预定义 skill 编译为状态机，模型只做参数填空
Connectivity Manager	离线队列 + 重连同步 + 云端透明升级

四、对现有 Agent 框架的启示

从现有 Agent 基础设施（如 Hermes、Antigravity SDK、LangChain）的架构看，可以逐步演进的方向：

Confidence-based routing：从 "一个模型从头跑到尾" 升级为 "根据任务特征自动选择最优模型"——flash 做简单分类，pro 做深度推理
Tool validation pipeline：当前的 hooks/pre-post 拦截应升级为结构化验证层——schema 校验 → dry-run → commit 三步流水线
Deterministic fallback chains：当模型 tool call 解析失败时，不是重试，而是退回到规则引擎——用确定性替代概率性重试
Context budget telemetry：跟踪每个 turn 的 token 消耗，基于预算自动决定 truncation 策略——不依赖模型自己管理上下文
Skill as state machine：将 skill 从 "给模型的提示" 升级为 "预编译的状态机"——减少模型自由度 = 减少出错概率

五、核心原则

端侧 Agent 的 harness 设计可以归纳为五大原则：

1. 不信任模型输出——每次执行前验证、执行中监控、执行后校验

2. 用延迟换可靠性——端侧 10-50ms 推理速度允许额外的验证计算开销

3. 永远有确定性后备路径——模型失败不是异常，是常态。Fallback 不是最后手段，是第二选择

4. 限制模型自由度——skill 编译为状态机，模型只做参数填空而非流程决策

5. 沉默是金——低置信度时比高置信度时更危险。不知道就说不知道，不要假装知道

总结

端侧模型入端不是 "把云端模型压缩一下塞进去" 这么简单。它要求 Agent 基础设施完成一次 设计哲学的根本转向——从 "模型能力时代" 到 "模型退化时代"。Harness 的角色从 "薄胶水层" 变成了 "厚防御层"：路由、验证、后备、预算管理、多模型协同、置信度评估、人机升级——这些不再是 nice-to-have，而是必须有的核心能力。

谁先做好这个转向，谁就掌握端侧 Agent 时代的基础设施话语权。