智能体工程的七大隐藏技术债

如今，任何人都能轻松在本地构建一个智能体。调用几次 LLM、写个提示词、定义几个工具，几分钟内这个智能体就能开始干活。但当它需要投入生产环境，被整个工程部门使用，处理真实数据和承担实际后果时，会发生什么？

2015 年，谷歌发表了《机器学习系统中的隐藏技术债务》论文。这篇论文为机器学习工程师们点明了他们正在经历的所有问题，其中分享的图表也成了经典：一个标着“ML 代码”的小盒子，被庞大的基础设施区块包围。

我们看到智能体领域出现了同样的模式。智能体只是整个图景中的一小部分，我们想给它们周围的所有基础设施命名。

智能体工程系统尤其容易堆积技术债务。它们既承载了传统软件的所有维护问题，又额外增加了一套智能体特有的问题。几乎每个员工每天都在创建新的智能体。很快，你拥有的智能体数量将远超员工数。

我们将智能体定义为任何具有动态决策能力、能够通过推理和反思自主决定工具使用和执行路径的流程。决策、推理和反思都需要所有支持性基础设施。

构建智能体很容易。但在生产环境中，智能体代码只是系统中最小的部分。真正的复杂性存在于它周围的一切。

过去几个月，通过与工程负责人交流以及我们自身的经验，我们梳理出了围绕智能体的七大基础设施区块。每一块都是构建演示时没人会规划的工作类别。

如果你做过传统工程，其中一些区块会看起来很熟悉：可观测性、集成和治理。另一些则是智能体独有的，例如人机协同、非确定性系统的评估以及智能体注册表。

我们来逐一看看。

1. 集成

智能体需要连接到你的实际系统：CI/CD、云提供商、事件工具、可观测性平台、代码仓库、密钥管理器等等。

没有集中化的集成，每个团队都会为自己的智能体单独接线。

想象一个拥有 200 名工程师、30 个团队的工程组织，每个团队都有多个智能体。每个工程师都会为自己的编码智能体生成 GitLab PAT，为数据智能体生成 Snowflake 凭证，为部署智能体生成 Kubernetes 服务账户，为事件智能体生成监控令牌。

这就是成百上千个集成点，每个都单独配置、单独调试，并按照自己的时间表过期。

当每个开发者都用自己的凭证接线时，每个智能体根据它使用的是谁的令牌，会看到不同的数据。一个开发者的 GitLab PAT 能访问所有仓库。其他人的权限则仅限于其团队。同样的智能体类型，每个对组织的视图却完全不同。

或者，当 GitLab 对其 API 做出破坏性变更时会发生什么？每个独立接线的团队都会调试同一个问题（或者向平台团队提交工单）。三个团队在周一搞定。周三前又有两个团队解决。一个团队因为他们的智能体只在事件期间运行，一周后才发现问题。

通过这些集成传递的内容也很重要。当三个团队通过不同路径连接到同一数据源时，他们的智能体对同一个问题可能得到不同的答案。如果一个团队的集成拉取的是 30 天的部署历史，而另一个团队的集成显示的是过去 3 年的所有内容，他们的输出就会不同。

目前，MCP 是大多数团队将智能体连接到工具的方式。但我们不要把 MCP 和集成混为一谈。MCP 为智能体提供了一种调用工具的标准方式。它并不管理该调用的凭证、返回数据的范围，或者当另一端的 API 发生变化时该怎么办。

集成中的隐藏技术债务看起来像这样：

• 一个集成认证令牌在周五晚上过期，事件智能体静默停止工作。直到周一才有人注意到。
• 五个团队各自维护自己的 GitLab 连接，权限和范围各不相同，却不知道其他连接的存在。
• 当一个集成更新其 API 时，每个团队都单独调试自己的连接。

2. 上下文湖

智能体的能力取决于它们能够引用和使用的上下文。它们需要两种上下文。

运行时上下文：如何在智能体执行期间向其提供准确的上下文？

运行时上下文是智能体在特定执行过程中所需的实时数据，例如关于服务的信息、谁拥有它们以及最近部署了什么。这与人类在编码或解决事件时使用的数据类似，但对智能体来说更易获取。

想象一个编码智能体接手一个为服务添加重试机制的任务。它需要知道：该服务使用什么语言和框架，本组织中其他服务如何处理重试，它调用的下游服务归谁所有，以及超时设置最近是否有配置变更。

