《Why (Senior) Engineers Struggle to Build AI Agents》

过去几十年，工程师的职责是消除模糊，确保输入A加代码B等于输出C。传统软件工程讲究确定性，程序像交通指挥，完全掌控数据流向和时机。而构建AI智能体（Agent）则是概率性的，我们更像调度员，给LLM（大语言模型）指令，但模型可能绕路、迷失，甚至“走捷径”。

令人讶异的是，资历浅的工程师往往比资深工程师更快推出可用智能体。原因在于，资深工程师更难信任AI的推理和执行力，反而试图用传统思维“代码化”概率性，结果反而受限。

以下五个例子展示了传统工程习惯与智能体开发的冲突：

1. 文字即状态
传统工程用数据结构、严格类型定义世界，安全但死板。智能体则需用自然语言承载状态与意图，如用户反馈“计划不错，但请聚焦美市场”，不能简化为“批准/未批准”。文本保存了语义丰富度，支持动态调整。

2. 放手让渡控制权
微服务中用户意图对应固定路由，智能体只有一个自然语言入口，LLM根据工具和上下文决定流程。对话可能曲折，用户从“取消订阅”转为“接受折扣续订”，必须信任模型灵活应变，而非硬编码每个分支。

3. 错误即输入
传统软件遇错即抛异常终止，智能体执行耗时且成本高，失败不能一棒子打死。错误应作为新信息反馈给模型，引导其自我修正，确保任务继续完成。

4. 从单元测试到质量评估
单元测试适合确定性代码，智能体输出多样无标准答案，无法用传统断言验证。评估重点在可靠性（频率）和质量（内容、语气、准确度），并追踪中间步骤，管理风险而非消除概率。

5. 智能体进化，API需“傻瓜化”
传统API面向人类开发者，隐含语境丰富。智能体字面理解，模糊变量名会导致“幻觉”。必须用明确、详尽的参数名和文档，方便智能体准确调用。且智能体能即时适应API变化，不像传统代码一改API就崩。

总结：信任但验证
智能体开发要求放弃绝对确定，接受语义灵活性，借助自然语言存储状态，交出流程控制权。试图用传统确定性思维“代码化”概率性只会失败。正确做法是通过评估和自我纠错管理风险，打造韧性系统。知道何时用智能体，何时用传统工作流，也非常关键。

这场转变虽不易，但未来已明。工程师必须拥抱不确定，学会与概率共舞，才能驾驭智能体的无限可能。

原文：www.philschmid.de/why-engineers-struggle-building-agents