ai-shell与龙虾结合

[fslong520]

建议ai-shell跟龙虾结合在一起，用户不光可以用aishell当作默认shell。
还可以启动龙虾模式，出门做事的时候再用手机安排电脑干活。
现在钉钉都在cli化了，ai shell更适合做这种事情。
参考codebuddy的/gateway模式：

[guanzi008]

来自ai 解说
**“ai-shell 控制龙虾”**的控制思路，尽量做成能落地的。原讨论里的诉求是：用户平时把 ai-shell 当默认 shell，用到外出场景时再切到“龙虾模式”，通过手机安排电脑继续干活。(GitHub)

一句话架构：
手机/IM 入口 → ai-shell 网关层 → 任务编排层 → 龙虾执行层 → 结果回传层

可以把“龙虾”理解成 远程执行能力，把 ai-shell 理解成 统一控制中枢。

---

1. 控制分层

A. 入口层

负责接收用户命令：

• 手机网页
• App
• 钉钉 / Telegram / 企业微信
• 未来也可以接语音

这里用户发的不是纯 shell 命令，而是：

• “帮我把项目编译一下”
• “跑一下测试并把失败项总结给我”
• “把下载目录里今天的 PDF 整理到 docs”

也可以保留高级模式，允许直接发命令，但默认不暴露。

---

B. ai-shell 网关层

这是核心。

它做 4 件事：

1. 鉴权

   • 确认是不是你本人手机
   • 设备绑定 + token + 二次确认

2. 意图解析

   • 自然语言转任务
   • 判断是“查询类”还是“执行类”

3. 任务路由

   • 这个请求该交给哪个 workflow
   • 是本机执行、远程机执行，还是仅返回建议

4. 风险拦截

   • 危险命令先拦住
   • 删除、覆盖、联网发布、git push 之类必须确认

所以这里不是“手机直接打 shell”，而是手机先控制 ai-shell，ai-shell 再决定怎么调龙虾去执行。

---

C. 任务编排层

这一层不要直接让用户碰命令，而是先抽象成任务模板。

比如：

• build_project
• run_tests
• summarize_logs
• organize_downloads
• deploy_preview
• search_codebase

每个任务模板内部再映射为一组 shell / script / agent steps。

例如：

run_tests

• 拉最新代码
• 安装依赖
• 执行测试
• 收集失败日志
• 用 AI 总结失败原因
• 把结果回给手机

这样用户说的是“做事”，不是“敲命令”。

---

D. 龙虾执行层

这一层只负责执行，不负责理解。

它可以是：

• 本机 agent
• 家里电脑上的 agent
• 办公机上的 agent
• 一台专门跑任务的 Linux 主机

它做的事很简单：

• 接收任务
• 执行 workflow
• 回传 stdout / stderr / 产物 / 状态

所以“龙虾”最好做成 worker / runner，而不是主控端。

---

E. 结果回传层

回传不要只给原始日志，要分三层：

1. 状态

   • 排队中
   • 执行中
   • 已完成
   • 失败

2. 摘要

   • 编译失败，原因是缺少环境变量
   • 测试 128 个，通过 121，失败 7

3. 详情

   • 完整日志
   • 文件下载链接
   • 可继续追问

这样手机端才好用。

---

2. 推荐控制流程

你可以设计成下面这条链：

用户手机发请求
→ ai-shell 判断意图
→ 命中任务模板
→ 生成执行计划
→ 风险检查
→ 下发给龙虾 worker
→ worker 执行
→ ai-shell 总结结果
→ 回传手机

例如：

用户说：
“把 aish 项目拉最新代码，跑测试，失败了给我总结。”

系统内部变成：

• task: run_tests
• repo: aish
• branch: main
• post_action: summarize_if_failed

再由龙虾执行：

• git pull
• pnpm install
• pnpm test
• collect logs
• ai summarize

最后回手机：

测试已完成。共 96 项，通过 91，失败 5。
主要失败集中在 CLI 参数解析和 Windows 路径兼容。

---

3. 最重要的控制原则

原则 1：ai-shell 负责“理解和决策”

它是大脑。

原则 2：龙虾负责“执行和回传”

它是手脚。

原则 3：用户默认操作“任务”，不是“命令”

这样更安全，也更适合手机端。

原则 4：高风险动作必须确认

比如：

• rm -rf
• 覆盖系统文件
• 发邮件
• 发布部署
• 推送 git
• 执行外网脚本

---

4. 最小可用版本

先别一上来做全功能，最小版只做这 5 个能力：

1. 手机发任务
2. ai-shell 做鉴权和解析
3. 只支持少量白名单任务
4. 龙虾在电脑端执行
5. 返回摘要 + 完整日志

首批只开放这几类任务就够了：

• 跑测试
• 编译项目
• 查日志
• 整理文件
• 查机器状态

这样最容易先跑通。

---

5. 你可以怎么定义“谁控制谁”

我建议你就用这句话来定：

ai-shell 是控制面（control plane），龙虾是执行面（data/execution plane）。

也就是：

• ai-shell 发号施令
• 龙虾 具体干活

这样定位最清楚，也最容易设计产品边界。

如果你愿意，我可以直接把这个思路整理成一段适合发在那个 GitHub Discussion 里的回复文案。