有些团队在 Markdown 文件中管理他们的运行时上下文：agents.md、.cursorrules、技能文件。

Markdown 文件对于静态指令来说没问题，比如如何格式化提交或使用哪个 linter。但运行时上下文是不断变化的。服务所有权会转移。依赖项会增加。配置值会更新。部署每小时都在发生。一个运行在 .md 文件上的智能体，如果文件写着“checkout-service 归支付团队所有”，它不会知道所有权在上周二已经转移给了商务团队。文件在编写时是准确的。等到智能体读取它时，可能已经过时了。

决策轨迹：如何帮助智能体从自己过去的工作或其他智能体的工作中学习？

决策轨迹是记录之前（由人类或智能体）做了什么、为什么做出该决定以及之后发生了什么的历史。没有这个历史可供参考，每次智能体运行都从零开始。想象一个智能体打开一个 PR 来修复一个不稳定的测试。它不知道另一个智能体上周尝试了同样的修复，PR 因为破坏了下游合约而被拒绝，团队决定完全弃用该测试。于是它重新打开了同一个 PR。没有决策轨迹，智能体会重复人类（或其他智能体）已经解决的错误。

一个解决了 50 起事件的智能体，已经见过新智能体没见过的模式，比如哪些修复有效，哪些导致了回归，哪些服务在部署后变得脆弱。没有轨迹，这些知识在每次运行后就消失了。当多个智能体在同一系统上操作时，它们看不到彼此的历史。

LLM 提供商开始通过可以跨团队共享的 memory.md 文件来解决这个问题。但当你有几十个智能体在运行时，债务仍然会出现。你需要找到一种方法，可靠地将这些记忆（或者只是其中正确的部分）提供给特定的智能体。

上下文湖中的隐藏技术债务看起来像这样：

• 陈旧、碎片化且无人负责的上下文
• 智能体运行在 agents.md 上，而公司标准却存放在 wiki 中
• 智能体无法了解其他智能体如何以及为何解决了问题，或者它们犯了什么错误

3. 智能体注册中心

搞清楚到底有多少智能体在跑

公司架构正在改变。除了员工，你现在拥有的智能体数量可能是员工的5到10倍。它们每天都在被员工创建出来，在没有安全护栏（Guardrails）的情况下运行，能访问关键基础设施，还能做决策。它们还分散在 Claude Code、Cursor、n8n、Zapier、Notion、AWS、GCP 等各种工具里。

典型的情况是这样的：一个工程师建了个分类智能体，他的团队开始用它处理故障。另一个团队不知道这个智能体已经存在，又自己建了一个。第三个团队也建了个类似的，但连的是不同的工具，权限也不一样。

在一个有20到30个工程团队的公司里，你很快就会遇到职责重叠、行为冲突、依赖关系不明的智能体。在团队之间共享智能体之前，你首先得知道它们存在。

给智能体下发指令

一旦你掌握了智能体的全貌，它们就需要一份“员工手册”：标准、技能（Skills）以及它们应该如何运作的指令。

现在，工程师们各自为他们的智能体创建技能文件。问题是，当这些文件分散在各个仓库（Repository）里，没有集中视图时，团队最终会创建重复或不准确的技能。这些技能常常与平台分发的上下文（Context）相矛盾。平台团队比单个团队更清楚应该在技能文件里写什么。

那么，如何将一致但又个性化的编码规则、命令、技能和钩子（Hooks）准确地下发给对应的智能体呢？

这些信息甚至可能需要多个层级：

• 全公司通用的标准（安全编码、提交规范）
• 仓库特定的指令（“在这个仓库里，事件要这样创建”）
• 或者针对部分工程师的团队级规则

你需要找到一种方法，可靠地将这些信息分发给成千上万个智能体，确保正确的指令到达正确的智能体。

智能体创建

假设你已经掌握了大部分现有智能体的信息，并给它们下发了指令。下一个问题是：你如何在不拖慢团队速度的前提下，控制新智能体的创建过程？

这个责任现在落到了平台团队身上。

就像软件目录里的服务一样，智能体应该有标准化的属性，并且应该连接到公司里的其他实体，比如其他智能体、团队、服务、部署（Deployment）等。

