在当今的技术环境下，构建一个智能体已不再是一件复杂的事情。通过调用一些大型语言模型（LLM）、设计提示和定义工具，个人可以在短时间内创建一个能够完成实际任务的智能体。然而，当这些智能体进入生产环境，被整个工程部门使用，并开始处理真实数据和产生实际影响时，情况就变得复杂起来。
谷歌在2015年发表的关于机器学习系统中隐性技术债务的论文，为机器学习工程师指明了方向，揭示了他们所面临的一系列问题。论文中的一张经典图片显示，一个标有“ML Code”的小方框被庞大的基础设施模块所包围。如今，智能体也面临着类似的挑战。智能体只是整个系统的一小部分，而围绕它们的基础设施却异常复杂。
智能体工程系统特别容易积累技术债务。它们不仅需要应对传统软件的所有维护问题，还要面对智能体特有的挑战。几乎每个员工每天都在创建新的智能体，导致智能体的数量迅速超过员工数量。智能体被定义为具有动态决策能力的进程，能够通过推理和反思自主确定工具使用和执行路径。然而，决策、推理和反思都需要辅助性的基础设施支持。
构建智能体相对容易，但在生产环境中，智能体代码只是系统的一小部分。周边的基础设施才是真正复杂的部分。根据与工程领导者的对话和自身经验，围绕智能体有七个关键的基础设施模块需要关注。这些模块包括可观测性、集成、治理等传统工程项目中熟悉的领域，也包括人机回环、非确定性系统评估和智能体注册表等智能体项目特有的模块。
集成是智能体需要连接实际系统的重要环节，包括CI/CD、云提供商、事件工具、可观测性平台等。如果不集中管理集成，每个团队都会自行设置智能体连接，导致数百个集成点，每个都需要单独配置和调试。当GitLab的API发生重大更改时，每个独立创建连接的团队都需要调试相同的问题，这不仅耗时而且低效。通过集中管理集成，可以避免这些问题，确保智能体的稳定运行。
智能体注册表是记录和管理组织中所有智能体的系统。随着智能体数量的迅速增加，如果没有一个集中的注册表，团队就会创建重复的智能体，导致责任重叠和行为冲突。智能体注册表不仅有助于了解存在哪些智能体，还能为智能体提供标准、技能和期望的操作指令。这类似于为员工提供员工手册，确保智能体按照统一的标准运行。
智能体的创建过程也需要标准化。智能体应该有标准化的属性，并与公司的其他实体建立连接。如果没有模板，工程师可能会创建没有所有者、生命周期状态或服务连接的智能体。这些智能体可能在生产环境中运行多年，使用过期的令牌，却无法联系到构建者。因此，智能体创建应该遵循标准模板，确保每个智能体都具备基本要素，从第一天起就可以进行管理。
度量是评估智能体性能的重要手段。工程团队需要了解智能体的可观测性，包括事件、跟踪信息和日志记录。机器学习工程师和产品经理则关注智能体是否变得更好或更糟。工程副总裁关心智能体的成本效益，而最终用户则希望智能体能够根据反馈进行学习。因此，度量智能体需要从多个角度进行，包括可观测性、评估、业务影响和反馈循环。
人机回环是确保智能体安全运行的重要机制。它允许在关键决策点引入人类审批，确保高风险决策在执行前得到确认。然而，当多个团队使用多个审批系统时，审批逻辑就会变得复杂且难以管理。因此，需要集中管理审批逻辑，确保审批系统的兼容性和一致性。这有助于建立团队对智能体的信任，促进智能体的大规模应用。
治理是确保智能体合规运行的关键环节。智能体需要遵循特定的规则和标准，如访问权限、数据保护等。平台团队需要在一个地方集中定义这些规则，并应用于所有智能体。治理还包括执行层面，如禁止所有智能体使用某个工具或追踪智能体的行动。成本治理也是治理的一部分，确保智能体不会无限制地消耗资源。
编排是管理智能体工作流的重要手段。智能体工作流通常混合了智能体、工具和人，债务不在于个别步骤，而在于步骤之间的事情。路由、故障处理和所有权是编排中的关键问题。传统工作流是确定性的，而智能体工作流则是非确定性的，引入了推理和决策的不确定性。因此，需要建立追踪机制，确保能够从跨智能体的决策追踪到原始触发器。
