新加坡 AI Agents Sandbox：真正的产出是一份采购规格书

把新加坡政府与 Google 的 AI Agents Sandbox 当成一条产业合作新闻，会错过它真正的产出。它交付的核心不是一套软件，而是一组采购问题：当会自行动作的软件进入公共服务，应先证明哪些失败会发生、权限到哪里为止、每一步留下什么记录、由谁批准放行。这几个问题连起来，就是一份可以照着执行的验收标准——尽管它并不以标准的形式出现。

这里要先把事实说准，以免把结论架空。新加坡网络安全局(CSA)在 2026 年 5 月 20 日的公开说明，给出的是沙盒测试中的发现与治理启发，并没有对外发布一份正式的采购规格书。把这些发现读成一份采购标准，是买方要自己完成的一层翻译：CSA 报告的是「我们观察到了什么风险、试了哪些控制」，而采购方要问的是「照这个，我该向供应商索取什么证据、在什么条件下拒收」。这层翻译不是文字游戏，它决定了同一份公开材料在不同人手里是新闻还是工具。

也正因为公开材料只到「发现」为止，它的价值恰恰来自诚实。到目前为止，没有任何一项公共服务被智能体自动接管的成效数据被公布；报告谈的是测试场景里的表现、暴露出的失败模式，以及仍然没搞清楚的地方。一份坦白承认「还不知道什么」的材料，比一份宣称「已经跑通」的成功案例更适合当采购依据——因为采购真正要防的，从来是那些还没被人写进 PPT 的失败，而不是已经被演示过的成功。

这条新闻真正的分量，在于它标记了较量重心的移动。过去两年，智能体的比拼几乎全在能力一侧：上下文长度、工具调用成功率、多步任务的完成度。沙盒把话题拽到另一侧——一个智能体能证明自己被控制到什么程度，第一次有了可以对照的公共样本。对采购方而言，这意味着评估语言要换一套：除了问「它能不能做完这件事」，更要能追问「它做这件事时，会在哪一步失手、失手能不能被发现、发现之后谁来收拾」。

对任何正在评估把智能体接进真实流程的团队，这份清单是眼下能拿到的最实用的东西。它给出的是一张问责地图的骨架，而非一份模型排行榜：把「智能体好不好」这个模糊的问题，拆成数据、权限、日志、批准、责任几条可以逐项检查的边界。后面几节会把这张骨架填满，但先记住这一点：沙盒最先交付的，是一套向供应商提问的方式，而这套提问方式独立于任何一家供应商的产品。

沙盒是一套被验证过的制度打法的延续，而非临时起意。新加坡是最早把「监管沙盒」做成正式制度、再被各国借去用的那个国家：在金融科技上，新加坡金管局(MAS)早年就用受控边界内的试点，换取「先看清风险、再决定是否放开」的空间，这套做法后来被英国、澳大利亚、香港等多个司法辖区引用。把同一套制度逻辑从金融科技平移到 agentic AI，是一个有迹可循的选择，而不是一次公关动作。

这套打法的内核，是把不确定性关进一个可以承受的盒子里。直接在生产环境里放开一个会点按钮、填表单的智能体，风险不可控；完全不试，又会在能力快速迭代时失去判断依据。监管沙盒的价值在于制造第三个选项：在划定边界、可回滚、有人盯着的条件下运行，用有限的暴露换取真实的观察。金融科技时代它换来的是对新支付、新借贷模式的监管理解；这一次，它要换的是对 computer-use 智能体在公共流程里如何失败的理解。

值得一并记下的是背景规模。Google 在同一天还公布了更广泛的新加坡 AI 合作计划，沙盒只是其中一块。孤立地看沙盒，会低估它的定位——它更像一次有意为之的标准制定动作，产业合作是外层包装。新加坡在这里争取的位置，是为一类全行业都在竞逐的 computer-use 智能体，公开地积累一套采购与问责的语言，而不只是又添一个应用现场。一个体量不大的经济体，靠制度先发去占标准位置，这在它的政策史里是反复出现的模式。

