为什么AI代理无法扩展：这是一个工程问题，而非AI问题

AI代理的扩展问题并非源于大语言模型（LLM）的能力不足，而是一个系统工程挑战。当代理从演示阶段进入真实用户环境时，基础设施的复杂性迅速凸显。

首先，用户行为的不可预测性是第一大障碍。当LLM直接面向消费者时，用户可能做出各种意想不到的操作，因此需要一层规划器来约束LLM的执行路径。当前许多工具如Claude Code、Cursor和Windsurf都采用了这种“计划-执行”模式：代理提出一个计划，然后在该计划内执行，而不是自由发挥。这种确定性防护栏能够有效防止用户“疯狂行为”导致的失败。

其次，数据可访问性是真正的瓶颈。超过90%的企业数据是非结构化的，包括合同、PDF、电子邮件和转录文件。目前的生成式AI项目仅利用了不到1%的企业数据。代理即使推理能力再强，如果无法访问所需数据，也只能给出基于“感觉”的错误答案。因此，构建一个高效的非结构化数据管道——包括数据分块、嵌入、治理和服务——是必须优先解决的问题。这是数据工程问题，而非模型问题。

第三，多代理协调带来了错误传播的挑战。当五个代理串联工作时，即使每个代理的失败率仅为5%，整体可靠性也会降至约77%。若代理B产生幻觉，其错误将沿着链条传播并放大。解决方案包括在每个代理跳转之间添加确定性验证、设置回退路径，并建立一个代理注册表以便发现和调度合适的代理。

第四，企业特定知识的融入是另一个关键挑战。LLM在第一天对你的业务一无所知。微调成本高昂且速度慢，RAG虽然成本较低，但依赖于稳健的数据管道。大多数公司在这一步停滞不前——代理在公共知识上表现良好，但在内部流程上失败。

最后，监控方面存在巨大缺口。传统APM工具（如Datadog、Grafana）仅监控延迟和错误，而代理监控需要跟踪决策质量：代理是否选择了正确的工具？计划是否合理？输出是否事实正确？目前这一可观测性层几乎没有现成工具支持。

为了应对这些挑战，文章提出了一个包含规划器/路由器、验证器、聚合器以及可观测性循环的架构。规划器将用户请求分解为子任务并选择专业代理；每个代理后接验证器进行确定性检查；聚合器合并结果并检测矛盾；可观测性循环提供决策审计和质量评分。

最终，团队需要将AI代理视为分布式系统问题，而非单纯的AI问题。确定性系统应包裹非确定性模型，而非相反。LLM提出方案，确定性代码决定执行。只有这样，代理才能从原型走向规模化生产。