夜雨聆风
真正让人怕的，不是 AI 不够强。
而是它已经越来越能干了，但很多时候还不够可控。
插件能直接调工具、消息能跨渠道乱飞、同一个会话在不同入口里看到的工具面不一致、长消息一拆就炸、老配置悄悄被迁移，最后出问题时你甚至不知道是哪一层在背刺你。
这就是为什么我看完 OpenClaw v2026.3.28的 release notes 后，第一反应不是“又加了多少新能力”，而是：
OpenClaw 终于开始认真补“Agent 治理层”了。
这次最值得看的，不是模型，不是 UI，也不是哪个新插件。
而是三个字：可控性。
先说结论：这不是炫技版更新，是“兜底版”更新
OpenClaw 2026.3.28官方 release 里最重要的变化，集中在三类：
- 审批前置
插件现在可以在真正调用工具前，异步要求人工批准。 - 路由和入口一致性
当前会话、当前聊天、当前 workspace 到底绑的是谁，开始被更明确地处理。 - 渠道层的稳定性修补
Telegram、Discord、Teams、CLI、OpenAI 兼容后端，这些最容易让用户“体感翻车”的边角都在补。
如果你前几个月一直在用 OpenClaw，你应该能感受到一个趋势：
早期版本在拼“能不能做更多事”。
到了这几版，团队明显开始转向另一个问题：
当 Agent 能做更多事之后，怎么避免它在真实工作流里变得不可预测。
这件事，比再多接一个模型重要。
第一件大事：插件也要先批后干了
这次 release 里，我最看重的是这条：
Plugins/hooks: add async requireApproval to before_tool_call hooks...
翻译成人话就是：
插件现在也能在工具真正执行之前停下来，要求用户先批准。
而且这个批准不是只在某一个界面里弹个窗了事，而是已经打通到了多个入口：
exec approval overlay Telegram buttons Discord interactions /approve命令
这意味着什么？
意味着 OpenClaw 终于开始把“插件能力”也纳入和 exec 一样的治理框架里。
以前很多系统最大的问题是：表面上你对命令执行有审批，实际上插件作为另一层能力入口，反而可能绕过这套控制。
这很危险。
因为从用户角度看，都是“Agent 在替我做事”；但从系统角度看，exec、plugin hook、channel action 往往分属不同路径。只要其中一条路径管得松，整个系统的安全边界就会变得很虚。
OpenClaw 3.28 这步的价值在于：
它开始承认，真正的 Agent 治理不能只盯 shell 命令，插件同样要进审批链。
这不是一个“增强功能”，这是在补制度。
第二件大事：同一个会话，终于更像“同一个会话”了
另一个很值得看的是 ACP 和渠道绑定相关的更新。
官方写了这条：
ACP/channels: add current-conversation ACP binds for Discord, BlueBubbles, and iMessage...
对应的意思是：
现在你可以把当前聊天直接绑成一个 ACP workspace，而不是永远额外开子线程、开子上下文、再猜到底哪个会话才是“现在这次工作”。
同时，fix 里还有一批相关改动：
复用 session workspace 构建 HTTP /tools/invoke工具列表Gateway-backed channel MCP bridge 更安全的 stdio bridge 生命周期处理 路由、恢复、重连时的 workspace / session 发现更稳
为什么这些改动重要？
因为很多 Agent 系统最让人崩溃的，不是模型笨，而是：
同一个 agent，在 A 界面能用工具，在 B 界面突然没了 你以为回复会回到当前会话，结果跑到别的地方 当前聊天和真正执行任务的 workspace 根本不是同一个东西
这种体验最伤信任。
用户不会说“这里是 session-key 设计不一致”。用户只会说一句：
这玩意怎么神神叨叨的。
OpenClaw 3.28 的方向很明确：
同一个会话，应该尽量讲同一种真话。
如果工具能用，就该在各入口里一致可见。如果任务绑的是当前聊天，就该明确落在当前聊天。如果回复该回这个渠道，就别飞去别处。
这类改动非常“基础设施”，但它决定了系统能不能长期用。
第三件大事：Telegram 这种“体感层”终于被认真修了
这次 fix 里，有三条 Telegram 相关更新特别典型：
- 长消息拆分更稳
不再按粗糙比例估算长度，而是按实际 HTML 长度验证，避免半个词被切断。 - 空白消息不再炸
whitespace-only 或 hook 清空后的文本，不再触发 Telegram 400 空消息错误。 - replyToMessageId 全面校验
对四个 API sink 统一校验，拒绝非数字、NaN、混合字符串。
这些修复很“细”，但特别像真实产品维护。
因为 Telegram 这类渠道的麻烦，不在 demo，而在日常：
一条长回复刚好超限 一个 hook 把正文裁空了 一个 reply id 格式不标准
用户不会关心你底层是哪个 transport。
用户只会看到：
“怎么这条没发出去？” “怎么又报错？” “怎么一半中文被截断了？”
所以我一直觉得，渠道层修复是 Agent 产品成熟度最诚实的指标之一。
你愿不愿意修这些烦人的边角，决定了你到底是在做一个 demo，还是在做一个每天真会被人用的系统。
但这次升级也不是“闭眼升”
3.28 里有两个 breaking change，值得提前说清楚。
1. Qwen 老 OAuth 路线被移除了
官方直接移除了 portal.qwen.ai旧的 qwen-portal-auth集成，要求迁到 Model Studio：
openclaw onboard --auth-choice modelstudio-api-key如果你还在走旧 Qwen Portal 的认证方式，这不是可选升级，是必须迁移。
2. 两个月前的老配置，不再自动帮你洗白
官方把“自动迁移超老旧配置”的逻辑砍掉了。
这意味着非常老的 legacy key 现在可能直接校验失败，而不是像以前一样在加载时偷偷帮你改掉。
我反而觉得这方向是对的。
自动迁移看起来贴心，但一旦系统越来越复杂，它也会制造另一种不透明：
你不知道配置到底什么时候被改了 你不知道现在生效的是新键还是旧键 你出了问题，很难复盘
所以这次选择“老配置直接报错、让人显式修”，虽然短期更硬，但长期更健康。
谁应该立刻升级，谁应该先看一眼
建议立刻升级的人
你在用 Telegram、Discord、Teams、Matrix 这类渠道做实际交付 你依赖插件、审批、跨入口工作流 你已经把 OpenClaw 当成日常系统，而不是偶尔玩玩
这类人最能吃到 3.28 的价值，因为它修的都是“每天会踩”的问题。
升级前先做检查的人
你还在用老 Qwen Portal 认证 你项目里留着很久以前的 legacy config key 你对现网配置来源已经不太有把握
这类人升级前先跑一遍：
openclaw doctor openclaw config schema再决定怎么迁。
最实用的升级动作
openclaw update openclaw gateway restart openclaw doctor如果你用的是 Qwen 旧接法，再补这步：
openclaw onboard --auth-choice modelstudio-api-key我的判断
OpenClaw 3.28 真正重要的，不是“又会干更多活”。
而是它开始认真回答一个更难的问题：
当 Agent 越来越强，怎么让它别失控。
审批前置、入口一致性、渠道修补、老配置显式失败，这些改动有一个共同指向：
OpenClaw 正在从“功能很多的 Agent 工具”，往“可治理的 Agent 基础设施”走。
这条路短期不一定最炫。
因为它修的往往不是 screenshot feature，而是那些用户只会在坏掉时注意到的无聊地方。
但我越来越确定，2026 年 AI Agent 的真正分水岭，不是谁工具多一把，谁模型强 3 分。
而是谁能把这些“无聊但关键”的层补齐：
该批的先批 该显式的显式 该一致的保持一致 该回哪儿的就回哪儿
这才是能长期用的系统。
我的判断很直接：
OpenClaw 3.28 不是最 flashy 的版本，但它很可能是更像“生产系统”的版本。
你更在意 Agent 更能干，还是更可控？评论区聊聊。