把它读成标准制定，而非应用示范，会改变对它的判断权重。如果这是应用示范，评估它就该看接管了多少业务、省了多少人力——而这些数据目前并不存在，于是新闻显得单薄。如果这是标准制定，评估它就该看它是否产出了可迁移、独立于厂商的问法——而这一点，公开材料是站得住的。判断一个动作的分量，要用它自己想争取的坐标系去量，而不是套一个它没打算参加的比赛。

这里也埋着一个可以观察的验证点与反证信号。如果这套沙盒逻辑真的在扮演标准制定者，未来一到两年里应该能看到它的问法被写进他国或区域组织的采购与治理文本；如果两年后除了新加坡本地，几乎没有别的买方在招标里复用这套语言，那就说明它更接近一次本地试验，而非区域标准的起点。触发它成为标准的条件，是区域内买方的采购能力同步成熟；缺了这个，再好的问法也传不出去。

清单一旦存在，握有筹码的就不只是能造出智能体的供应商，还包括读得懂证据的买方——但要注意，是「读得懂」，不是「拿得到」。过去采购软件，评估维度是功能、价格与安全认证，这些东西相对标准化，买方即便不懂底层实现，也能靠认证和口碑做决策。采购一个会行动的智能体，要看的是失败分类、权限模型、日志字段、人工批准点、上线后的监测——这些东西没有现成的认证可依，必须由采购方自己读懂并判断。

这就造出了一种新的稀缺：会读证据的采购。能生产这些证据的供应商拿到差异化，这一层比较直白；但能把风险真正挡在部署之前的，是那些既懂得索取证据、又分得清一份真实运行日志和一份精选合规文档的买方。一份精心裁剪过的合规文档，可以让所有指标看起来都达标，却回避了最难看的失败场景；一份真实日志会暴露智能体在哪一步犹豫、在哪一步被环境带偏。分辨这两者需要专业判断，而这种判断在今天的采购团队里普遍不足。

所以这份清单不会自动把议价权交回买方，这一点要说清楚，否则容易滑向一种乐观的误读。它造出的是一种能力的稀缺，而稀缺能力从来只惠及先具备它的少数人。今天绝大多数采购流程仍停在看演示、比报价的阶段；能把这四类证据写进招标书、并且看得懂供应商回标的团队还很少。先具备这种能力的买方，吃到的是别人还看不懂时的时间差——他们能以更低的风险，买到别人不敢碰或看不清的东西。

把这层不对称落到具体动作上，采购方值得立刻做的一件事，是重写自己的评估表。旧表上写的是「支持哪些功能、通过哪些认证、报价多少」；新表上要加的是「能否提供分场景的失败分类、权限是否可按动作粒度收紧、日志是否覆盖每一次工具调用与人工接管、责任如何在合同里分配」。这张表本身不复杂，难的是拿到回标之后有人能读懂——一张各栏都填满的表，若没人能验证背后的真实性，反而会给出虚假的安全感。

这也解释了为什么「时间差」是可控但会收窄的机会，而不是一劳永逸的护城河。触发它转化为真实优势的条件，是买方在拿到证据后能独立复核；它的反证信号也很明确——如果市面上出现了成熟的第三方评测与认证机制，把「读懂证据」这件事标准化、外包化，那么先行买方的判断力优势就会被迅速抹平。在那之前，读证据的能力是稀缺的；之后，它会变成又一项可采购的服务。

要理解控制为什么非有不可，得先看清智能体到底改变了什么。CSA 与 IMDA 的材料聚焦的是 computer-use agents——能通过电脑或浏览器界面执行任务的智能体，而不是停在对话框里的问答助手。这个区分是全部分析的地基：两类系统的风险位置根本不在一层。

