8.0
热点
AI SCORE
技术实践2026-08-19 22:00
DevOps视角解读Agent术语：12个概念在基础设施层的真实映射
dev.to · AI#Agent#DevOps#LLM
Editor brief · 编辑速览
文章将12个Agentic AI术语翻译成DevOps工程师熟悉的概念：Agent loop即 reconciliation loop、Guardrails即admission control、Sandboxing即cgroups。重点分析了每个类比的边界在哪里、为何有些无法简单映射。
目前有一类信息图正在流传：十二个必须了解的 AI 智能体术语、一份面向高管层的智能体语言指南。这些图对目标受众——高管——来说是合适的。问题在于下一步会发生什么：高管拿着这套词汇找到平台团队，问智能体多久才能获得生产环境访问权限。
如果你负责运维基础设施，对这份列表的诚实解读并不是来了十二个新东西。而是其中十个是你已经在操作的概念，只是用了不同的名字；另外两个才是真正的新东西，而这两个才会让你头疼。智能体循环就是一个调和循环（reconciliation loop）。护栏就是准入控制。沙箱就是你对不受信工作负载一直以来在做的事——从 cgroups 开始就是。
这篇文章就是一张对照表，接下来是信息图遗漏的部分：每个类比具体在哪些地方失效。失效的部分才是有趣的部分。如果一个智能体只是一个控制器，你早就知道怎么运行它了。
十二个术语中有十个可以干净地映射到你已经在运行的基础设施原语上：控制循环、IAM、沙箱、准入策略、变更门控、调度器。
智能体循环是一个带有非确定性控制器的调和循环。形状相同，但所有依赖于"相同输入、相同输出"的运维假设都不再成立。
工具使用是一个 IAM 问题，不是 AI 问题。智能体的影响范围恰好是你赋予其工具的凭据的并集。模型本身改变不了这一点。
提示词注入是一种以内容载荷而非二进制载荷实现的权限提升，而你的遥测数据就是它的传播通道。
两个真正的新东西是非确定性和无界运行时成本。你已经在运行的基础设施中，两者都没有好的类比。
先问影响范围问题，再问模型问题。哪些凭据、哪些环境，以及审计日志实际记录了什么。
前置知识
对容器和某种编排器（很可能是 Kubernetes）有基本了解
对 IAM 或 RBAC 有一定接触，无论热情高低
读过一篇 AI 智能体解析文章，但看完后不确定到底在讲什么
对照表
从这里开始。这是一个界面就能展示完的完整论证。
这十二个中有十个只是重新贴了标签。这不是对这套词汇的批评。恰恰相反，这就是基础设施人员异常适合推理智能体、却异常被面向高管层的解析文章坑了的原因。
现在进入真正值得深入的部分。
智能体循环是一个调和循环，只有一个关键区别
每篇 AI 智能体解析文章都会画同样的循环：感知、规划、行动、观察、重复。如果你写过 Kubernetes 控制器，你自己就画过这个循环，只是叫法不同。
观察——监听 API，或读取上下文
比对——当前状态 vs 期望状态，或规划一步
行动——调用 API，或调用工具
验证——读取状态，或观察结果
形状是相同的。控制器监听 API 服务器，将实际状态与 spec 进行比较，采取行动缩小差距，然后观察结果。智能体读取上下文，规划一步，调用工具，然后观察输出。如果你想详细了解第一个的机制，《Write a Simple Kubernetes Operator》是从头构建一个控制器的完整指南，其中所有内容都可以迁移过来。对于智能体侧的循环，包括为什么判断工作的组件必须与执行工作的组件分离，参见《Stop Prompting, Start Looping》。
这里是区别，而且不是一个小的区别。控制器是确定性的，而智能体不是。
给控制器两次相同的集群状态，它会产生两次相同的操作。这一个属性是支撑你几乎所有控制循环运维知识的基础。正因如此，你才能测试控制器，才能推理卡住的调和过程，才能把重新运行当作诊断工具而非赌博，以及为什么"这次它做了不同的操作"是一份 bug 报告而非预期行为。
相同的输入给到智能体，它可能走不同的路径。通常不会差异很大，但足以让以下所有事情不再可靠：
复现故障。再次运行不是一次受控实验。
测试覆盖率。一次通过不能证明这条路径是安全的。
事后分析。"它为什么那样做"可能没有比"它采样了一个不同的 token"更好的答案。
本文其他一切内容都从这个属性推导而来。基础设施的类比在它们不依赖于确定性之前都成立，之后就失效了。
工具使用是一个穿着新马甲的 IAM 问题
这是引起最多困惑的术语，也是答案最清晰的一个。
智能体只能通过工具做事。模型产生的是文本。文本要变成行动，只有靠你这边的什么东西接收那段文本然后调用 API。所以"这个智能体能对我的基础设施做什么"这个问题有一个精确答案，而且它根本不是关于模型的问题：
智能体的影响范围是你赋予它的每个工具所持有的权限的并集。
这是一次 IAM 审计，而你早已知道怎么做。如果智能体有一个工具能用绑定到 cluster-admin 的 kubeconfig 调用 kubectl，那么这个智能体就是 cluster-admin。再多的系统提示词中的指令也改变不了这一点，就像告诉实习生小心不是一种访问控制机制一样。
实际的后果是安全对话应该从凭据开始，而不是从模型开始：
# 唯一能真正界定智能体能做什么的问题
kubectl auth can-i --list --as=system:serviceaccount:agents:incident-responder
如果这个输出让你害怕，模型选择就无关紧要。如果范围收得紧，那么一个糟糕的计划产生的只会是一个被拒绝的 API 调用，而非一次故障。
有用的心智模型是：智能体是一个用户，不是服务。给它自己的身份，精确地限定它所需的范围，让它的行为在审计日志中可归因。一个智能体共享你平台团队的服务账号，和 CI 流水线共享一个人的凭据是同样的错误，而且会在同一时间以同样的方式失败：在事故复盘时。
MCP 是一个插件接口，它继承了插件接口的问题
Model Context Protocol（模型上下文协议）是最可能被呈现得比实际更新颖的术语。它是一种协议，通过一致的接口向智能体暴露工具、数据和提示词，这样一个能力写一次就可以被任何懂这个协议的客户端使用。
从结构上说，这和存储的 CSI 或网络的 CNI 是同样的思路：一个稳定的接口，让厂商写一个实现而不是每个消费者写一个。我们写过关于何时该用 MCP 何时该用普通 CLI，简短版本是答案通常是两者都要。
从运维角度重要的是：插件接口是一条供应链。每个 MCP 服务器都是代码，来自某个人，带着你赋予它的访问权限运行。这是一个与 Helm chart、Terraform provider 或 GitHub Action 相同的信任问题，还多了一个麻烦：MCP 服务器的工具描述本身就是到达模型的文本。我们关于 MCP 设计缺陷及它所引发的 RCE 的分析覆盖了实践中哪里出了问题。
对待 MCP 服务器的方式要像对待任何第三方准入 Webhook 或 CSI 驱动一样：固定版本、阅读你安装的内容、不要运行一个你无法溯源的。
护栏是准入控制，而且它们应该放在智能体外部
大多数解析文章中的"护栏"指的是限制不安全行为的规则和政策。这样写下来，听起来像是你在 AI 产品内部配置的东西。
在生产环境中存活下来的版本是你已经在运行的：在智能体无法逾越的边界处执行的策略。准入 Webhook 不要求工作负载表现良好。它拒绝请求。RBAC 不信任客户端的意图。它评估调用。
这个区别就是全部关键。有两个地方可以放护栏：
在提示词中。"永远不要删除生产命名空间。"这是对一个非确定性系统的强烈建议，而且会被任何改变模型上下文的东西击败，包括一条恶意的日志行。
在执行层。生产命名空间上没有删除权限。这不会被击败，因为这个能力根本不存在。
提示词级规则值得有，就像文档和 linting 值得有一样。但它们不是控制手段。如果一个护栏很重要，它应该放在 RBAC 里，放在 OPA 或 Kyverno 里，放在网络策略里，或者放在凭据的缺失中。
需要警惕的失败模式是：一个护栏只在系统提示词里描述，别处再也找不到，然后在设计评审中被当作控制手段呈报。问问它在哪里执行。如果答案是"我们告诉它不要做"，那就是文档。
落地（Grounding）是可观测性，同时也是攻击面
Grounding 意为将模型的输出连接到真实数据，而非它自行推断的结果。对基础设施工作而言，"真实数据"就是你的遥测数据：指标、日志、链路追踪以及 API 的实时状态。
其优势是真实存在的，也是当前 AI 运营工作中真正在起效的部分。一个在提出故障原因前先读取真实指标的 AI 智能体，做的是优秀 on-call 工程师在做的事。我们对 AI SRE 智能体的修复与故障评估发现，调查环节是其中最扎实的部分，而 grounding 就是背后的原因。
信息图无法装进框里的一部分是：Grounding 使你的遥测数据成为了决策系统的输入。日志是受攻击者影响的数据。一条日志行由一个请求写入，而请求可以被精心构造。一旦智能体读取日志并能对其采取行动，日志中的字符串就变成了潜在的指令。
这就是提示词注入（prompt injection），对基础设施人员而言最清晰的诠释是：这是带有内容负载的权限提升。经典的权限提升路径是：不受信任的输入到达特权解释器。此处解释器是模型，而输入是它读取的任何东西：日志行、工单文本、提交信息、告警注释、HTTP User Agent。
对应的缓解措施就是你从上述框架中可以想到的那些，且没有一个是 AI 特有的：
人机交互是一个变更门控，有着相同的失败模式。
在敏感操作前进行人工审查和批准。你已经在运行这套机制了：Pull Request 审查、部署流水线上的手动审批步骤、需要第二双眼睛介入的紧急程序。
这意味着你已经知道它会如何失败。审批门控会直接按照触发频率和携带上下文量不足的比例，退化成橡皮图章。一个审阅者面对当天第四十个"智能体想要重启一个 Pod"的提示时，不是在审查，而是在点击。
变更管理的经验教训完全适用：
按爆炸半径而非按操作数量来设置门控。重启一个无状态 Pod 不需要人工。任何涉及持久化数据或生产网络的操作才需要。
给审批者的是 diff，而非意图。"我将扩展部署"是无法审查的。replicas: 3 -> 30 可以。
使拒绝变得廉价且正常。一个从未被拒绝过的门控什么也测量不了。
如果你的智能体审批提示中不包含足以做出知情拒绝的信息，那它就是带有审计跟踪的走过场。
最后一组被描述为前沿：管理层面负责分配任务、专业化工作者做狭窄的工作、多个智能体协作完成一个工作流。
这是一个分布式系统。具体来说，它是一个调度器、一组工作者和共享状态，这就是你已经在运行的大部分系统的架构。
所以有趣的地方在于：你无需运行就能预测其失败模式：
部分失败。 一个子智能体失败了，编排器没有注意到，工作流报告成功。你在每一个作业运行器中都见过这种情况。
重复工作。 两个智能体被分配了重叠的任务，两者都采取了行动，第二个撤销了第一个的操作。
协调成本超过工作本身。 智能体之间传递上下文消耗 token，超出一定程度后，编排的成本比在单一地方完成还要高。
不幂等。 重试失败步骤会重新运行副作用。与没有去重 key 的 Webhook 遇到的问题相同。
设计问题与你对任何工作者池的问题相同。工作器中途挂掉会发生什么？工作单元是幂等的吗？共享状态在哪里，当两个工作器同时写入时会发生什么？我们在 Mastra 上构建的 on-call 智能体特意在最糟糕的时刻被 SIGKILL 杀死，就是为了回答这些问题，这是正确的直觉。
这两者在大多数解释文章中被混为一谈，但实际上相当不同。
记忆是持久化。 有记忆的智能体在运行之间携带信息，这意味着它有状态，也意味着你所有关于有状态工作负载的直觉都适用。它存放在哪里、丢失了怎么办、谁能读取它、它在你的备份中吗？Deployment 与 StatefulSet 的区别正是正确的视角：有记忆的智能体不是可以自由重新调度的无状态副本，而且如果该记忆持有任何来自生产数据的派生内容，它就继承了与数据本身相同的处理要求。
上下文窗口是一个资源限制。 这是模型一次能考虑的内容量，当你超出它时的运行行为很熟悉：东西被驱逐。早期的上下文被淘汰，智能体会忘记开头给出的约束，方式完全等同于进程在遇到内存限制时无法优雅地忘记任何东西。
实际结果是，在长时间运行的智能体会话早期给出的指令不是持久约束。它是缓冲区中的一个值，正在被驱逐。这也是为什么强制执行应该放在模型之外的原因：RBAC 中的一条规则在第六个小时仍然存在，而开头提示词中的规则可能已经不在了。
剥离重新标记的概念后，剩下两个在你已经运行的基础设施中没有清晰等价物的东西。
控制循环中的非确定性。 你为控制循环设置的所有运营实践都假设可重现性。测试、分阶段部署、事故复现、"回滚看是否停止"都依赖于这个属性。智能体打破了这个假设，而诚实的回应不是假装不是这样，而是把保证转移到某个确定性的地方：在策略中强制执行，用智能体无法影响的检查来验证，并将其输出视为一个提案，直到某个确定性的东西验证了它。
运行时成本作为变量。 控制器的成本大致是固定和可预测的。智能体的成本是它读取量和循环次数的函数，两者每次运行都不同，且可能受到输入的影响。病理情况不只是慢，而是贵，而且没有类似于资源限制块的东西是循环无法争辩的。预算上限和迭代限制在这里不是优化，与内存限制属于同一类控制。
这些都不需要一份策略文档。它需要五个答案。
哪些凭证？ 对其身份运行 can-i --list。该输出就是爆炸半径，其他都是废话。
在哪里强制执行？ 对每条安全规则，说出强制执行点。如果答案是"系统提示词"，那就不是控制。
它读取什么？ 该列表中的所有内容都是不可信输入，包括你自己的日志和工单。
审计跟踪记录了什么？ 仅记录操作是不够的。没有它读取了什么，注入就无法重建。
成本上限是多少？ 每次运行和每天，由循环外部的东西强制执行。
回答了这些问题，模型选择就变成了它一直应该成为的东西：一个你可以稍后更改的实现细节。
智能体循环是一个协调循环（reconciliation loop），工具使用是 IAM 边界，护栏是准入控制，接地（grounding）是可观测性，人机交互是变更门控，而带子智能体的编排器是工作者池，具有所有由此产生的部分失败问题。
这样理解它有两件有用的事。它告诉你现有的直觉大多可以迁移，这比大多数解释文章会告诉你的更多。它也隔离出了两处直觉不适用的地方：一个是不可重现的控制循环，一个是未受限的运行成本。
这两处就是工作所在。其他的你已经做了多年了。
问：智能体真的只是一个控制循环吗？
结构上是的，而且这个比较在它依赖于确定性之前成立。给控制器相同的状态它行为相同；智能体可能不同。测试、复现和回滚都依赖于这个属性，所以它们都需要重新思考。
问：最有用首先要加的控制是什么？
限定范围的 identity。大多数智能体风险是凭证风险，给智能体自己的最小权限服务账户绑定了每一次其他错误（包括一次成功的提示词注入）造成的损失。
问：那提示词级别的护栏没用吗？
不是没用，但它们属于与文档和 linting 相同的类别：它们改善了常见情况，但阻止不了对抗性情况。任何必须不发生的事属于 RBAC、策略或没有凭证的缺席。
提示词注入与普通注入有何不同？主要在于载荷。它是不可信输入到达特权解释器，这与你们已经在防御的形态相同。麻烦的是，解释器在指令和数据之间没有可靠的语法边界，因此转义和参数化这些常规修复手段都不可用。
我需要多智能体架构吗？通常一开始不需要。这是一个分布式系统，会带来协调开销、部分失败处理和 token 消耗。先从一个智能体起步，缩小工具范围，只有在单个循环明显成为瓶颈时才进行拆分。
如果已有 CLI，MCP 扮演什么角色？MCP 标准化了跨客户端的能力暴露，而 CLI 通常 token 消耗更低，且模型已经熟悉它。我们的比较深入分析了这种权衡；实践中大多数团队最终会同时运行两者。
原文发表于 devops-daily.com。