@arcane_bloom: 从软件工程到智能体工程的转变：五部分解析 1/6 大多数开发者在构建AI时失败…

从软件工程到智能体工程的转变：5大核心变化

1/6 大多数开发者在构建AI智能体时失败，因为他们将其视为传统的微服务。他们把非确定性的智能强行塞进确定性的代码库，结果导致系统脆弱，一遇到人类的微妙之处就崩溃。

在这个系列中，我们将拆解旧的规则手册。你会看到为什么传统的软件模式——如硬编码路由、二元单元测试和“快速失败“错误处理——会直接“阉割“AI智能体。更重要的是，你会看到构建弹性、生产级智能体循环所需的具体架构转变（从“文本即状态“到“智能体就绪API“）。

让我们深入这5个核心思维转变。

2/6 转变1：文本就是新状态

传统软件工程追求安全、可预测和控制。我们本能地试图将现实世界映射成整洁的枚举、严格的类型和布尔值（如图中所示的is_celsius: true或status: "APPROVED"）。但把混乱的自然语言意图强行塞进这些僵硬的容器，会剥离关键的上下文。

解决办法？保持数据的原始和丰富。让下游的智能体去适应细微差别，而不是强制使用一刀切的状态。

3/6 转变2：交出控制权

在标准微服务架构中，用户意图直接映射到预定义的路由。我们严格编排工作流，规划出确切的逐步流程。但人类的交互是混乱的：他们会循环、回溯、改变主意，甚至在中途完全转向。

看看下面的客服聊天示例：客户说想取消订阅，触发了流失挽回流程。系统提出50%折扣，客户突然转向保留服务。如果你把那个流失挽回流程硬编码成僵硬的线性路径，系统将无法处理转向，你就失去了一个客户。

信任智能体去导航。提供约束，而不是流程。

4/6 转变3：错误只是输入

在标准开发中，我们“快速失败“，遇到模式错误就崩溃执行。但LLM智能体的运行既费时又费钱，在第4步崩溃（共5步）是不可接受的。

不要抛出传统的运行时错误，而要捕获异常，将其转换为字符串，然后直接送回智能体循环。让智能体自我纠正和恢复。

5/6 转变4：从单元测试到评估

二元断言（“成功了吗？是/否”）会失败，因为LLM输出是非确定性的。

不要再检查智能体是否使用了你期望的精确路径或工具。评估整体结果，而不是步骤。每个提示运行3-5次试验，衡量成功的统计分布，并大量依赖“LLM作为评判者“的框架。

6/6 转变5：智能体进化，API不变

人类级别的API通常是隐式和模糊的。但智能体是字面主义者，会对不明确的参数产生幻觉。

要构建一个“智能体就绪API“，你必须转向显式、自文档化的语义接口。冗长的文档字符串、类型化的变量和严格的命名约定，构成了智能体的运行时轨道。

来源：