# agentShell **Repository Path**: wanquan9527/agent-shell ## Basic Information - **Project Name**: agentShell - **Description**: No description available - **Primary Language**: Unknown - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-04-09 - **Last Updated**: 2026-04-13 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # AgentShell — 自进化指令特化执行层 ## 项目设计方案 v1.0 --- ## 第一章：项目概述 ### 1.1 问题 当前所有 Agent 框架（LangChain、OpenAI Function Calling、MCP、Open Interpreter 等）共享一个结构性低效： **大模型每次对话都需要携带完整的工具描述。** 一份典型的 Agent 系统提示词包含 10-20 个工具的 JSON Schema 描述，每个工具 100-300 tokens，总计 3000-8000 tokens。这些信息大模型在训练时已经见过，是冗余的。10 轮对话下来，仅工具描述就消耗 50,000+ tokens，占总消耗的 69%，而真正有用的对话内容不到 20%。 更深层的问题是： - **环境适配缺失**：大模型不知道当前设备是 Linux 还是 Windows，是 Bash 还是 PowerShell，它只能"猜"。 - **生态依赖开发者**：工具数量取决于有多少开发者贡献代码，小众硬件永远没有足够的生态。 - **无状态复用**：每次对话都是从零开始，上一轮创建的工具知识不会延续到下一轮。 ### 1.2 方案 AgentShell 提出一个新的架构范式： **大模型只说"意图"，本地特化层负责"翻译+执行"。** ``` 传统范式: 大模型 → 构造完整工具调用 JSON → 框架解析 → 执行 AgentShell: 大模型 → 输出意图暗号 → 本地特化层翻译为原生命令 → 执行 ``` 大模型从"工具说明书朗读者"解放为"指挥官"，环境适配交给本地的"参谋部"。 ### 1.3 核心收益 | 维度 | 传统方案 | AgentShell | 改善 | |------|---------|------------|------| | 系统提示词大小 | 3000-8000 tok | 200-400 tok | **-90%** | | 单次工具调用输出 | 100-300 tok | 8-15 tok | **-90%** | | 10 轮对话总计 | ~72,500 tok | ~15,000 tok | **-79%** | | 跨平台适配 | 大模型自己判断 | 本地自动适配 | **免维护** | | 工具扩展 | 开发者写代码发版 | AI 实时创建注册 | **零等待** | | 最小运行资源 | ~100MB RAM | ~5MB RAM | **-95%** | --- ## 第二章：系统架构 ### 2.1 全景架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 用户层 │ │ 终端 / Web UI / IDE 插件 / API / 语音 │ └───────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Shell 前端（复用开源） │ │ 对话管理 · 上下文维护 · 流式输出 · 历史记录 │ │ 基础选型: Continue / gptme / Open Interpreter │ │ 改造点: 替换工具调用层为 %intent% $args$ 协议 │ └───────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 协议解析层 (Protocol Parser) │ │ 从大模型输出流中实时提取 %intent% $args$ 标记 │ │ 支持流式解析（模型还在输出时就可触发执行） │ │ 支持格式容错和 fallback（同时接受 JSON） │ └───────────────────────────┬─────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 命令特化执行层 (Command Specialization Layer) │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ 环境感知 │ │ 命令映射 │ │ 安全审计 │ │ │ │ │ │ │ │ │ │ │ │ OS/Shell/ │ │ 规则查表 │ │ 白名单·注入检测 │ │ │ │ 运行时/权限 │ │ 模板选择 │ │ 路径约束·沙箱 │ │ │ │ 可用命令集 │ │ 参数注入 │ │ 脚本审查 │ │ │ └──────┬───────┘ └──────┬───────┘ └──────────┬───────────┘ │ │ └─────────────────┼─────────────────────┘ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 沙箱执行器 │ │ │ │ subprocess │ │ │ │ container │ │ │ │ remote SSH │ │ │ └────────┬─────────┘ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 结果标准化器 │ │ │ │ 截断/压缩/token │ │ │ │ 预算控制 │ │ │ └──────────────────┘ │ └───────────────────────────┬─────────────────────────────────────┘ │ $ok:结果$ 或 $err:原因$ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Shell 前端 → 大模型继续推理 │ └─────────────────────────────────────────────────────────────────┘ ``` ### 2.2 指令注册表（自进化核心） ``` ┌─────────────────────────────────────────────────────────────────┐ │ 指令注册表 │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ 内置指令表 │ │ 用户指令表 │ │ 意图匹配索引 │ │ │ │ (只读) │ │ (可读写) │ │ │ │ │ │ │ │ │ │ "天气" → 查询天气 │ │ │ │ fl.ls │ │ 查询天气 │ │ "weather" → 查询天气 │ │ │ │ fl.rd │ │ 股票行情 │ │ "ls" → fl.ls │ │ │ │ pr.top │ │ 翻译文本 │ │ "列目录" → fl.ls │ │ │ │ nw.ping │ │ ... │ │ "看看家里" → 监控 │ │ │ │ ... │ │ │ │ ... │ │ │ └──────────────┘ └──────────────┘ └──────────────────────┘ │ │ │ │ 三级查找: 精确匹配 → 别名匹配 → 语义模糊匹配 │ │ 未命中时: 触发指令创建引导流程 │ └─────────────────────────────────────────────────────────────────┘ ``` ### 2.3 数据流 一次完整的指令执行流程： ``` 用户: "帮我看看上海今天天气" ① 大模型推理，输出: %查询天气% $local=Shanghai,time=today$ ② 协议解析层提取意图: category=通用, action=查询天气, args=[local=Shanghai, time=today] ③ 命令映射引擎查找注册表: → 用户指令表中找到 "查询天气" → 映射为: python3 ~/.agentshell/commands/weather.py local=Shanghai time=today ④ 安全审计: → 路径在白名单内 ✓ → 无注入风险 ✓ → 脚本哈希校验通过 ✓ ⑤ 沙箱执行: → subprocess 执行，30 秒超时 → 捕获 stdout/stderr ⑥ 结果标准化: → 截断到 2000 tokens 以内 → 格式化为 $ok:{"temp_c":"28","desc":"多云"}$ ⑦ 返回大模型: 大模型收到结果，生成回复给用户 ``` --- ## 第三章：核心设计 ### 3.1 意图标记协议 大模型和特化层之间通过一种极简的标记格式通信： ``` 语法: %.% $,,=$ 示例: %fl.ls% $/home$ 列目录 %fl.rd% $/etc/nginx.conf$ 读文件 %fl.fnd% $/var,*.log,s>50M,t=-7d$ 查找文件 %pr.top% $cpu,10$ 进程列表 %pr.kill% $1823,15$ 杀进程 %nw.ping% $8.8.8.8,c=5$ Ping 测试 %db.q% $SELECT * FROM users LIMIT 10$ 数据库查询 %lg.tail% $/var/log/sys.log,50,err$ 日志尾部 %pg.install% $nginx$ 安装包 %gi.diff% $HEAD~3$ Git 差异 返回: $ok:<输出内容>$ 成功 $err:<错误原因>$ 失败 $partial:<内容>$ 输出被截断 $timeout$ 超时 $hint:<提示信息>$ 创建引导 ``` **为什么用这个格式而不是 JSON：** | 格式 | 单次调用 tokens | 示例 | |------|----------------|------| | 传统 JSON Function Calling | ~120 | `{"tool":"find","parameters":{"path":"/home","size":"50M"}}` | | MCP 完整描述 | | 结构化代码块 | ~35 | `` ```exec\naction: find\nargs: {...}\n``` `` | | **意图标记（完整名）** | **~15** | `%find_large_files% $/home,50M$` | | **意图标记（缩写）** | **~10** | `%fl.fnd% $/home,50M$` | **为什么大模型能理解这个格式：** 大模型训练数据中包含数百万次 shell 命令的使用。它不需要 JSON Schema 来告诉你 `find` 命令需要 `-name` 参数，它本来就知道。我们需要的只是告诉它"用这种简写格式表达你已经知道的东西"。 ### 3.2 命令特化层 特化层是整个架构的核心，它的职责是将大模型的高层意图翻译为当前设备可执行的原生命令。 **三层降级架构：** ``` Level 1: 规则引擎（覆盖 85-95% 场景） ───────────────────────────────────── 纯查表，零模型依赖 资源: JSON Schema | ~200 | 含 inputSchema <5MB RAM, <1ms 延迟 原理: 硬编码的命令模板 + 环境选择 内置指令 → 平台模板选择 → 参数注入 → 生成命令 例: %fl.fnd% $/var,*.log,s>50M$ Linux+find → find /var -name "*.log" -size +50M -exec ls -lh {} \; BusyBox → find /var -name "*.log" -size +50k Windows → dir /s /b C:\var\*.log Level 2: 语义匹配（覆盖额外 3-5%） ───────────────────────────────────── 当规则表没有精确匹配时触发 方案 A: TF-IDF 关键词匹配（~10MB RAM） 方案 B: 微型 embedding 模型（~50MB RAM，纯 CPU） 延迟: <100ms 大模型说 "看看谁占了太多内存" → embedding 匹配 → 命中 "pr.top" (按内存排序) → 生成 ps aux --sort=-%mem | head -20 Level 3: 云端回退（覆盖 100%） ───────────────────────────────────── 本地无法处理时，将意图+环境快照发回云端大模型 大模型生成精确命令 → 返回本地执行 本次结果缓存到本地映射表（自学习） 下次遇到同样意图不再回退 ``` **环境感知：** 特化层在首次启动时检测当前环境，结果缓存供后续使用： - 操作系统类型和版本 - Shell 类型（bash/zsh/powershell/ash） - 是否 BusyBox/ToyBox - 已安装的运行时（Python/Node/Java 版本） - 可用命令集扫描 - 包管理器类型 - 权限状态 - 容器化检测 同一个意图在不同环境下自动映射到不同的命令，大模型完全不需要知道这些差异。 ### 3.3 安全体系 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 四层安全审计 │ │ │ │ Layer 1: 命令黑名单 │ │ ───────────────── │ │ 永久阻止的模式: rm -rf /, mkfs, fork bomb, curl|sh 等 │ │ 在命令生成后、执行前拦截 │ │ │ │ Layer 2: 路径约束 │ │ ───────────────── │ │ 可写白名单: ~/.agentshell/, /tmp/, ~/projects/ │ │ 可读范围: 全盘（受 OS 权限限制） │ │ 禁止访问: /etc/shadow, /boot/, /proc/sys/ │ │ │ │ Layer 3: 脚本审查（自进化场景） │ │ ───────────────── │ │ 大模型创建的脚本在注册前接受内容审查: │ │ 检测危险系统调用（os.system, eval, 动态导入等） │ │ 检测网络访问和文件写入（标记为 moderate，需确认） │ │ 脚本哈希校验（注册后如果被篡改，拒绝执行） │ │ │ │ Layer 4: 沙箱执行 │ │ ───────────────── │ │ 资源限制: 内存上限、CPU 时间、文件大小、子进程数 │ │ 超时控制: 默认 30 秒，最大 300 秒 │ │ 隔离环境: 最小化的环境变量集合 │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` ### 3.4 结果控制 执行结果在返回大模型前经过 token 预算控制： - **截断保护**：单次输出最大 8KB，超出部分截断 - **智能截断**：保留头部和尾部（对日志特别有效），中间用省略号 - **Token 估算**：粗略估算返回文本的 token 数，确保不浪费大模型的上下文窗口 - **格式统一**：所有结果统一为 `$ok:...$` 或 `$err:...$` 格式 --- ## 第四章：自进化系统 这是 AgentShell 最独特的创新——**指令生态系统可以由 AI 自行生长。** ### 4.1 指令生命周期 ``` 创建 → 审计 → 注册 → 使用 → 共享 → 进化 ``` 一个指令从诞生到成熟的完整路径： ``` 阶段 1: 意图未命中 ───────────────── 用户请求一个系统中不存在的功能 特化层查注册表未找到 返回创建引导（包含脚本规范和注册模板） 阶段 2: 大模型创建 ───────────────── 大模型根据引导编写脚本 通过 %fs.write% 保存到工作目录 通过 %run% 测试执行 通过 %cmd.register% 注册 阶段 3: 安全注册 ───────────────── 特化层对脚本进行安全审查 计算内容哈希（防篡改） 自动生成扩展别名（中英文、同义词） 更新意图匹配索引 持久化到磁盘 阶段 4: 正常使用 ───────────────── 任何会话中都可以通过意图名或别名调用 模糊匹配自动处理表述差异 使用统计自动记录 阶段 5: 生态共享 ───────────────── 用户可将指令导出为 .agentpkg 包 上传到社区仓库 其他设备可从仓库安装 厂家可将热门指令纳入内置集 ``` ### 4.2 交互示例 ``` ═══════════════════════════════════════════════════════════ 场景：全新设备，用户第一次使用 ═══════════════════════════════════════════════════════════ 用户: 帮我看看上海今天天气 大模型: %查询天气% $local=Shanghai,time=today$ 特化层: $err:COMMAND_NOT_FOUND:查询天气$ $hint:你可以创建这个指令。请编写脚本，然后注册。$ $hint:步骤: 1. %fs.write% $路径,代码$ $hint: 2. %cmd.register% $意图名,脚本路径,别名,参数$ $hint:脚本规范: 参数key=value传入，结果输出stdout(JSON)，错误输出stderr$ 大模型: (理解引导，编写天气查询脚本) %fs.write% $~/.agentshell/commands/weather.py, [天气查询脚本]$ 特化层: $ok:文件已保存$ 大模型: %cmd.register% $查询天气, python3 ~/.agentshell/commands/weather.py, 天气 weather, local time$ 特化层: $ok:指令"查询天气"已注册，别名: [天气, weather]$ 大模型: (现在执行真正的查询) %查询天气% $local=Shanghai$ 特化层: $ok:{"temp_c":"28","desc":"多云","humidity":"78"}$ 大模型: 上海今天多云，28°C，湿度78%。 ═══════════════════════════════════════════════════════════ 三天后，另一个会话 ═══════════════════════════════════════════════════════════ 用户: 北京天气怎么样 大模型: %天气% $local=Beijing$ 特化层: (模糊匹配 "天气" → 别名命中 "查询天气") (映射为 python3 ~/.agentshell/commands/weather.py local=Beijing) $ok:{"temp_c":"35","desc":"晴"}$ 大模型: 北京今天35°C，晴天。 ═══════════════════════════════════════════════════════════ 注意: 大模型不需要知道指令是怎么实现的 不需要知道脚本路径 不需要知道当前是 Linux 还是 Windows 它只需要说"天气"，特化层完成剩下的一切 ═══════════════════════════════════════════════════════════ ``` ### 4.3 指令组合 大模型可以创建组合指令，串联多个已有指令完成复杂任务： ``` 用户: "每天早上8点给我发一份系统报告" 大模型创建 daily_report.py: 1. 调用 %监控% $action=status$ → 获取系统状态 2. 调用 %fl.fnd% $/var/log,err$ → 获取最近错误 3. 调用 %pr.top% $cpu,5$ → 获取 CPU 前5进程 4. 汇总成报告 5. 调用 %通知% $channel=telegram,message=<报告>$ 注册为 %日报% $time=08:00$ 再用 %定时任务% 注册每日触发 → 一个全新的"每日报告"功能诞生了 没有任何开发者参与，完全由 AI 在对话中完成 ``` --- ## 第五章：自举生态 ### 5.1 核心命题 **对于安装了 AgentShell 的设备，是否可以通过该软件自行完善自身的软件生态？** 答案是：可以。这可能是边缘设备软件生态的未来形态。 ### 5.2 传统生态 vs 自举生态 ``` 传统模式: 厂家 → 开发者 → 用户 ────────────────────────────────── 厂家出硬件 厂家/社区开发操作系统 开发者为系统写软件 用户安装使用 问题: 小众硬件永远没有足够的开发者 OpenWrt 路由器能装的包远少于 Ubuntu 一个新芯片上市，等生态成熟要 2-5 年 自举模式: 厂家 → AI → 用户（开发者角色被 AI 替代） ────────────────────────────────── 厂家出硬件 + 预装 AgentShell + 特化小模型 + 运行时 用户说需求 大模型 + 特化层协作，实时创建软件 软件被注册、缓存、共享 本质变化: 不再等待开发者，AI 就是开发者 生态增长速度从"人月"变成"对话轮次" 每个用户的每次使用都在丰富生态 ``` ### 5.3 自举过程 以一块 IoT 开发板为例（ARM, 512MB RAM, 8GB 存储, WiFi）： ``` 出厂状态: 精简 Linux 内核 + BusyBox + Python3 运行时 + AgentShell 核心（~2MB）+ 特化小模型（~15MB） + 内置指令集（fl.*, pr.*, nw.*, fs.*, run, cmd.register） 可用资源: ~400MB 空闲存储, ~350MB 空闲内存 Day 1 — 用户: "帮我把这台设备变成一个家庭监控中心" ───────────────────────────────────────────────────── 大模型检测环境 → 安装依赖（flask, opencv）→ 编写监控脚本 → 注册指令 %监控% → 创建通知指令 %通知% → 创建人体检测指令 %人体检测% → 创建定时任务指令 %定时任务% 新增 5 个指令，总计 35 个 Day 7 — 用户: "帮我管理花园的浇灌" ───────────────────────────────────────────────────── 大模型创建: 湿度传感器读取、浇灌控制、天气集成、自动策略 新增 4 个指令，总计 39 个 Day 30 — 用户: "帮我做家庭能源管理" ───────────────────────────────────────────────────── 大模型创建: 电表读取、功率监控、用电分析、报表生成 新增 5 个指令，总计 44 个 Day 60 — 用户从社区安装了别人分享的指令包 ───────────────────────────────────────────────────── 导入: NAS管理, 媒体服务器, VPN配置, 智能家居桥接 新增 8 个指令，总计 52 个 Day 180 — 厂家 OTA 推送模型更新 ───────────────────────────────────────────────────── 模型更新: 嵌入了社区最热门的 200 个自定义指令的语义理解 模糊匹配准确率: 85% → 94% 本地 52 个指令 + 模型理解 252 种意图 ``` **生态增长曲线：** ``` 指令数 │ ╱ 社区共享 │ ╱ │ ╱────────╱ 用户创建 │ ╱ │ ╱ │ ──────────────────── 内置指令（固定） │ ╱ │╱ └────────────────────────────────────── 时间 出厂 1周 1月 3月 6月 1年 30 35 44 52 80 150+ ``` ### 5.4 生态共享机制 ``` ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 指令包格式: .agentpkg（tar.gz） │ │ ───────────────────────────── │ │ 包含: 指令元数据 + 脚本源码 + 依赖声明 + 测试环境快照 │ │ │ │ 共享方式: │ │ │ │ 1. 本地分享 │ │ 设备A 导出 → USB/蓝牙 → 设备B 2. 云端仓库 │ │ 类似 npm registry，但包是由 AI 创建的 │ │ 大模型可以搜索、安装、发布 │ │ │ │ 3. 厂家采纳 │ │ 社区热门指令被厂家审核后纳入内置指令集 │ │ 通过 OTA 推送到所有设备 │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` ### 5.5 特化小模型的自举训练 ``` 出厂时: 导入 │ │ │ │ 模型只理解 30 个内置指令 ───────────────────────────────── 通过注册表的别名索引，即时覆盖用户创建的指令 不需要重新训练模型，只更新向量索引 用户创建"监控" → 别名索引增加: "监控" → monitor.py "camera" → monitor.py "拍照" → monitor.py "看看家里" → monitor.py → 下次任何会话中说这些词都能命中 长期进化: ───────────────────────────────── 厂家收集社区最热门的自定义指令 合并到训练数据中 定期发布模型更新 → OTA 推送 每次更新，模型理解的指令范围更大 模糊匹配能力更强 ``` ### 5.6 不同硬件的自举路径 | 设备类型 | 典型配置 | 出厂指令重点 | 用户创建方向 | 模型大小 | |---------|---------|------------|------------|---------| | 路由器 | 128MB RAM | 网络诊断、流量、防火墙 | 广告屏蔽、VPN、异常报警 | 5MB | | NAS | 512MB RAM | 存储、用户、备份 | 照片分类、影视刮削、下载 | 15MB | | 工业网关 | 256MB RAM | 串口、Modbus、MQTT | PLC读写、数据转发、报警 | 8MB | | 智能音箱 | 1GB RAM | 语音、音量、WiFi | 闹钟、播客、智能家居 | 30MB | | 开发板 | 4GB RAM | 完整 Linux 命令集 | 几乎什么都能创建 | 80MB | | ESP32 | 520KB | GPIO、WiFi、BLE | 由网关代理创建 | 0（网关代理） | ### 5.7 AI 能替代开发者吗 ``` 能替代的部分（IoT/边缘场景中占比 > 90%）: ✅ 胶水代码（连接 API、格式转换、数据搬运） ✅ CRUD 操作（增删改查） ✅ 标准协议实现（HTTP、MQTT、Modbus） ✅ 配置文件生成 ✅ 简单业务逻辑 ✅ 脚本自动化（定时任务、监控报警） ✅ 硬件外设调用（GPIO、串口、I2C） 不能完全替代的部分（占比 < 10%）: ⚠️ 高性能算法（需要底层优化） ⚠️ 内核/驱动开发（需要硬件专业知识） ⚠️ 安全关键系统（需要形式化验证） ⚠️ 复杂架构设计（需要全局视野） 结论: AI 不能替代 Linux 内核开发者。 但 AI 可以替代 OpenWrt 社区 80% 的应用层贡献者。 对于一个只有 30 个内置命令的 IoT 设备， 用户需要的不是"更好的 ls"， 而是"帮我监控花园湿度并在干旱时自动浇水"。 这种东西，AI 现在就能写。 ``` ### 5.8 厂家只需做三件事 ``` ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 1. 硬件 + 精简 OS │ │ 能跑 Python/Node/Lua 的最小运行时 │ │ │ │ 2. 特化小模型（按硬件定制训练） │ │ 知道这个硬件能做什么、这个 OS 上的命令差异 │ │ 15-80MB │ │ │ │ 3. AgentShell 核心 │ │ 协议解析 + 命令映射 + 安全审计 + 指令注册表 + 云端连接 │ │ 2-5MB │ │ │ │ 之后的事情，全部由 AI + 用户完成: │ │ │ │ 用户说需求 → 有现成指令？直接执行 │ │ → 有社区包？安装后执行 │ │ → 都没有？AI 创建 → 注册 → 执行 → 分享 │ │ │ │ 生态就这样一圈一圈地长出来。 │ │ 厂家不需要养一个开发者社区。 │ │ 每个用户都是生态贡献者，而且用户甚至不需要会写代码。 │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` --- ## 第六章：Token 消耗精算 ### 6.1 测试场景 服务器性能排查任务，10 轮对话，涉及 18 次工具调用。 ### 6.2 逐项对比 | 消耗项 | 传统 Agent | AgentShell | 节省 | |--------|-----------|------------|------| | 系统提示词（×10轮） | 50------|-------|,000 | 4,000 | 46,000 | | 用户消息（×10轮） | 1,500 | 1,500 | 0 | | 模型指令输出（×18次） | 9,000 | 270 | 8,730 | | 执行结果（×18次） | 9,000 | 9,000 | 0 | | 模型文字回复（×10轮） | 3,000 | 3,000 | 0 | | **总计** | **72,500** | **17,770** | **54,730（ | ### 6.3 费用换算（GPT-4o 定价） | 规模 | 传统方案 | AgentShell | 年节省 | |------|---------|------------|--------| | 10 轮对话 | $0.249 |---------| | Open Interpreter | LLM 执行本地代码 | 55k+ | 大模型输出完整代码执行75.5%）** $0.065 | — | | 100 轮对话 | $2.49 | $0.65 | — | | 每日 1000 任务（10轮/任务） | $249/天 | $65/天 | **$67,000/年** | ### 6.4 更深层的节省 ``` Token 直接节省: ~75% 延迟节省: ~30-50%（输出更短，生成更快） 错误率降低: 指令格式极简，几乎不会出错 上下文利用率提升: 省下的空间变成更长的推理链 缓存命中率提升: 200 token 提示词几乎 100% 缓存命中 ``` --- ## 第七章：与现有项目对比 ### 7.1 相关项目概览 | 项目 | 定位 | Stars | 核心方式 | |------| | | LangChain | Agent 编排框架 | 100k+ | JSON Schema 工具描述 | | MCP (Anthropic) | 工具通信协议标准 | 10k+ | 标准化 JSON Schema | | ShellGPT | 自然语言转 shell | 10k+ | 每次调用云端翻译 | | gptme | 终端 AI 助手 | 3k+ | 代码块执行 | | fabric | 管道式 AI 工具 | 25k+ | 预定义 prompt 模板 | | AutoGPT | 自主 Agent | 170k+ | 自动分解执行 | ### 7.2 核心差异 | 维度 | Open Interpreter | LangChain | MCP | ShellGPT | AgentShell | |------|-----------------|-----------|-----|----------|------------| | 工具描述方式 | 代码块 ~100tok | JSON Schema ~200tok | JSON Schema ~200tok | 无（直接翻译） | **意图标记 ~12tok** | | 系统提示词 | ~2000 tok | ~3000 tok | ~2500 tok | ~500 tok | **~200 tok** | | 环境适配 | 大模型自己判断 | 大模型自己判断 | Server 处理 | 大模型自己判断 | **本地自动适配** | | 跨平台 | ❌ 需大模型适配 | ❌ 需大模型适配 | ⚠️ 每平台一个 Server | ❌ 需大模型适配 | **✅ 环境感知+模板** | | 指令复用 | ❌ 每次重新生成 | ⚠️ 可定义但无注册 | ⚠️ Server 提供固定 | ❌ 每次重新生成 | **✅ 注册后永久复需要接收每个工具的完整 JSON Schema，工具描述仍然消耗 tokens，每个 MCP Server 是一个独立进程，不解决环境适配和自进化问题。 AgentShell 的思路是"大模型根本不需要知道工具的细节，它只需要说意图，本地特化层来翻译"。 **Token 对比（10 个工具，10 轮对话）：** | 项目 | 系统提示词 | 工具调用 | 合计 | |------|-----------|---------|------| | MCP | ~30,000 tok | ~2,700 tok | ~32,700 tok | | AgentShell | ~2,000 tok | ~216 tok | ~2,216 tok | | 节省 | — | — | **93%** | ### 7.4 AgentShell 的独特优势 1. **意图标记协议**：没有现有项目使用这种极简格式，这是 token 消耗差距的根本原因 2. **本地命令特化层**：没有项目做"高层用** | | 自进化 | ❌ | ❌ | ❌ | ❌ | **✅ AI 创建+注册** | | 安全审计 | ⚠️ 基础 | ⚠️ 可配置 | ⚠️ Server 负责 | ❌ | **✅ 多层审计+沙箱** | | 边缘设备 | ❌ 太重 | ❌ 太重 | ❌ 需网络 | ❌ 依赖云端 | **✅ 5MB 起步** | | 最小 RAM | ~200MB | ~300MB | ~100MB/Server | ~50MB | **~5MB** | ### 7.3 与 MCP 的深度对比 MCP 是目前最接近我们想法的项目： **共同点：** - 都想标准化 LLM 与工具的通信 - 都认为工具调用不应该硬编码在 LLM 里 - 都支持工具的动态发现 **关键差异：** MCP 的思路是"定义标准接口，让工具提供方实现 MCP Server"。但这没有解决根本问题——LLM 仍然意图 → 平台原生命令"的自动翻译，一次适配所有意图受益 3. **指令自进化**：没有任何项目支持"大模型实时创建新工具并注册"，完整的创建→注册→复用→共享生命周期 4. **边缘设备原生支持**：没有项目考虑在 128MB RAM 的路由器上运行，我们从架构设计时就考虑了全谱系 5. **Token 经济性**：现有项目 30,000-80,000 tokens/10 轮，我们目标 < 15,000 tokens/10 轮 ### 7.5 竞争定位 ``` Token 效率 高 │ │ ★ AgentShell │ │ ★ ShellGPT │ │ ★ MCP │ │ ★ gptme │ │ ★ Open Interpreter │ │ ★ LangChain │ └────────────────────────────── 功能丰富度 低 高 定位: 高 Token 效率 + 中等功能丰富度 差异化: 别人拼功能，我们拼效率 长期: 功能通过自进化追上来，效率优势保持 ``` ### 7.6 风险与应对 | 风险 | 概率 | 影响 | 应对 | |------|------|------|------| | 大模型不理解意图标记格式 | 中 | 高 | few-shot 示例 + fallback JSON + 流式容错 | | 命令覆盖范围有限 | 高 | 中 | 自进化 + 云端回退 + 社区共享 + %run% 兜底 | | 安全漏洞（命令注入等） | 低 | 极高 | 四层审计 + 沙箱 + 渗透测试 | | 生态冷启动 | 高 | 中 | 兼容 MCP + 集成已有项目 + 聚焦垂直场景 | | 大模型创建的脚本质量不稳定 | 中 | 中 | 安全审计 + 脚本审查 + 用户确认机制 | --- ## 第八章：项目路线图 ### 8.1 版本规划 ``` v0.1 — Proof of Concept（第 1-4 周） 目标: 验证核心假设——意图标记格式可行 交付: 协议解析器 · 规则引擎（Linux, 30 指令）· 安全审计 沙箱执行器 · CLI 界面 · 与一个开源前端集成 验证: 10 轮 token 消耗 < 传统方案 30%，映射准确率 > 90% v0.2 — Multi-Platform（第 5-8 周） 目标: 扩展到多平台 交付: Alpine · macOS · Windows PowerShell 支持 环境自动检测 · 命令模板注册表（YAML）· 基础模糊匹配 v0.3 — Self-Evolution（第 9-14 周） 目标: 实现自进化核心 交付: 指令注册表 · 创建引导器 · 别名自动生成 云端回退机制 · 指令包导出/导入 · 在线学习 v0.4 — Smart Matching（第 15-20 周） 目标: 引入小模型提升匹配能力 交付: Embedding 意图匹配模型 · 命令翻译模型 训练数据集（~50,000 条）· 评测框架 v0.5 — Edge & Embedded（第 21-26 周） 目标: 支持边缘设备 交付: BusyBox/OpenWrt · Android Termux 纯规则版本（RAM < 5MB）· 远程执行 · 容器执行 v1.0 — Production Ready（第 27-34 周） 目标: 生产可用 交付: RESTful API · 多用户/权限 · 审计日志 · 监控 插件系统 · 完整文档 · Docker 镜像 · 包发布 ``` ### 8.2 团队配置 ``` 最小团队（3 人）: 后端/架构 1人 核心引擎、协议、安全 ML工程师 1人 小模型训练、数据管道 全栈/集成 1人 前端集成、CLI、文档 理想团队（5-6 人）: 架构师 1人 系统设计、协议定义 后端工程师 1人 引擎、执行器、安全 ML工程师 2人 模型训练、数据、评测 前端/集成 1人 UI、CLI、开源集成 安全工程师 1人 安全审计、渗透测试（可兼） ``` --- ## 第九章：关键决策记录 | 决策 | 理由 | 权衡 | |------|------|------| | 用意图标记而非 JSON | Token 节省 90%，大模型本来就知道命令语法 | 需要更复杂的解析器，值得 | | 规则引擎优先，模型辅助 | 边缘设备无 GPU，85% 场景确定性映射不需要模型 | 模糊指令受限，但有云端回退 | | 按平台分别训练模型 | Windows PS 和 Linux bash 语法差异太大，混合训练准确率下降 | 部署时需选择模型，可自动检测 | | 复用开源前端 | 对话管理是成熟问题，核心价值在特化层 | 依赖第三方，但降低开发成本 60%+ | | 支持云端回退+在线学习 | 本地不可能覆盖 100%，每次回退是学习机会 | 首次新场景有延迟，后续不再有 | | 指令自进化 | 生态不再依赖开发者，AI 实时创建 | 安全挑战增大，通过四层审计缓解 | --- ## 第十章：总结 ``` ┌─────────────────────────────────────────────────────────────────┐ │ │ │ AgentShell 做的事情可以概括为一句话: │ │ │ │ 把大模型从"工具说明书朗读者"解放为"指挥官"， │ │ 把环境适配交给本地的"参谋部"， │ │ 让软件生态由 AI 自行生长。 │ │ │ │ ───────────────────────────────────────────────────────────── │ │ │ │ 三个核心创新: │ │ │ │ 1. 意图标记协议 │ │ 大模型输出 %intent% $args$ 而非 JSON │ │ Token 消耗降低 75-80% │ │ │ │ 2. 本地命令特化层 │ │ 高层意图自动翻译为平台原生命令 │ │ 大模型无需知道 OS/Shell/运行时差异 │ │ 5MB RAM 起步，覆盖从 ESP32 到服务器 │ │ │ │ 3. 指令自进化 │ │ 大模型实时创建新指令并注册 │ │ 生态不再依赖开发者，由 AI + 用户共建 │ │ 厂家只需提供硬件 + OS + 小模型 + 核心框架 │ │ 剩下的，AI 来写。 │ │ │ │ ───────────────────────────────────────────────────────────── │ │ │ │ 类比: │ │ 传统 Agent = 功能手机，出厂装了什么就用什么 │ │ AgentShell = 智能手机 + 应用商店，但应用是 AI 实时写的 │ │ │ └─────────────────────────────────────────────────────────────────┘ ```