没有模板，你就会重蹈覆辙，再次陷入刚才解决的混乱局面。一个工程师启动了一个智能体，没有所有者，没有生命周期状态，也没有连接到它所操作的服务。对他自己来说能用。但没人知道它的存在。六个月后，有人发现它还在生产环境运行，用的令牌（Token）已经过期，而且找不到当初创建它的人。

“一个工程师启动了一个智能体，没有所有者，没有生命周期状态，也没有连接到它所操作的服务。对他自己来说能用。但没人知道它的存在。”

智能体的创建应该遵循一个标准化模板。这并不意味着员工创建智能体时应该被拖慢。恰恰相反。通过标准化的创建流程，他们能比各自为战更快地达到高质量的工作水准。

智能体创建应该允许从工程师的工作站发起。如果他们在 Cursor 里工作，需要启动一个智能体，他们应该能在 Cursor 里完成，而不是去别的地方。这意味着，作为平台工程师，你的工作就是确保在任何地方创建的智能体都遵循你的创建流程。

模板并不限制智能体做什么。它只是确保每个智能体在诞生时就具备基本要素：所有者、描述、使用的工具、接触的服务以及生命周期状态。正是这些要素，让它从第一天起就是可治理的，而不是你以后需要费力追踪的东西。

智能体注册中心里的隐藏技术债务看起来是这样的：

• 看不见的智能体
• 团队在创建重复的智能体
• 过时的上下文
• 当首席信息安全官要求进行智能体审计时，却连个清单都没有
• 没有明确的将智能体提升到生产环境的方法
• 没有版本控制、回滚或预发布环境

4. 度量

你怎么知道你的智能体是否在工作？嗯，这取决于谁在问。

SRE 想知道智能体做了什么。

机器学习工程师或产品经理想知道它是变好了还是变差了。

工程副总裁想知道它值不值这个钱。

最终用户想知道智能体是否根据他们的反馈在学习。

所以，虽然每个人都想度量智能体的某些方面，但他们想要的是不同类型的度量。

1. 你怎么知道你的智能体在做什么？

这是可观测性（Observability）。

事件、追踪和日志显示了智能体采取了哪些行动，访问了哪些数据，以及它是否仍在正确运行。工程团队从传统系统就理解可观测性，但对于智能体，可观测的表面更广。

假设你有一个能自主解决 Jira 工单的智能体。当它收到一个 Jira 工单时，它会读取服务目录找到相关仓库，通过 GitHub 集成拉取最近的提交，用编码智能体生成修复方案，在 GitHub 中打开一个 PR，并向它在软件目录中找到的服务所有者请求审查。如果这个修复搞砸了什么，是哪一步出了问题？是拉错了仓库？读错了所有者信息？还是生成了糟糕的代码？

如果你无法追踪整个链条中的每一个环节，那就别想调试它了。

2. 当提示（Prompt）、技能、工具和模型发生变化时，你怎么知道你的智能体是变好了还是变差了？

这是评估（Evals）。

在标准软件工程中，你可以写一个期望精确字符串的单元测试。在智能体工程（Agentic Engineering）中，每次响应都不同，你需要不同的方法。

评估回答一个简单的问题：在你改变了某些东西（比如提示或模型）之后，智能体是否仍然表现良好？

没有方法来追踪这一点，变更就会未经测试就发布，输出质量会无声无息地下降。就像把 Sonnet 换成 Opus，结果你的 PR 审查智能体开始批准它以前会标记的东西。

3. 你怎么知道你的智能体是否真的对你的业务有效？

这是业务影响。

今年的每一次财报电话会议都会包含这个问题：“AI 为你的业务做了什么？”

大多数工程领导者现在还无法回答，而最终，他们才是负责度量智能体成本和投资回报率（ROI）的人。

追踪支出是这个等式中比较容易的部分。你可以按智能体、按团队追踪令牌使用量、API 调用和计算成本。

投资回报率更难衡量。智能体解决了多少工单？节省了多少工程时间？是真的降低了平均修复时间（MTTR），还是只是把工作转移了？这些数字更难收集，也更难让人信服。如果你只能展示成本面，却无法展示清晰的投资回报率，那将是一场糟糕的对话。

4. 你如何给智能体的工作提供反馈？

这些是反馈循环（Feedback Loops）。

