2025 年，一家台湾中型电商的行销团队有五个人，轮班管理三个社群帐号。密码存在一张共用的Google 试算表里，每个人都有存取权。没有人觉得这有什么问题，直到他们决定导入AI Agent 来自动发文。

第一个直觉是：「把帐密给Agent 就好了。」

这个直觉，几乎每一家开始用AI 的企业都会有。而它几乎都是错的。

训练Agent 之前，先问一个问题

大多数人谈AI Agent，谈的是能力：它能搜寻吗？能写报告吗？能串接哪些工具？这些问题都对，但都是第二顺位的问题。

第一顺位的问题是：这个Agent，被允许做什么？不被允许做什么？当它做了不该做的事，责任落在哪里？

这不是技术问题，是治理问题。而企业在设计Agent 的时候，90% 的注意力都花在前者，几乎没有人在想后者。

没有授权边界的Agent，能力越强越危险。一个什么都能做的助理，和一个随时可能失控的漏洞，在系统架构上其实没有本质差异。

这正是SPEAK 框架诞生的起点。

• 【小】 专业技能 技能
• 【P】性格 特质
• 【E】体验 经验
• [一]权威 授权
• 【K】知识库 知识

五个维度里，S、P、E、K 都在描述Agent是什么、懂什么、能做什么。只有A 【Authority】在回答一个完全不同的问题：它被允许走到哪里为止。

「你给Agent 的每一项授权，都是一扇打开的门。问题不是门打开了多少，而是你知不知道哪些门永远不该开。」

密码的物理隔离：流程代理的逻辑

回到那家电商的故事。他们最后没有把社群帐密交给Agent。

他们做的事情更聪明：Agent 只被授权触发发布流程，而不是执行发布动作本身。当Agent 决定要发一篇贴文，它做的事是把内容和时间传入Make.com的一个场景流程，由Make 在背后用真实帐密完成登入与发文。

整个流程的授权链是这样的：

Agent（知道要发什么）→触发Make 场景（知道怎么发）→ Make 持有帐密（有权限发）

Agent 全程碰不到密码。它不知道密码是什么，也不需要知道。

这个设计的本质，是企业安全架构里几十年前就存在的原则：最小权限原则（Principle of Least Privilege）。每个角色只被授予完成工作所需的最小权限，不多给一分。

银行系统、医院资讯系统、政府资料库，它们都是这样设计的。但在AI Agent 的世界里，这个原则几乎被遗忘了，因为大家都急着让Agent「更强大」。

智働话的核心命题是：AI 不是来取代人的，而是来协作的。但协作有前提，每个参与者都要清楚自己的职责边界。给Agent 无限授权，不是信任，是失职。

双层金钥：当技能本身也需要授权

流程隔离解决了「操作层」的安全问题，但还有另一个问题：技能本身，要怎么授权？

在Smart4A 的Agent 职训中心平台（speak.smart4a.tw）里，每一项技能都是加密的。主机端用AES 加密储存技能内容；用户端必须在本机持有对应的解密金钥，才能解锁使用。

这创造了一个优雅的安全结构：技能不是「下载」来的，而是「解锁」来的。平台知道你有资格使用，你的本机金钥确认你是本人，两者缺一不可。

对企业主来说，这个设计的好处不是技术上的，而是心理上的：你不需要懂AES 是什么，你只需要保管好你的金钥。复杂的安全逻辑由平台承担，你承担的只有最后一把钥匙。

这让我想到保险箱的设计哲学：最好的保险箱不是让用户理解它的锁芯构造，而是让用户只需要记住一组密码，其他都由机械结构保护。 SPEAK 的授权层，做的是同一件事。

金流的边界：不是拒绝，是加一道人的关卡

那么，有没有什么场景是Agent 可以触发流程，但不能独自完成的？

答案是有的。金流，是最典型的例子。

对帐、请款、甚至部分汇款流程，Agent 可以启动、可以整理资料、可以带入数字，但在流程的某个关键节点，必须有人确认才能继续。这就是Human-in-the-Loop（HITL）的设计逻辑。

HITL 设计原则

Agent 触发流程，但流程在执行之前会暂停，等待人工审核与放行。资金不会在没有人确认的情况下移动。 Agent 的角色是准备与提醒，决策权留在人的手上——这不是技术限制，是刻意为之的治理设计。

HITL 不是不信任AI，而是承认有些决策的后果不可逆。一旦出错，没有撤回键。金流挪用、帐款错付，任何一个环节的失误都可能造成无法弥补的损失。在这种场景下，让人保持在回路里，是授权设计最负责任的选择。

Authority 的成熟形式不是二元的「给」或「不给」，而是设计一条有层次的授权链：Agent 可以走到哪一步、哪一步需要人工确认、哪一步只有特定角色才能放行。这才是企业级AI 治理真正的样子。

一部好的宪法，不只写明谁有什么权力，也写明哪些权力必须经过制衡才能行使。你的Agent 授权架构，也应该如此。

SPEAK 的真正顺序

如果你正在规划企业AI Agent，SPEAK 给你一个反直觉的建议：不要从S 开始，要从A 开始。

先问：这个Agent 被允许接触哪些系统？哪些帐密永远不该落地到Agent 手中？哪些操作必须保留人工确认？有没有一条你无论如何都不会跨过的红线？

把这些问题回答清楚，你的Agent 才有资格开始学技能、建立个性、累积经验、吸收知识。

否则，你训练出来的不是助理，是一个随时可能失控的漏洞。只是它说话很有礼貌，你暂时还没发现问题在哪里。

智働话的核心不是用AI 取代人的工作，而是重新定义人与AI 各自该负责什么。授权设计，就是这道边界最具体的体现。

那家电商的行销团队，最后建了一个干净的Agent 架构：Agent 负责内容生成与排程判断，Make 负责执行与帐密管理，人负责最终的发布决策与金流操作。三层分工，各司其职。

他们说，导入之后最大的感受不是「AI 帮我省了多少时间」，而是：「第一次感觉我们的系统是有设计过的。」

这才是SPEAK框架想要带给每个企业的东西。