为什么这个领域重要

如今的生产智能体早已不靠单条提示运行。它是拼装出来的——检索模块、工具调用模块、安全护栏、摘要器、若干子智能体，全部以系统提示和工具定义的形式层层叠进同一个上下文。问题在于，这样连接起来之后，给某个模块的指令会渗漏到相邻模块。2026年6月发表于arXiv的论文《Instruction Bleed: Cross-Module Interference in Prompt-Composed Agentic Systems》(2606.26356) 正面探讨了这一现象。你在一个模块里写下"简洁作答"，本应毫无关联的安全校验模块却开始草草跳过检查。智能体在生产环境中那些无法解释、从未在演示里出现的失败，很大一部分都能追溯到这里。

根本原因在于，大模型把所有文本几乎以同等权重来读。正如OpenAI在《The Instruction Hierarchy》中指出的，模型本来就把开发者的系统提示、用户输入和工具输出当作同一优先级来对待。模块越多，越难控制哪条指令侵入了哪条，一行改动就可能在系统的另一端引发回归。于是，除了把模型做大之外，还分化出一个专门的角色，负责保证这套拼装好的系统真正按预期隔离运行。这就是智能体可靠性工程师——守护的是系统可信度而非模型精度。在多模块智能体成为常态的今天，这个岗位正迅速固化为一项专门的工种。

所需技能

这份工作处在SRE式可靠性工程的直觉与大模型系统特有的非确定性控制之间的交叉点上。它既不是造工具，也不是搭编排——而是在拼装好的模块之间划出边界，让它们彼此不互相污染，再不停地度量这些边界是否守住。

• 提示模块隔离。 不把每条系统提示、工具定义和子智能体指令都塞进同一个上下文，而是用清晰的边界把它们分开。设计每条指令的作用域延伸到哪里，并阻止无关模块继承彼此的语气、策略或约束。
• 指令作用域与权限。 分离受信任的系统指令、用户输入与工具返回文本的权限层级。把指令层级（instruction hierarchy）的概念翻译成具体的提示结构，使低权限文本无法覆盖高权限策略。
• 干扰评估框架。 构建回归套件，自动捕捉"改动模块A的指令会扰动模块B的行为"这类情况。把黄金集、场景用例与对抗用例接入CI，使一行提示修改一旦破坏了远处的模块，构建立刻亮红灯。
• 运行时防护。 在部署之后仍保留运行中的防线：拦截疑似指令泄漏的输出，检测策略违规，对跨越模块边界的异常行为施加熔断与回滚。
• 可观测性。 追踪每一次模块调用与每一个指令注入点。一旦出现故障，你必须能事后读出究竟是哪个模块的哪条指令渗漏到了哪里。

职业路径

需求明确，供给却很薄。把智能体做到演示阶段的人很多，但从可靠性视角调试过几十个模块相互纠缠的生产系统的人却很少。招聘的关键在于：你能不能解释并预防"演示能跑，可一加上某个模块，毫不相关的地方就坏了"。这使它成为一个尴尬的交叉点——既不是普通的后端工程师，也不是纯粹的机器学习研究者，而是在SRE和平台经验之上叠加了大模型系统直觉的中高级工程师。

入行有两条路。一是从SRE、平台或可靠性工程师起步，接手内部智能体基础设施，再转向非确定性控制；二是从AI工程和提示工程一侧切入，向下深入到评估与运行时安全这一层。头衔尚未定型，散落为Agent Reliability Engineer、AI Reliability Engineer、Agent Safety Engineer等。由于技能稀缺，越来越多团队给出比同级软件工程师高出10%~20%的薪酬。在BAT这类大厂还是刚拿到A轮的创业公司，只要把智能体推上了生产环境，这个角色就不再是可选项，而成了平台团队的固定职责。

最快的验证方式是亲手把它弄坏。搭一个只有三四个模块的小智能体，故意往一个模块里塞进强指令，量一量其他模块的输出如何被污染。接着修好隔离与作用域，把干扰回归套件接进CI，再给输出加上运行时防护。完整跑通这一轮的经历，胜过简历上任何一个关键词。