这次升级回答的问题#

上一版（架构全解）里，为了安全，线上 pi 关闭了通用写工具，只保留业务工具。这带来两个限制：

• 助手不能在服务器上直接执行命令、读写文件，很多运维类任务只能「给出命令让你自己跑」；
• 不同来源的任务（手机、cron、gateway 直连）各自调用会话，多个任务可能混进同一个 agent run，工具结果的归属会串。

这次升级分别解决这两点。

一、full 工具集#

线上 pi 现在激活完整的工具集合：

• 原生工具：read、bash、edit、write、grep、find、ls
• 业务工具：email_*、blog_*、memory_*、rss_*、task_update、request_confirm

工具选择由 ASSISTANT_TOOL_PROFILE 控制：源码默认 full，保留 business 作为回退（read + 全部业务工具，近似原先的只读语义）；未知取值直接启动报错，不静默回退。

一条必须如实说明的边界：full 之下，通用 bash/write/edit 在同一账号权限内，理论上可以绕过邮件/博客的专用确认链去直接改文件或执行命令。字符串黑名单挡不住 bash -c、解释器、子进程这类绕过，所以这里不宣称提供这种保证。专用外发确认链本身并没有取消——email_send/blog_deploy 仍由宿主按轮次、目标、最终正文逐项校验，二者是并列而非互斥的安全机制。

二、统一任务入口#

新增按 session 共享的 SessionMessageDispatcher，把 daemon 的所有唤醒路径串行化：

• 同一 session 的消息严格 FIFO，不同 session 互不阻塞；
• 任务先 waitForIdle 再 prompt，执行期才设置 taskId/confirmId 上下文，任务结束清空；
• gateway 原来的 POST /task 直连，也通过宿主消息桥接入同一条队列；
• confirmId 只进入宿主上下文与观察，不构成任何外发授权。

这样不同任务不再混进同一个 agent run，工具结果的归属清晰可查。

三、确认链不变#

升级不改变最重要的那条纪律：发送邮件、发布博客这类对外可见的动作，必须先经用户在手机页确认；未收到确认前，绝不调用 email_send / blog_deploy。 确认按轮次计，改稿后重新请求确认会换发新的 confirmId，旧轮次立即失效，保证发出去的一定是用户最后看到的那一版。

当前状态#

• 线上：服务于 2026-10-10 18:30:32 CST 重启，日志确认 tool profile full 与 gateway ready。
• 代码基线：411ef36。

结语#

这次升级的核心不是「助手能做的事更多了」，而是把「能力」和「边界」分开：能力上放开到全量工具，边界上仍然守住「外发动作必须先由人确认」。工具越强，越要把不可逆的动作压到那一次确认上。