E002 · 已有建议 · 2026年11月13日

助理机器人
架构

原始记录

来源、收到日期和原话

深入分析

证据、对比和深入分析

建议

结论、工作量和建议的第一步

E002 建议

状态：recommended
对照基线：agent24 bc923205
分析：深入分析

结论

可以朝 Grok Bot 式助理演进，但不要把文中任何一个仓库嵌进 agent24。现有的 run、审批、调度、MCP 和记忆已经盖住闭环的一半。最大的洞是「一个有名字的 Bot」以及它自己的例行任务不能绕过审批。电脑沙箱、多通道和页面先不做。

缺口	向谁学	怎么借
持久 Bot（记忆、对话、例行任务绑在一起）	Rakazo	只借记录形状。不引入 Postgres 和 Graphile
例行任务不能放宽审批	Suparagent	只借规则：调度触发的 run 使用更严的审批，不能更松
队长把活分给专长代理	Suparagent	设计。先不要多进程团队
渠道（Slack、邮件）	OpenTeam 的插件清单	不复制 GPL 代码。仿微信桥再做一条能真正回复的通道
每人一台电脑和浏览器	Rakazo、OpenTeam	先不借。现有 shell 加审批不够，但上 Docker 电脑是另一项大工程
关掉审批的桌面队友	Nightly OpenBot	不借。非商业许可，且文档允许初次同意后不再询问

值不值得借

判断：partly
原因：助理服务需要的是 Bot 这个产品对象，不是再换一个 Agent 运行时。agent24 的循环、审批和 cron 已经在。文中仓库的运行时、许可证或账户共享模型和 agent24 对不上。

当前架构是否撑得住

判断：部分支持
证据：调度在 rust/crates/agent24-scheduler/src/lib.rs 开头。审批在 rust/crates/agent24-policy/src/lib.rs 的 ApprovalBroker。记忆召回是 FTS，见 rust/crates/agent24-agent/src/session_memory.rs。微信只把入站记下来并回复「已记录」，见 packages/wechat-bridge/src/bridge.ts。
缺的缝：没有 Bot 表把记忆范围、schedule 和通道绑在一起。调度触发的 run 仍走普通工具门，没有「例行任务不得放宽」这条规则。没有持久浏览器电脑。

演进步骤

增加 Bot 记录：所有者、记忆范围、允许的工具集、关联的 schedule id。不新写循环。
调度起来的 run 带上 Bot 的审批上限，测试证明它不能把 shell_exec 调成免审批。
选一条通道做真实回复。不要同时做 Slack、邮件和微信。
电脑沙箱单独立项。没过前两步不开工。

工作量

规模：L（到一条能回复的通道）。只做 Bot 加审批上限是 M。
人日：Bot 记录约 4 到 6。审批上限约 3 到 5。一条通道约 8 到 12。电脑沙箱另计，超过 15，本次不排。
主要工作在：agent24-store 的新表、agent24-scheduler 与 ApprovalBroker 的交界。不替换 run_loop。

产品与用户影响

好处：用户得到一个会记住、会按时做事、做事仍要确认的本机助理。
代价：多一个要备份的对象。例行任务变严之后，以前指望「定时就自动跑完」的用法会停下来等人。

风险

正确性或安全：若例行任务继承会话级免审批，定时任务会在无人看管时执行 shell。OpenTeam 把登录态分给所有 Bot，agent24 不能学。
交付：CopilotKit 的 MIT 仓库解决不了 Intelligence 的另行授权。OpenMausBot 的 enterprise/ 不是 Apache-2.0。
不做的风险：调度、记忆和微信桥继续是三块拼起来的能力，用户看不到一个助理。

建议的第一步

写一个测试：某个 schedule 绑定到一个 Bot，Bot 的审批上限是「必须问」。触发后的 shell_exec 仍然进入 ApprovalBroker，不能因为是定时任务就执行。现有的手动 run 审批行为保持不变。