IBM TLS 多智能体平台架构与实践

IBM 技术生命周期服务（TLS）部门从零构建了一套生产级多智能体平台 TLS Agentic Platform，前端名为 TLS Concierge，自 2025 年秋季上线运行。该项目由 IBM Infrastructure 人工智能卓越中心（AI CoE）的一位高级架构师主导，目标是为数千名 TLS 员工提供一个统一入口，覆盖支持工单、硬件资产、合同、客户历史等原本分散在十几个系统中的查询场景。文章以一手工程视角回顾了关键架构决策与踩坑教训。

关键架构原则

平台采用 Python 与 LangGraph 编写智能体本身，并确立了清晰的分层协议边界：

• 智能体之间统一使用 A2A 协议，工具之间统一使用 MCP 协议。这一一致性使六个专业智能体中的五个得以由不同团队在各自环境中独立构建，仍能顺利对接。
• 用户身份需在每一跳中传递或交换，绝不能用服务账号替代。一旦某次委托丢失了调用方身份，授权就悄悄从企业模型滑向平台自有模型，事后修补代价极高。
• 可观测性先行：评估、追踪、业务指标必须先于构建落地，且应采用当下已有的工具，而非等待内部路线图稳定。

数据访问是真正的瓶颈

作者直言，真正的约束从来不是智能体代码本身，而是数据访问。尽管业界普遍追求"智能体工厂"式的团队产能，但 TLS 更需要的是一个"数据工厂"：定位系统记录、协商访问权限、构建工具层。早期 AI 成果（如 watsonx 驱动的 Agent Assist、自动化 Call Home 处理 91% 的硬件错误通知）证明了价值，却未形成可复用的平台基础；这部分基础设施正是作者入驻 TLS 第一年的主要工作。

团队独立与对齐的张力

统一的协议边界让新团队容易接入，但也让每个团队自然优先自己负责的 backlog。结果是，团队共同认可的一种更优推理模式被推出后，多数智能体至今仍未采用。这种"易扩展、难对齐"的现象，是企业级智能体平台规模化时绕不开的现实挑战。

业务背景与设计取舍

TLS 负责全球硬件与软件支持、运维及生命周期管理，体量庞大。其 AI 投资的目标不仅是工单解决率，更包括客户层面的真实结果。作者强调，文中所有架构决策都在真实服务组织、真实规模下做出：错误的智能体回答可能直接影响 IBM 客户，合规、审计、长时间运行等企业级约束从第一天起就是需求而非学术讨论。