当智能体生成一个 PR、解决一个工单或写一份根本原因分析（RCA）时，审查它的人类是接受了输出还是纠正了它？这通常用点赞或点踩来管理，但有时人类本身的回应就算作反馈（比如“不，再试一次，但这次要改 X 而不是 Y”）。

它们对于改进智能体至关重要，甚至比评估更重要。处于演示阶段的智能体要么不收集这些信号，要么不据此采取行动。

度量中的隐藏技术债务看起来是这样的：

• 不知道智能体性能是随时间改善还是下降，以及和什么相比
• 无法度量当提示或模型改变时会发生什么
• 领导层要求提供投资回报率，但你没有一个清晰的答案
• 未能收集使用智能体的人类用户的反馈

5. 人机协同（Human-in-the-Loop）

在完全手动和完全自主的工程之间有一个光谱。一端，人类做所有事。另一端，智能体不问就行动。大多数有用的智能体都处于中间某个位置，具体在哪里取决于行动、环境和风险。

人机协同是让你能安全地将智能体推向更自主的机制之一。它让你可以定义检查点：这个行动需要批准，那个不需要，这个则取决于环境。智能体运行，但人类在高风险的决策执行前进行确认。

例如，一个部署（Deployment）智能体可能在预发布环境自由运行，但在生产环境需要批准。它可以在工作时间完全自主，但在凌晨三点我们需要人机协同。规则是有条件的，因智能体、行动、环境和团队而异。

当你只有一个演示用的智能体时，你可以把批准检查点硬编码成一个在部署前 ping Slack 的 if 语句。但当你有 20 个团队的 100 个智能体时，硬编码的批准逻辑就无法扩展了。每个团队都实现自己的版本。一个团队的智能体不问一声就回滚生产环境。另一个团队的智能体做同样的事却需要三次批准。没人集中定义这些，所以没人知道哪些智能体可以自主行动，哪些不行。

然后还有批准流程本身的编排（Orchestration）。通知谁？通过什么渠道？如果没人回应，超时时间是多少？如果审批人休假了怎么办？如果一个智能体的批准通过 Slack，另一个通过邮件，第三个通过自定义 UI，那么你现在就有三个批准系统要维护。围绕批准的逻辑本身就成了主要的技术债务，与智能体本身是分开的。

如果我们拉远视角，人机协同也关乎了解所有为我们工作的智能体内部正在发生什么。随着工程师更多地转向（智能体的）管理角色，他们将需要一个控制平面（Control Plane）来查看正在进行的工作，启动智能体工作，识别哪些智能体需要关注，并在需要时采取行动。

这一点很重要，因为人机协同是你大规模应用变更的方式（而今天的公司不变则死）。为了胜任新工作，工程师需要能看到智能体在工作，就像他们过去能看到自己的代码在工作一样。一个能看着智能体处理前十个部署（看到每一步，审查每一个决定，并在需要时干预）的团队会信任那个智能体。一个不能这样做的团队，则根本不会信任。

人机协同中的隐藏技术债务看起来是这样的：

• 硬编码的批准代码无法从一个地方统一修改
• 有些智能体在没有批准的情况下运行，另一些则有太多批准
• 多个通过邮件、Slack 和自定义 UI 的批准系统互不兼容
• 没有共享的工作空间让团队能看到他们的智能体在做什么并在必要时干预

6. 治理

人类工程师要访问生产数据库，得走流程：提交申请、有人审批、权限限定、操作留痕。可能花一小时或一天，但谁有权访问什么、谁做了什么，都有记录可查。

工程师在本地创建智能体时，情况就不同了。它通常直接继承创建者的权限：他们的 API token、服务账号、云权限。很可能没人审查过这些权限的范围。

智能体的治理规则必须具体明确：

• “只有在发生高严重性事件时，才允许回滚服务。”
• “部署到生产环境必须手动审批，无论由哪个智能体触发。”
• “从外部系统拉取数据的 RCA 报告，只能对相关服务的负责人可见。”

这类规则需要平台团队在统一的中心位置定义，并应用到所有智能体上。

治理的另一面是执行。假设你发现某个内部 API 存在漏洞，需要立即阻止所有智能体调用它。你能做到吗？理想情况下，一位安全工程师应该能在一个地方禁用某个工具，并让它自动在所有智能体中失效。目前，大多数公司还不具备这种能力。