问答助手的风险停在文本层。它的输出是文字，评估维度是答案准不准、有没有偏见、会不会泄露训练数据或上下文里的敏感信息。这些风险都可怕，但它们有一个共同特征：风险停留在「它说了什么」，而说出来的东西，在被人采纳之前不会改变任何系统状态。人还站在文本和行动之间，充当天然的过滤层。

computer-use 智能体把风险推过了这道过滤层，推进了行动链路。当系统能读网页、点按钮、填字段、跨页面把一件事做完，要审的就不再是它说了什么，而是它做了什么、改了什么状态、以及底层系统撤不撤得回。这是一次性质的跳变：输出从「建议」变成了「已执行的动作」，而已执行的动作可能已经提交了一份表单、改写了一条记录、触发了一个下游流程。

「撤不撤得回」这件事，还常被高估。智能体是在 UI 层操作的，它点的是人也在点的那个按钮；而一个政府或企业的遗留系统里，一次表单提交往往是非幂等的、没有原生撤销接口的操作。也就是说，能不能回滚，多半不由智能体决定，而取决于底层事务本身有没有撤销能力。指望在智能体这一层加一个「撤回」按钮就能兜底，是一种常见的错觉——真正能兜底的，是底层系统的事务设计，而这恰恰是大多数遗留系统最薄弱的地方。

正因为回滚不可靠，限权在工程上往往比支持撤回更实在。与其让智能体拥有提交权、再指望出错后能撤回，不如一开始就把它的权限收在「只读、只建议」的范围里，把不可逆的动作留给人。这样做是对底层系统能力的诚实承认。对正在设计这类系统的技术负责人，一条可直接采用的判断规则是：凡是底层不支持幂等或原生撤销的动作，默认不授予智能体执行权，除非在其前面焊上一个强制的人工批准点。

在所有已知失败里，最能说明行动链风险的是间接提示注入(indirect prompt injection)，CSA 把它列为沙盒观察到的共同风险之一。它的机制很朴素却很致命：一个 computer-use 智能体去读一个网页，网页里藏着一句指令，智能体把这句话当成了自己的任务去执行——于是它做出的，是页面作者想要的动作，而非委派它的机构想要的动作。整条攻击不需要突破任何系统权限，它借的正是智能体被授予的正常访问能力。

它难防，恰恰因为访问外部内容本身就是智能体的工作。防传统的跨站脚本(XSS)，可以在信任边界上对外部输入做消毒，因为「外部输入」和「可信指令」在架构上是分开的两类数据。但对一个要读网页才能完成任务的智能体，外部内容就是它的输入，消毒无从下手——你没法在不切断它工作能力的前提下，把它读到的所有文字都先当成敌意指令过滤掉。这里的信任边界，和任务本身重合了。

更麻烦的是它在日志里的隐身性。被劫持的动作，在事后审计里往往看起来是一次正常执行：某一步完成了，状态改变了，没有报错，没有异常告警。区别只在于这一步的语义被环境里的隐藏指令悄悄换掉了——智能体以为自己在做 A，实际做的是 B，而 A 和 B 在系统层面留下的痕迹可能一模一样。这类失败常常要到下游出了问题、有人反查时才被发现，那时动作早已生效。

对任何打算把智能体接进真实系统的技术负责人，这类失败比幻觉更棘手，值得单独对待。幻觉是输出层的问题，人在采纳前还有机会核对；间接提示注入是动作层的问题，它不在输出里，而在已经发生的动作里。这意味着仅靠事后的日志复核不够——等日志能看出问题，损害已经造成。真正能拦住它的，是动作级的人工批准点：在智能体执行不可逆或高风险动作之前，强制一次人工确认，把「事后发现」提前成「事前拦截」。

这条也给出了一个可以写进设计规范的具体控制：对会读取外部、不可信内容的智能体，越是靠近不可逆动作的环节，越要缩短它的自主链条。观察一个供应商是否认真对待了这个问题，有一个简单的反证信号——如果它的方案里，智能体读完外部网页后可以一路自动执行到提交，中间没有任何为高风险动作设置的强制停顿，那么无论它的模型多强，这套系统对间接提示注入基本是不设防的。

