AI智能体技术债工程实践MCP软件开发
智能体工程的隐形技术债：10分钟造出一个Agent，公司却要为它养一个平台团队
智能体工程的隐形技术债
作者： Zohar Einy | 译者： 平川 | 发布时间： 2026-04-26
核心观点
- 构建智能体只需几分钟，但在生产环境中维护需要庞大的基础设施支持
- 智能体工程系统特别擅长积累技术债务
- 智能体代码只占系统最小的一部分，周边基础设施才是真正复杂的
- 2015年谷歌的"机器学习系统中的隐性技术债务"论文对智能体同样适用
传统ML vs 智能体工程
2015年，谷歌发表了"机器学习系统中的隐性技术债务"，其中那张著名的图片：一个标有"ML Code"的小方框，被庞大的基础设施模块所包围。
对于智能体，我们看到了相同的模式。智能体只是画面的一小部分，周围的基础设施才是真正复杂的。
智能体工程的七大基础设施模块
1. 集成（Integration）
智能体需要连接到实际系统：CI/CD、云提供商、事件工具、可观测性平台、代码库、密钥管理器等。
技术债务陷阱：
- 30个团队、200名工程师，每个团队都自己生成凭据
- 每个集成点都有单独配置、单独调试、各自有效时间表
- GitLab API升级时，每个团队独立调试相同问题
MCP的局限性： MCP为智能体提供了标准的工具调用方式，但它并不管理：
- 调用的凭证
- 返回数据的范围
- 当API变化时的处理
2. 上下文湖（Context Lake）
智能体的好坏取决于它们可引用的上下文。需要两种上下文：
运行时上下文：
- 服务信息、所有权、最近部署内容
- 不断变化：服务所有权转移、依赖项添加、配置值更新
决策痕迹：
- 之前做过的事情（人类或智能体完成）
- 为什么做出决策，以及之后发生了什么
技术债务陷阱：
- 上下文陈旧过时、支离破碎且无人负责
- 智能体重复人类/其他智能体已解决的错误
- 公司标准存在于维基中，智能体基于agents.md文件运行
3. 智能体注册表（Agent Registry）
问题：组织结构图在动态变化。现在不只是人，还有5-10倍数量的智能体。
典型模式：
- 工程师A构建了分诊智能体 → 团队使用
- 工程师B不知道A的存在 → 构建自己的版本
- 工程师C也构建类似的东西 → 但连接不同工具、有不同权限
技术债务陷阱：
- 责任重叠、行为冲突、依赖项不可见
- 智能体不可见，团队创建重复智能体
- CISO要求智能体审计时，没有一个列表可以入手
4. 向智能体传达指令
工程师们独立为智能体创建技能文件，但分散在不同存储库中时：
- 团队创建重复或不准确的技能
- 与平台分发的上下文相矛盾
需要传递的信息层次：
- 公司范围标准（安全编码、提交规范）
- 存储库特定指令\n- 团队级规则
5. 智能体创建
平台团队的责任：
- 智能体应有标准化的属性
- 应与公司其他实体建立连接
技术债务陷阱：
- 没有生命周期状态
- 没有所有者
- 没有与操作服务的连接
- 六个月后在生产环境运行，使用过期Token，找不到构建者
6. 度量（Metrics）
不同角色关心的度量不同：
| 角色 | 关心问题 | 度量类型 |
|---|---|---|
| SRE | 智能体做了什么 | 可观测性 |
| ML工程师/产品经理 | 变好了还是变糟了 | 评估 |
| 工程VP | 是否值得花钱 | 业务影响 |
| 最终用户 | 是否根据反馈学习 | 用户满意度 |
评估难点： 标准软件可以编写单元测试，判断确切字符串输出。智能体工程中，每个响应都不同，需要不同方法。
技术债务陷阱：
- 更改未经测试发布
- 输出质量悄无声息降低
- 用Opus替换Sonnet，PR审查智能体开始批准以前标记过的东西
7. 人机回环（Human-in-the-loop）
复杂场景需要人类介入：
- 高影响决策
- 模糊场景
- 合规要求
解决建议
- 集中管理集成，而非每个团队独立配置
- 建立上下文管理器，统一处理运行时上下文
- 创建智能体注册表，确保可见性和标准化
- 实施智能体模板，确保每个智能体具备基本要素
- 建立评估体系，跟踪智能体质量变化
结论
构建智能体很容易。但在生产环境中，智能体代码只占系统最小的一部分。周边的一切——集成、上下文、注册表、度量、治理——才是真正复杂的。
几乎每个员工每天都在创建新的智能体。很快，你拥有的智能体将比员工还多。如果没有适当的基础设施和管理，技术债务将快速积累。
原文来源：InfoQ | 原文：THENEWSTACK | 汇总时间：2026-04-27