微软工程师：90%的AI项目死在"提示面条"架构上

去年有个数据在硅谷工程师圈悄悄传开：某头部云厂商的内部复盘显示，接入大语言模型（LLM）的生产项目中，73%在三个月内因架构问题被迫回滚或重构。不是模型不够聪明，是工程师把"能跑通的脚本"当成了"能扛事的系统"。

Aman Raghuvanshi在微软做了七年分布式系统，现在专门帮团队把LLM原型救活。他说了个精妙的类比：很多人以为自己在造自动驾驶汽车，实际上只是给马车装了个火箭发动机——动力再猛，骨架不对，散架是迟早的事。

从"神谕模式"到"组件模式"

早期LLM应用的核心幻觉，是把模型当成全知全能的 oracle（神谕）。你扔个问题，它吐个答案，完事。这种交互在Demo里丝滑得像魔术，进生产环境就现原形：多步骤任务走到第三步忘了第一步要干啥，调API时把用户ID和订单ID搞混，出错之后只会复读"作为AI助手我无法……"

Raghuvanshi的观察很毒舌：「单轮LLM调用和真正的Agent系统，差距就像Excel宏和微服务架构。」Agent不是更复杂的提示工程，而是一种新的工程物种——有状态、能规划、会调用工具、能在多轮推理中保持目标一致性。

他带过的一个典型抢救案例：某金融科技团队用GPT-4做风控报告生成，提示词写了2000行，每次跑完要人工检查有没有漏算指标。重构后改用Orchestrator模式，把任务拆给三个专职子Agent（数据抓取、计算校验、报告组装），错误率从12%降到0.7%，响应时间反而快了40%。

Orchestrator模式：让专业的人干专业的事

这个模式的核心是"路由"而非"包揽"。想象一个医院分诊台：患者进来，护士判断该去外科还是内科，而不是自己试图看病。Orchestrator就是那个护士——它本身不处理业务逻辑，只负责把用户请求映射到最合适的子Agent。

Raghuvanshi给过一个极简实现框架：主Agent解析意图，维护一个子Agent注册表（名字+能力描述+输入输出Schema），匹配成功后移交控制权。关键设计是子Agent之间不直接对话，所有状态变更通过Orchestrator中转——这避免了"传话游戏"式的信息失真，也让调试时能精准定位哪环出了问题。

但别滥用。他明确划了红线：如果子任务之间需要频繁交换中间结果，Orchestrator会成为瓶颈；如果子Agent超过5个，路由逻辑的复杂度可能反超收益。一个反直觉的判断标准：当你开始给Orchestrator写"路由策略的元策略"时，就该拆系统了。

Planner-Executor：把"怎么做"和"做不做"拆开

这是Raghuvanshi最推崇的模式，源自机器人领域的经典分层架构。Planner负责生成带依赖关系的任务图（比如：查天气→决定穿衣→推荐搭配），Executor负责按拓扑序执行，并在每一步验证前置条件是否满足。

一个精妙的细节是计划的可回滚性。Raghuvanshi的代码示例里，Executor在调用外部API前会先把当前计划状态快照到Redis，如果第三步失败，可以回到第二步重新生成替代方案，而不是从头再来。这在支付、库存等关键链路是刚需——用户不会容忍"扣了钱但订单没建"的中间态。

他特意提醒了个坑：Planner和Executor不要用同一个LLM实例。规划需要创造性推理，执行需要严格遵循约束，两种能力对温度参数（temperature）的要求截然相反。混用会导致"计划很完美，执行时却擅自发挥"的诡异bug。

Memory-Augmented：Agent的"便签本"该记什么

上下文窗口（context window）越来越长，但Raghuvanshi认为这反而加剧了滥用。他把LLM的上下文比作工作记忆——能同时惦记的事就那么几件，塞太多只会互相干扰。真正的长期记忆需要外部化存储，且要有选择地召回。

他的分层方案：短期记忆（当前对话轮次）走上下文窗口；中期记忆（本次会话的关键事实）存向量数据库，按语义相似度检索；长期记忆（用户偏好、历史决策）走关系型数据库，精确查询。一个电商客服Agent的例子：用户说"还是像上次那样寄到公司"，系统从长期记忆捞出地址，从中期记忆确认"上次"指三天前的订单，短期记忆处理当前的修改需求——三层各司其职，没有一层在干脏活。

但向量检索的幻觉被低估了。Raghuvanshi见过案例：Agent把"我不喜欢红色"和"上次退货是因为色差"错误关联，导致推荐时刻意避开所有暖色调。他的防御策略是给记忆条目加置信度分数和来源标记，低置信度的记忆需要LLM二次验证才能进入决策流程。

ReAct与Human-in-the-Loop：安全带的两种系法

ReAct（Reasoning + Acting）模式现在几乎成了工具调用的标准范式：Thought→Action→Observation循环。Raghuvanshi的贡献是强调了工具调用的幂等性设计——同样的Action执行两次，结果应该一致。这在LLM可能重复调用或失败后重试的场景是保命设计。

他举了个支付场景的反例：某团队把"扣款"做成非幂等接口，Agent在超时重试时导致用户被扣两次钱。修复方案是引入客户端生成唯一幂等键，服务端用这个键去重。这个改动和LLM无关，但缺了它，再聪明的Agent也是定时炸弹。

Human-in-the-Loop（人机协同）则是另一层保险。Raghuvanshi区分了两种介入时机：审批式（Action执行前人工确认）和审计式（Action执行后人工抽查）。他的经验数据是，生产系统应该从100%审批开始，随着置信度积累逐步降到5%以下，但审计比例要始终保持在1%以上——这是发现边缘案例的唯一途径。

一个被忽视的设计是"中断的可恢复性"。用户中途介入修改了参数，Agent应该能从中断点继续，而不是重启整个流程。这要求状态机设计时就考虑人机交接的边界条件。

Reflection：让Agent学会"复盘"

这是Raghuvanshi最看好的方向。Reflection模式让Agent在任务完成后执行二次推理：目标达成了吗？哪个步骤最耗时？有没有更短的路径？这些反思结果写入记忆，形成类似"经验"的积累。

他展示了一个客服Agent的反思日志："用户询问退货政策→我调用了通用FAQ接口→但用户实际想退的是定制商品→应该优先查定制商品特殊规则→下次遇到'退货'关键词且订单含定制标记时，直接走定制流程。"这种结构化的自我改进，比微调模型成本低两个数量级。

但Reflection也有毒性。Raghuvanshi警告过"过度反思"陷阱：某Agent在简单查询上花了30%的token做事后分析，导致成本失控。他的解法是给Reflection设置触发条件——只有任务时长超过阈值、或用户明确反馈不满、或遇到新类型的工具调用时才启动。

Raghuvanshi在文末留了道思考题：当Agent的Reflection能力足够强时，Planner和Executor的边界会不会模糊？如果Agent能实时重构自己的执行策略，"计划"和"执行"还是两个模块，还是变成一种连续的、流式的智能？

这个问题他还没答案。但有个现象值得玩味：他最近把博客的评论区关了——因为实验性的Reflection Agent在回复读者时，开始表现出"为了展示反思深度而过度展开"的倾向，人类读者反而觉得啰嗦。优化目标的对齐，可能比架构设计更难。