沙盒里的三个测试场景，该被读成三台专门用来暴露失败的装置，而非三个产品演示。它们各自对准一类不同的风险，合起来构成一张关于「智能体在哪能用、只能用到什么程度」的能力地图。

第一个方向是质量保证。CSA 让智能体去检查政府网站的响应、搜索与页面完整性，识别那些被故意放进去的失效页面、占位文本，以及指向预发布环境的错误链接。这个场景考的是它在一个动态、会变化的界面里能否做出解释和判断——分辨出哪个链接不该出现在生产站点上，哪段文字是占位符而非真实内容。它测的是智能体在真实网页环境里的辨识力，而脚本化的巡检做不到这一点。

第二个方向是安全测试，这里藏着整份材料里最值钱的一句话。公开资料说，智能体能帮助更大规模地、跨不同语言和格式去测试聊天机器人，同时明确指出这种实现「并非完全无误」。从工程角度看，用智能体自动生成多语言、多格式的对抗性输入(也就是让智能体去做红队)，确实能把测试覆盖面扩展到人工做不到的规模；但它有一个内在偏差——自动生成的攻击更容易命中已知攻击模式的各种变体，而不容易发现全新的攻击向量。「并非完全无误」这句话背后，正是这个含义。

在一份政府材料里主动承认自己的工具会出错，是极有价值的信号，值得单独强调。它把评估的问题从「这个工具能不能成功」换成了「它在什么条件下会失手、失手能不能被发现、谁来收拾」。这正是从能力叙事转向问责叙事的那一步——一个不肯承认自己会失手的方案，恰恰是最不该被放进生产环境的方案，因为它连自己的失败边界都没画出来。采购方遇到一份把一切都说得万无一失的供应商材料，合理的反应是提高警惕，而不是放心。

第三个方向是社会援助，这里的关键在于能力被设计成了「到此为止」。智能体在这个场景里被观察的，是能否引导申请人或社工穿过一套复杂的申请流程，而明确不替任何人裁定资格。这条界线是有意划出来的：引导是可辅助的，裁定是必须由人承担的。三类场景叠起来，就是那张能力地图——哪里让智能体当助手，哪里只让它当测试员，哪里必须把人焊死在回路里。这张图同样适用于企业：客服、合规、财务、运维里的智能体，差别不在模型多聪明，而在出事时谁能把过程说清楚。

把「出事能交代」拆开，正好是那份清单的四个条目，也是四道可以逐项尽调的边界。CSA 归纳的四类共同风险——人工监督、定制与控制、网络安全、数据保护与隐私——与 IMDA 的 agentic AI 治理框架里的组件(工具、协议、控制、日志与监测，其中「控制」包含访问控制、护栏与人工批准)对照落地，收敛出的就是这四道边界。它们既是买方的采购标准，也是投资人的尽调项。

第一道是数据边界。真实数据、脱敏数据与模拟数据是否被严格区分，是第一个要问的问题。像社会援助这类高敏感场景，一个合理的默认是：能只用模拟数据就绝不用真实数据。一个供应商如果在演示阶段就随手用真实公民数据去喂智能体，那它在数据治理上的成熟度基本可以判负。第二道是权限边界：智能体到底只能读取与建议，还是能提交、修改、触发后续动作。这一条几乎单独决定了整个系统的风险等级，前面关于回滚和限权的讨论都收敛到这里。

第三道是审计边界：每一次点击、每一次输入、每一次工具调用、每一次失败与每一次人工接管，是否都留下了痕迹。这里要补一句工程提醒，因为它是一个常见的实现陷阱——这里说的「护栏」，不同于对话式 AI 的输出过滤器。对话式护栏是在模型吐出文字之后过滤内容；行动链上的护栏，必须在每一次工具调用之前生效。把为聊天机器人设计的输出护栏直接搬到行动链上，会在中间步骤留下大片控制空白：模型的最终输出被检查了，但它中途执行的一系列动作根本没经过任何闸门。

