飞书远程操控，我做了入口+模型+权限三

我最近把飞书机器人接到了本机 Codex CLI 上。 刚开始用着挺爽，在飞书里发条消息，就能远程让本机 Codex 查状态、读文件、翻飞书文档、做总结。结果用了两天就发现问题了：飞书这边只是查个简单状态，它却默认把 Codex Desktop 的全局配置（GPT-5.5 + xhigh）给继承过来了。 这明显不合理。Desktop 是深度工作台，适合架构设计、复杂代码、长链路推理；飞书 Bot 则是远程轻量入口，适合查状态、看文档、抓网页、简单总结这些事。两个入口场景完全不同，却共用一套默认模型策略，体验自然就别扭。 后来我改了一下： 保留了 Codex Desktop 的全局配置不变，还是 GPT-5.5 + xhigh。 给飞书 bridge 单独建了个 Codex profile，用 GPT-5.3 Codex Spark + medium + fast。 通过 wrapper 把 bridge 调用 Codex 的入口管起来。 同时在飞书 /config 里把模型选项扩展成四个：GPT-5.3 Codex Spark、GPT-5.4 Mini、GPT-5.4、GPT-5.5。 这样 Desktop 继续干重活，飞书 Bot 默认走轻量路线。 我还给自己整了个好记的模型选择口诀：Spark 查、Mini 整、5.4 干、5.5 审。 查状态、查飞书、读文档就用 Spark；整理表格、改格式用 Mini；项目分析和小范围执行用 5.4；架构审查、安全审查、关键决策用 5.5。 不过这次改动里，最重要的其实不是模型切换，而是安全。 飞书 Bot 连着本机 Codex，而本机 Codex 有 full access。一句飞书消息，理论上就能触发文件修改、批量移动、安装依赖、Git 操作，甚至读敏感信息。我在 bridge 默认工作区加了 AGENTS.md，明确规定：删除、批量移动、安装依赖、登录授权、读取 Cookie、飞书写入、权限变更、Git push 这些动作，必须先问我确认。 这次最大的收获是： Agent 工作流不是简单把最强模型接进来就完事。真正要设计的是入口分层、模型分层、权限分层、回滚机制和验证闭环。否则自动化程度越高，风险反而越大。 AI Agent 的成熟度，不在于它能不能干大事，而在于它在不该干大事的时候，能不能被好好限制住。 #CodeX #飞书CLI教程 #Agent教程