权限配置很难从一开始就做到天衣无缝。一旦出问题，你需要知道发生了什么：是哪个智能体执行了操作、访问了什么数据、使用了什么凭证、由谁触发。大多数智能体设置无法提供这样的审计追踪（本地创建的尤其如此）。本地运行的智能体继承其创建者的凭证，因此每个操作看起来都像是工程师的个人行为。如果三个智能体共享一个服务账号，你无法分辨是哪个发起了调用。如果一个智能体通过另外两个智能体链式调用后修改了生产配置，审计日志可能只显示最终的写入操作，而看不到其推理过程、上下文或导致该操作的决策链。

治理的另一个方面是成本治理。智能体往往会持续工作，不管它们正在累积多少成本。工程师在本地创建智能体时，很可能不会想到设置成本上限。

一个陷入重试循环或原地打转的智能体，可能会持续消耗 token 数小时，直到有人手动终止它，或者直到月度账单显示出损失。大多数团队能告诉你他们的 LLM 总支出，但几乎没人能按智能体、按团队或按用例细分。团队也应该能轻松查看自己的成本状况。因为当领导层问起运行智能体花了多少钱时，工程团队需要给出答案。

治理方面的隐藏技术债务表现为：

• 不该在生产环境运行的智能体，访问了生产数据
• 一个 RCA 智能体将敏感服务数据发布到了共享频道
• 智能体在公共论坛发布了个人身份信息（PII）
• 无法从一个地方禁用所有智能体中的某个工具
• 没有智能体操作记录或原因追踪

7. 编排

大多数智能体工作流并非纯粹的智能体，而是智能体、工具和人员的混合体。债务不在于单个步骤，而在于步骤之间发生的事情：路由、故障处理和权责归属。

节点之间会出什么问题

以上图的事件响应工作流为例。警报触发，分诊智能体接手，调查并确定根本原因是部署问题。它转交给部署智能体来回滚变更，然后验证智能体检查修复是否生效。

现在假设分诊智能体判断错误。真正原因是数据库超时，而非错误部署。部署被不必要地回滚，数据库问题持续存在，警报继续触发。最终，人类介入并从零开始调试，但此时他们还得清理本不该发生的回滚。故障并非悄无声息，工作流自信地执行了错误操作，却没人能说清错误的决策点在哪里。

这就是编排债务在实践中的样子：不一定是工作流停止，而是工作流做了错事且难以追溯。

之后每增加一种新问题类型（如安全事件、配置漂移或依赖故障），都会让路由更难以测试和解释。这些变更本身都不难，但当没人负责决定它们如何连接时，每次都会以不同的方式拼凑在一起。

与传统工作流编排有何不同

工作流编排并不新鲜。多年来，团队一直在 CI/CD 流水线、Airflow 和 Step Functions 中串联步骤。那为什么智能体编排成了新问题？

传统工作流是确定性的。步骤 A 产生已知输出，步骤 B 消费它。你可以测试每条路径，因为你知道所有路径。智能体工作流在原本确定性的链条中引入了非确定性。当你用一个能对问题进行推理的智能体取代操作手册时，每个下游步骤都变得不可预测。你无法测试每条路径，因为你不知道所有路径。

智能体之间也没有契约。服务有带模式和版本化端点的 API。两个智能体相互交接时，靠的是提示词和自然语言。这种“接口”是模糊的。一个智能体的模型更新或提示词变更，可能使其输出发生细微偏移，足以破坏链中的下一个智能体。

例如，部署流水线应该是完全确定性的。触发器启动，系统知道严重性，部署到预发布环境，人工审批，进入生产环境，验证智能体检查健康状况。步骤是预定义的，顺序是固定的，风险足够高，你希望它如此。

事件响应工作流本质上是非确定性的。根本原因可能是错误部署、数据库问题、配置错误，或是前所未见的情况。智能体必须调查并决定下一步做什么。

大多数工程团队需要这两种工作流。债务在于，没有关于何时使用哪种的共享规则。一个团队将所有分诊结果直接发送给编码智能体，另一个团队则在任何自动化修复前都要求人工审核。两者各自为政，直到某个事件跨越团队边界，两种方法发生冲突。

谁拥有工作流？