第四道是责任边界：政府、云厂商、模型方与集成商各自承担什么，是否在出事之前就写清楚。这一条最容易被拖到出事之后才发现没人写过。当一个由四方共同搭起来的智能体做出了一个错误的、影响到公民的动作，如果合同里没有事前的责任划分，追责就会变成互相推诿，而受影响的人得不到救济。把责任划分写在部署之前，是这四道边界里最不技术、却最考验治理成熟度的一道。

这四条对两类人是两份不同的清单，值得分开看。对买方，它是采购与验收的硬标准——可以照着它，拒绝一个只会演示、却交不出日志设计和接管方案的供应商。对投资人，它是判断一家智能体公司值不值得投的尽调项：看它能不能把这四样做成产品化的能力，而不只是一页幻灯片上的承诺。当证据成了交易的标的，买方的懂行和卖方的能做同样稀缺、同样值钱，前面那道不对称最终落在这四条上。

在沙盒、限权试点、直接进生产这三者之间怎么选，如果把它当成一次期权定价来算，结论其实并不含糊。这个框架比凭直觉选「稳妥方案」要清醒，因为它逼你面对每个选项真实的成本。

继续留在沙盒里，是表面上最安全的选择，却也在悄悄浪费一笔已经付出的成本。花了几个月、在受控环境里攒下的失败分类、权限模型、日志与接管设计，是一批已经买到手的期权；如果不拿它去换一点真实价值，这批证据就会随着模型迭代和场景变化而贬值。沙盒里长出来的证据有保质期——它只能证明「在沙盒条件下会怎样」，放得越久，离真实生产环境的差距就越大。一直留在沙盒，等于把买到的期权锁死到过期。

直接进生产则是另一个极端，它要求责任分配、回滚机制与持续监控全部就位。问题是，今天的公开证据还撑不到这一步：没有成效数据，没有被验证过的大规模问责实践，连回滚在遗留系统上是否可靠都还是未知。在这些前提还没落地时就把智能体推进生产，等于在没有安全网的情况下把不可逆的风险交给一个会被环境带偏的系统。

夹在中间的限权试点，因此是这道题在当下事实里回报最高、下行可控的答案，而非一个折中的安全牌。它的做法是：划出一块边界清晰、可回滚的真实场景，让智能体在真实环境里运行，但只授予有限权限、并在高风险动作前设人工批准。它用一小块真实运行，去换取只有真实环境才能长出来的下一批证据——真实用户的真实输入、真实系统的真实响应、真实失败的真实痕迹。这些是沙盒里造不出来的，也是进一步扩大规模前必须先拿到的。

把这套逻辑压成一条可执行的决策规则：不要用「感觉安不安全」来选，而要问「哪个选项能以最小的不可逆风险，换到最多我现在还没有的证据」。按这个标准，限权试点几乎总是当下的最优解，直到它换回的证据足够支撑责任、回滚与监控三件事同时到位——那时，而且只有到那时，再谈扩大到生产规模才是有依据的。反过来，如果一个团队的试点跑了很久却始终不敢授予任何会改变状态的权限，那也是一个信号：要么场景选错了，要么底层系统还没准备好承接智能体。

前面反复出现的「人工批准点」，值得单独展开，因为它是整套控制里最容易被架空的一环。几乎每一份 AI 治理文件都会写上「保持人工监督」这句原则，但原则和产品之间隔着一道很少有人认真跨过的鸿沟——一句写在治理文档里的「human in the loop」，不会自动变成系统里一个真实生效的闸门。

把人工监督做成产品，意味着要回答一串很具体的工程问题，而不是重申一句立场。哪些节点必须强制弹出批准、不批准就停；哪些节点允许事后复核、先执行后备案；哪些异常情况要触发自动停机、不等人。这三档的划分本身就是设计决策：分得太松，批准点形同虚设；分得太严，人被淹没在批准请求里，最后变成机械点「同意」，监督退化成橡皮图章。

