Agent 运行成功了，但维护计划失败了。
利益相关者喜欢看到 AI Agent 完成复杂的任务。 但在六个月后维护同样的任务则是另一场战斗。
我见过许多在演示时表现出色的 Agent 系统。 但在部署后却成了运维方面的头痛问题。 问题不在于模型质量。 问题在于架构。
大多数项目都从小规模开始。 你连接一个模型。 添加几个工具。 第一个版本运行良好。
然后需求发生了变化。 Agent 需要 CRM 数据。 它需要工单系统。 它需要内部文档。 它需要计费系统。 它需要安全控制。
简洁的架构变成了混乱的集成。 每一个新工具都会增加一个依赖项。 复杂度在缓慢增长。 团队往往会忽略这一点。
大多数团队会估算构建需要多长时间。 很少有人会估算维护需要多长时间。
你添加的每一个工具都需要：
- 身份验证逻辑
- 错误处理
- 权限控制
- 监控
- API 版本管理
架构图看起来没问题。 但运维负担却并非如此。 维护成本的增长速度超过了工具数量的增长速度。
不要问一个 Agent 可以使用多少工具。 要问你的团队可以维护多少工具。
只有保持可靠，一项能力才真正有效。 一个每周都会崩溃的集成算不上什么功能。 它只是一个带有用户界面的技术债。
简单具有长期价值。 一个依赖较少的较小系统往往更胜一筹。 它易于理解。 易于理解的系统更容易修复。 它们更容易保障安全。 它们更容易扩展。
架构必须为生存而优化。 在添加集成之前，请问自己一个问题： “这能带来什么样的业务成果？”
如果答案不明确，就不要添加。 复杂度会产生复利效应。 复杂度不会预先宣告自己。 它会等到第六个月才让你的系统崩溃。
Source: https://dev.to/nolanvale/the-agent-worked-the-maintenance-plan-didnt-3f2l
Optional learning community: https://t.me/GyaanSetuAi