即使每个单独的智能体都有所有者，这也不够。编排本身需要一个所有者。

当一个智能体修改了服务并导致故障时，谁负责？是智能体的所有者还是服务所有者？当一个工作流跨越三个团队时，哪个团队拥有最终结果？当一个步骤在链中失败时，是由失败的智能体负责重试，还是由工作流负责重新路由？

这些不是理论问题。它们是凌晨两点，当智能体驱动的工作流误入歧途，三个团队在作战室试图弄清楚谁的智能体做了什么时会遇到的问题。单个步骤失败很容易调试。但要找出三个交接步骤前，是哪个决策将工作流引向了错误路径——这需要大多数组织尚未构建的追踪能力。

“…当智能体驱动的工作流误入歧途，三个团队在作战室试图弄清楚谁的智能体做了什么。”

编排方面的隐藏技术债务表现为：

• 智能体在工作流中途失败，直到下游影响显现才被发现
• 无法跨智能体追踪决策回到原始触发点
• 工作流跨越三个团队，但没有团队对结果负责
• 一个智能体的模型或提示词变更，悄无声息地破坏了链中的下一个智能体

债务何时显现

这种隐藏的技术债务会在特定的触发点变得棘手。

在探索阶段，没有债务。一个工程师，一个智能体，运行良好。但当团队开始将智能体用于实际工作时，集成和上下文（Context）会首先出问题。智能体访问了不该看到的客户数据，因为没人限定其凭证范围；智能体猜错了服务负责人，因为它没有相关上下文。

当多个团队独立运行智能体时，债务会更快堆积。智能体注册、度量和人机协同（Human-in-the-Loop）问题会同时浮现。在这个阶段，团队大约 50% 的精力将用于构建周边基础设施。

达到生产规模（智能体嵌入到工程组织的大部分环节）时，治理和编排成为优先事项。有些公司预见到了这一点。一位架构师告诉我：“我们从经验中知道混乱必然存在，我们会从第一天起就努力避免它。”另一些公司则付出了代价：一位平台工程副总裁看到团队各自构建相同的智能体，不得不在蔓延已成事实后，再回头补治理。两者最终都会构建相同的基础设施，区别在于一个是先付钱，一个是后付钱，而且可能付两次。

微服务时代曾发生过

当前时刻与微服务的演进过程相似。每个团队选择自己的技术，搭建自己的基础设施，最终必须有人介入创建标准。现在，围绕智能体，正在发生另一个平台工程时刻。

平台工程过去是一项提升速度的举措：自助服务、减少工单负载、为新服务提供脚手架。对于智能体，它仍然关乎速度，但平台团队是在追赶。工程师们没有等待，他们随时可以在 Cursor 或 Claude Code 中启动新的智能体。平台团队的首要任务是识别已存在的智能体，并将其纳入管控。只有这样，他们才能做他们一直在做的事：让其他人更快、更安全、更容易地创建和使用智能体。

一个开发体验（DevEx）团队这样向我描述他们的新角色：“我们不会成为设计和创建智能体的人。我们的责任是确保开发者知道如何使用它们，能进行适当的交互，并帮助更多团队创建自己的智能体。”

该怎么办

从可见性开始。审计你的 GitHub 组织中与 AI 相关的工作流和 Actions。检查你的团队在 Claude、OpenAI 或 Bedrock 上有多少活跃的 API token。查看你的工作流工具中任何带有 AI 节点的内容。目标不是完美的清单，而是第一次清点。

更棘手的问题是就什么算作智能体达成一致。一个 GitHub Actions 自动化 算智能体吗？一个 Claude Code 定时任务算吗？一个带有 AI 节点的 n8n 工作流算吗？在分类之前，你需要一个可行的定义。它不必完美，但你的组织需要就此达成一致。

还有集中化与民主化的问题。平台团队应该构建一切，开发者直接使用吗？还是平台团队提供安全护栏（Guardrails），让各团队自行构建？两种模式都存在。这可能取决于你的文化能容忍多少控制。

你可以现在就构建这套基础设施，也可以在某个智能体泄露客户数据、一夜烧掉 300 美元 token、或悄无声息地回滚了没人让它碰的生产服务之后，再开始构建。无论如何，你最终都得构建它。唯一的问题是，你是在痛苦来临之前构建，还是在痛苦来临之后构建。