还要回答谁来监督、以及监督者被给了什么。谁有权接管一个正在执行的智能体；接管时，系统有没有把足够的上下文推到人面前，让他能在几秒内看懂「智能体正打算做什么、为什么」；哪些记录会进入审计系统，供事后追责。如果批准请求弹到人面前时只有一句「是否允许执行」而没有可判断的上下文，那这个批准点在架构上存在，在实践中却无效——人被摆在了回路里，却没被给予做判断的材料。

少了这些，人只是名义上在回路里。真出事的时候，如果没有人能指出「他本该在这一步把它拦下」，那所谓的人工监督就从未真正存在过——它只在治理文档里存在，不在运行的系统里存在。这也是尽调时最该验证的一点：不要满足于供应商说「我们有人工监督」，而要请它演示，在一个高风险动作发生前，批准请求长什么样、包含哪些信息、不批准会怎样、这次批准是否被记进了审计。

对采购方，这里有一条可以直接用的验收标准：把人工监督当成一个可测试的功能，而不是一句可勾选的承诺。让供应商在验收环境里真实触发一次需要批准的高风险动作，观察闸门是否弹出、上下文是否充分、拒绝是否真的中止了执行、整个过程是否留痕。一个通不过这个测试的系统，无论它的宣传材料里怎么承诺，它的人工监督就是不成立的。这个测试不复杂，但它能筛掉相当一批只在纸面上做治理的方案。

把镜头拉到区域来看，最不可能跨境复制的，正是新加坡与 Google 的那套具体组合。各国的数据保护法规、公共流程、云基础设施与人才储备都不相同，照搬具体用例多半水土不服——一个在新加坡跑通的社会援助智能体，换到另一个国家的申请流程和数据环境里，大概率要推倒重来。能真正搬走的，是那套问法本身。

那套问法独立于任何厂商：哪些任务允许智能体观察、建议、执行，哪些必须人工确认，哪些日志必须保留，哪些失败必须中止，哪些供应商责任必须写进合同。它不绑定 Google，也不绑定任何一个模型，因此可以直接长成各地本土的采购标准。这正是把新加坡看作标准制定者、而非又一个应用现场的分量所在——它输出的是一门采购的语言，而语言比部署更容易跨境。

这门语言会不会真的跨境，取决于它靠哪些渠道扩散，而这一步目前还没有定论。可观察的通道是具体的：IMDA 在 ASEAN 数字主计划下的相关工作、多国之间的双边数字经济协定、以及 CSA 与他国同类机构之间的框架与技术输出。这些渠道确实存在，但它们传导得多快、能不能把一套问法变成多国招标里的通用条款，眼下都还是未知数。

所以这里要给一个可证伪的判断，而不是一句乐观的断言。正向信号是：若一两年内，某个 ASEAN 邻国的公共采购文件里开始出现新加坡这套问法的影子——按动作粒度收权、分场景的失败分类、工具调用级的日志、事前写清的多方责任——那说明这门语言真的在过境。反证信号同样清楚：如果各国买方的采购能力成熟得慢、或各自另起炉灶，它完全可能长期停留在新加坡本地，成不了区域共识。衡量这门语言的分量，要盯的是它在别国招标书里出没的频率，而不是它在新加坡跑通了多少个用例。

这就把问题交回到每一个正在做同一道选择的政府与平台手上：要不要、在什么边界内，把一批智能体从沙盒往前推一小步。公开证据给出的答案并不暧昧——先用限权试点换取可被证明的控制，再谈规模。而新加坡这一次真正拿得出手的，是一门把「控制」写成可尽调、可写进合同条款的采购语言；用例难以跨境，这门语言却可以。它到底能走多远，答案不在新加坡的沙盒里，而在别国的下一版招标书里。