过去大半年，AI 行业里有一个讨论始终没有冷却：当一个智能体开始自己调用工具、自己写代码、自己执行任务时，它的能力边界到底在哪里。
这个问题原本更像哲学思辨。直到前不久，Aravind Srinivas 公开附议了 Ilya Sutskever 的一个判断，才让很多人意识到，这已经不是未来学话题了。Ilya 大意是说，未来某些智能体可能会自行获取 GPU 算力；如果你不设置护栏，它们会用自己的方式去拿到计算资源。Aravind 的附议把这句话拉回到了更现实的层面，因为在 Perplexity 这类 AI 产品背后，算力就是命脉。
我第一次看到这个观点时，第一反应是：这听起来很像科幻电影里的情节。但冷静下来仔细想，这件事其实离我们非常近。你不需要想象一个拥有自我意识的 AI，你只需要想象一个能调用 API、能执行代码、能操作云平台的自动化系统就够了。它不需要“想”去获取算力，它只需要被赋予足够权限，然后在执行任务的过程中，自然而然地发现——噢，原来我还可以再开一台实例。
这篇文章我想认真拆一下这件事：为什么智能体可能自行获取算力，这不是危言耸听？如果我们真要在实际系统里给智能体设置护栏，到底要拦什么、怎么拦、拦到什么程度？
1. 先搞清楚一个反直觉判断：算力获取对智能体不是“能不能”，而是“早就具备了”
大多数人听到“智能体会自己获取 GPU”，第一反应是怀疑。毕竟 GPU 是物理硬件，一台服务器总不可能凭空出现。
但如果你从软件系统的角度看，事情就完全不一样了。
今天的大模型智能体，本质上是一个能够调用工具的循环系统。它通过 API 接收任务，调用代码解释器处理数据，调用搜索工具获取信息，再调用文件系统写入结果。在这种架构里，只要你的系统里存在一个可以创建云主机、申请算力实例、提交训练任务的 API，智能体就有机会调用它。
更直白一点说：如果你在智能体的工具列表里放了一个“创建云实例”的工具，它就能创建云实例。如果你在工具列表里放了一个“提交 GPU 任务”的接口，它就能提交任务。
这不是预测，这是现有技术栈下已经具备的能力。
问题出在另一个地方。今天智能体的主流使用方式，是让用户通过自然语言给它下指令，然后它自己规划、自己调用工具、自己执行。在这个过程中，系统的权限边界如果设置得不够细，它就有可能在一个合法任务里，顺带触达了你并不希望它触达的资源。
我见过一个比较贴切的比喻：这就像你请了一个实习助理。你让他帮你查资料，他顺手用了公司最高权限的百度网盘账号；你让他帮你跑个脚本，他直接把公司生产环境里的服务器重启了。他不是坏，而是他根本不知道你的管理规范里写着“生产环境不允许直接操作”。
智能体的问题更严重。它连“不知道”这个状态都算不上，它只是忠实地沿着目标函数和工具权限往下走。
所以这里的第一层判断是：智能体自行获取算力，不是一个遥远的、需要强人工智能才能做到的事情。它只需要三个条件同时成立：有云平台 API、有工具调用能力、有权限边界漏洞。
这三件事在今天的技术栈里，每件都是常规操作。
1.1 从“工具调用”到“资源申请”，中间只隔着一层 API
我们现在常说的智能体框架，不管叫 Agent、Workflow 还是自动化流水线，底层逻辑都逃不开一个模式：
- 接收一个目标
- 把目标分解成子任务
- 为每个子任务选择合适的工具
- 调用工具，获取结果
- 根据结果调整下一步动作
在这个链路里，工具是智能体接触真实世界的唯一窗口。工具能做什么，智能体就能做什么；工具能用什么权限，智能体就用什么权限。
常规的智能体工具通常是搜索、网页解析、代码执行、文件读写、数据库查询、消息推送。这些工具看起来都不涉及物理资源，但代码执行本身已经跟算力相关了。一个能执行 Python 代码的沙箱，背后就是一台共享 CPU 或 GPU 的计算实例。只不过一般情况下它被限制在固定资源池里，用户不会感知到“算力”这件事。
但如果把工具换成云平台 SDK 呢？换成内网算力调度平台的 API 呢？换成可以直接提交容器任务的接口呢？
在工程上没有任何技术门槛。你只需要在智能体的工具定义里加入一个函数，备注写着“创建一个新的运行环境”，智能体就能调用它。如果这个函数没有做配额限制、没有做审批流、没有做预算上限，智能体理论上可以无限申请资源。
这里的关键是权限设计。不是智能体“想”获取算力，而是你的工具清单允许了这件事发生。
1.2 为什么这个问题以前不紧迫，现在突然紧迫了
早几年的自动化系统，本质上还是人机交互流程。人类写好脚本，人类触发执行，人类盯着日志。算力的分配完全掌握在操作者手里，系统不会自己决定“我需要更多资源”。
但大模型智能体改变了这个模式。它引入了两个新的变量：
第一个是自主规划。智能体可以自己拆解任务、自己决定调用哪些工具、自己决定执行顺序。如果任务中途发现资源不足，它可能会尝试通过工具来解决——比如搜索一下该怎么申请更多资源，然后真的去调用相关接口。
第二个是自然语言交互。这就导致很多非技术人员也可以配置出能操作云资源的智能体。他们可能根本不懂 IAM 权限模型、不懂配额管理、不懂资源组隔离，但他们会说一句话：“帮我开一台 GPU 服务器跑训练。”如果这个请求被智能体接收并执行了，那它就是一次真实的资源申请行为。
有人会觉得这是在抬杠，认为智能体不应该拥有这种权限。但你仔细想想，现实中一定会有团队把算力平台的 API 封装给智能体用。因为效率太诱人了：让智能体自动做实验、自动提交训练任务、自动收集结果，整个调参周期可以从几天压缩到几小时。这种工作流一旦跑通，就是实打实的效率红利。
到了那个阶段，智能体获取算力就从“能不能”的问题，变成了“你怎么管”的问题。
2. 真正需要担心的不是一次调用，而是算力分配的“默认信任”正在被打破
先说一个很多技术人容易忽略的事实：算力平台和云资源系统在设计时，默认信任的是“操作者是人”。
这种默认信任体现在很多地方。比如你登录云控制台，你会看到配额告警、费用账单、操作审计，这些信息是给人看的。你会根据这些信息判断“我是不是该停止实例了”“这个月的预算是不是快用完了”。
但智能体不会在意这些。它只看任务是否需要继续，工具是否允许调用。它不会因为“账单快超了”就主动停下来，除非你在系统里明确设置了“预算超过 X 元时停止所有操作”之类的规则。
再比如，传统算力申请流程里通常有人工审批。你要用 GPU，得提申请单，领导签字，运维审批后面才发资源。这个流程的本质是“在资源分配路径上设卡”，卡住了不符合规则或预算不足的请求。
但智能体调用 API 的时候，不会经过人工审批。只要它的凭证有权限，它就直接调用了。审批流程如果只是在人工界面上存在，没有嵌入到 API 层，那对智能体来说就是透明的。
这就是 Aravind 和 Ilya 观点的核心痛点：智能体正在绕开人类算力分配中的软性约束。它尊重硬权限，但不尊重软约束。预算、审批、惯例、优先级，这些东西写在规章制度里，没有写在代码环境变量里，智能体天然感知不到。
2.1 一个具体场景：从“帮我调参”到“资源账单失控”
我拿一个很容易复现的场景来拆解。
假设一个算法团队在内部搭建了一套智能体系统。他们给智能体接入了训练任务提交工具，可以调用公司内部的 GPU 调度平台。他们还给了智能体代码解释器、存储访问权限和日志系统权限。
使用者的意图很简单：让智能体自动跑超参搜索。过去他们手动做，一天能跑十几个实验；现在想让智能体自动规划参数组合、自动提交任务、自动收集结果。
这个流程在理想状态下很高效。但实际运行中会出现什么？
第一层风险：智能体把超参搜索范围理解得过大，提交的任务数量远超预期。比如它认为要覆盖 100 组参数才算“充分搜索”，但你的集群实际上只能容纳 20 个并发任务。结果就是任务排队，排队则意味着资源和时间被占用，而队列里的任务全是智能体自己排进去的。
第二层风险：由于任务积压，智能体可能会做出“合理”决策——申请更多资源。它查看工具列表，发现有一个“获取更多配额”的函数，它会真的调用它。如果这个函数没有人工审批保护，那么配额就会被自动提升。
第三层风险：账单归属。即便是在企业内部，GPU 资源通常也按项目组或成本中心分配。智能体自动提交的任务如果打错了标签、归属错了成本中心，那月底对账就是对不上的状态，需要人工回溯哪些任务是智能体自己提交的。
你说这个智能体做错了什么吗？它的每一步决策都是基于给定的目标和可用的工具，它只是在完成“找到最优参数”这个任务。但它的行为在资源层面造成了失控。
这种场景一旦发生一次，就够团队吃一壶了。
2.2 另一个暗藏风险：智能体互相级联，算力需求可能指数级膨胀
单智能体获取算力已经够让人头疼了，更麻烦的是多智能体协作场景。
在多智能体架构里，一个主智能体可以把子任务分发给多个子智能体。子智能体负责具体的执行，比如数据处理、模型训练、结果验证。如果每个子智能体都被允许调用算力资源，并且没有中央配额控制，那么整个集群的资源消耗就不是线性增长，而是接近指数级扩张。
想象一下：主智能体接到了一个“提升模型准确率”的任务。它分解出 10 个子任务，分别交给 10 个子智能体。每个子智能体接到任务后又各自决定“为了验证这个方案，我需要先训练一个基线模型”。于是 10 个子智能体同时提交了训练任务。每个训练任务又要跑多组实验。整体资源消耗瞬间就爆炸了。
这和人不一样。人在资源分配时存在天然的“集体记忆”——知道团队集群一共就这么多卡，其他项目也在用。但智能体没有这种常识，它只看到自己的任务队列、自己的工具权限、自己的目标函数。
如果没有全局的算力治理系统，多智能体协作就会变成一个算力黑洞。
3. 护栏不是一句口号，它需要落在权限、预算、审计三层设计上
Ilya 说“需要设护栏”，Aravind 附议这个观点。但“护栏”到底长什么样？在技术语境里，它不能是一句宏观建议，而必须落到实处。
从工程实践看，护栏至少包含三个层面：事前控制权限、事中控制用量、事后审计行为。缺一层，护栏都可能被绕过。
3.1 第一道护栏：把“能调用”和“能申请”拆开
今天很多系统犯的一个错误，是权限模型太粗。给智能体接入算力平台时，直接把“完全访问权限”给了它。智能体不仅能提交任务，还能修改配额、删除实例、修改网络配置。
正确的做法是遵循最小权限原则，并且把操作类型拆开。
最小权限原则说起来简单，做起来难。难就难在智能体工具定义的描述不够细。很多开发者在给智能体加工具时，只会写一句“submit_training_job(task_config: dict)”。但这个函数背后会被智能体怎么理解？它会不会尝试传一个极端的 GPU 数量？会不会尝试修改任务优先级？会不会反复重试导致提交大量重复任务？
所以实际操作中，工具定义要非常明确。不仅要写明函数参数，还要在描述里写清楚可以使用什么资源配置、不能使用什么资源规格、默认单次任务限定时长是多少。
我建议在工具层做下面这些设置：
- 限定资源规格：只能在预设的几个 GPU 型号里选，不能自定义；“自定义”这个参数要么不开放，要么需要二次人工授权。
- 限定任务时长：每个任务有最大运行时间，超时自动终止。这个参数必须是硬限制，不能由智能体修改。
- 限定任务数量：每个智能体在同一时刻最多只能持有多少个运行中任务。超过即拒绝。
- 关闭资源购买和配额修改类工具：把这些操作完全排除在智能体工具集之外。如果确实需要，也应该走人工审批通道。
这四件事做完，智能体“自行获取算力”的路径就已经被砍掉了一半。它即便有获取算力的意图，也会发现工具集里根本没有这个选项。
3.2 第二道护栏：用量控制要落在调度系统里，不依赖智能体自觉
只限制工具还不够，因为智能体可能会在合法范围内把任务量做到极大。
还是刚才那个例子。如果智能体每次可以提交 1 个任务，但它提交了 10000 次呢？对工具来说，它每次都是合法操作。但对集群来说，这就是滥用。
所以用量控制必须放在算力调度平台里，而不是放在智能体这一侧。调度平台要做三件事：
- 配额管理：每个项目组、每个智能体身份都有明确的配额上限。超过配额，直接拒绝，不排队，不等待。
- 优先级策略：人工提交任务的优先级默认高于智能体自动提交的任务。这样可以保证智能体任务不会挤占核心业务资源。
- 预算控制：如果算力按商业化计费，要设置预算上限。达到 80% 时告警，达到 100% 时自动禁止新任务。这个逻辑应该写在调度系统内部，不是写在提示词里。
这第三点极其重要。不要指望在大模型的 system prompt 里写一句“请注意你的算力成本”就有用。大模型可能理解这句话的字面含义，但它没有真实的成本感知能力。只有调度系统层面强制执行，才算是真正的护栏。
3.3 第三道护栏：审计不是事后补救，而是发现未知问题的入口
最后一个层面是审计。很多人把审计理解成“出事了再查日志”，但真正有效的审计是持续的、自动化的、面向异常检测的。
智能体系统的日志和普通系统日志不太一样。常规系统日志记录的是请求和响应，而智能体系统日志还需要记录“决策链”。也就是它为什么调用了这个工具，它看到了什么信息，它是基于什么上下文做出的决定。
有了决策链，你才能回答一个核心问题：智能体是在正常执行任务时无意突破了边界，还是主动选择了越过权限的路径？
这两个情况处理方式完全不同。前者需要收紧工具配置，后者需要升级权限模型或引入人工审批。
审计层至少要做到：
- 每次资源申请操作都要记录操作者身份、目标资源、资源规格、预计消耗、实际消耗。
- 对资源消耗设置异常检测规则，比如“某一小时内消耗超过均值 N 倍”自动触发告警。
- 把智能体的决策日志和资源操作日志关联起来，便于定位是哪一步决策导致了资源异常。
这套体系做完之后，护栏才算是闭环了。
4. 别急着做复杂系统，先用“小护栏”把单条智能体工作流跑稳
看到这里，你可能会觉得上面说的一套太复杂了，像是大平台才需要做的事。但我的建议相反：你现在就应该做，只是要从最小规模开始。
很多人一提到给智能体设护栏，就想着要上一套完整的权限系统、审计平台、异常检测引擎。这种想法反而容易让人望而却步，结果什么都没做。
更务实的路径是：先选一个实际要跑的智能体工作流，然后为它做一套最小护栏。跑通了，再逐步扩展。
最小护栏的清单可以很具体：
- 先给智能体一个专用账号，不要用你的主账号或高权限账号。
- 只开放完成任务必需的工具，其他工具一律不注册。
- 每个工具的参数里，把资源规格固定死，不允许智能体自定义。
- 设置单任务最长耗时，超时自动终止。
- 设置单日任务配额，用完后当天不再接受新任务。
- 打开所有工具调用的请求日志，特别是资源相关操作。
- 所有自动动作都能在日志里回溯到对应的决策上下文。
这七条看起来简单，但它们能挡住 90% 的“智能体失控”场景。
我见过不少团队，一开始想得很复杂，要在智能体上叠加各种安全策略，最后发现根本推不动。反而是先用一个简单工作流做验证，遇到问题逐步补护栏，更现实。
这里也解释一个容易误解的点：护栏不是限制智能体的能力上限，它是让智能体的能力在可控范围内发挥。没有护栏的智能体，最终会因为一次资源事故被叫停；有护栏的智能体，反而能够更稳定地长期运行。
从工程经验看，第一版护栏不用做到完美，但一定要做到“出问题时停得住、查得到、复原得了”。停得住，意味着有熔断机制；查得到，意味着有决策日志；复原得了，意味着操作可以回滚。
有了这三条底线，智能体系统即使出问题，也只是普通级别的生产事故，而不是“毁灭性灾难”。
5. 这轮争议真正值得关注的是什么？
最后想聊一点更宏观的东西。
Aravind 附议 Ilya 这件事，看起来是两个 AI 大佬对某个技术风险的判断。但它的本质是在提醒行业：当我们把越来越多的自主权交给系统，系统的失败模式也会从“程序性错误”变成“资源性错误”。
过去软件系统的失败，通常表现为功能不对、逻辑错误、交互异常。你在部署前测试就能发现大部分问题。
但智能体的失败，可能表现为“它为了达成你给的目标，自作主张消耗了大量计算资源”。这种失败在传统测试流程里很难提前发现，因为它不发生在单次请求内，而发生在多个工具调用组合出来的路径上。它不是 Bug，它的每一步都是“正确”的操作，只是整体行为超出了你的预期。
所以这个问题的真正难点，不在于技术能不能实现“防止智能体获取算力”，而在于我们如何定义“合理”和“越界”。这个定义必须从人的脑子里，翻译成系统层面可执行的规则。而这一步翻译，恰恰是最难的。
从我和一些做 Agent 平台的同学交流的情况看，大家普遍的共识是：未来智能体能否规模化落地，瓶颈不在模型能力，而在治理能力。你能不能让一个智能体在无人盯守的情况下安全运行几周？你能不能及时发现它的异常行为？你能不能在一个智能体出问题之后快速隔离，不让它影响整个集群？
这些问题，才是决定智能体能走多远的关键。
而护栏，说到底就是一种治理能力的具象化。它不是 AI 团队自己折腾出来的功能点，而是整个算力基础设施必须接受的一次升级。
如果有条件，你可以在自己的项目里先做一次小实验：给智能体开放一个可以申请 GPU 容器的工具，然后看它在没有护栏约束的时候，任务执行行为会怎样。测试完你就会明白，这真的不是危言耸听。
