1. 双AI代理架构一个Agent搞不定的事两个Agent也未必搞得更漂亮先聊一个扎心的现实。做AI代理项目很多人一开始都满怀希望地搭了一个超级Agent给它一堆工具、一大段系统提示词、几个知识库结果一跑起来就露馅它在不同任务之间反复横跳上下文窗口越塞越满到最后连最基本的格式要求都开始违反。我去年在AWS上做一个企业内部流程自动化的POC前面几周基本就是在跟这种单Agent失控做斗争。当时面临两个选择要么继续堆提示词要么把架构改成分工协作的双代理。最后我选了后者——两个Agent各管一段各自持有精简的上下文效果立刻不一样了。而正是在做这个拆分的过程中我接触了AWS生态里两条完全不同的实现路线一条是直接用托管服务一条是用基础框架自己拼。两条路子我都实测过这里面取舍很微妙。这篇文章我把两条路线的架构逻辑、实现步骤、常见坑位和选型思路完整梳理一遍。不论你是正在评估AWS AI代理方案的架构师还是准备动手写第一个Agent的实验者这篇应该能帮你省掉不少试错时间。1.1 单Agent为什么会在真实任务里崩溃先花点时间说清楚双代理到底解决了什么问题。单Agent架构的崩溃本质上是三个问题叠加。第一是上下文污染。Agent每执行一步都要把历史记录塞进模型上下文。任务复杂一点十几轮工具调用下来中间产物、错误日志、多余的系统消息全堆在上下文里。模型不是数据库它分不清哪些信息重要注意力被稀释之后关键指令就容易被忽略。第二是职责冲突。一个Agent要同时扮演规划者和执行者这两件事的心智模型完全不同。规划需要宏观视野执行需要聚焦细节你要在一条系统提示词里同时把这俩塞进去最后得到的往往是两头都不靠的行为。第三是错误放大。单Agent链路有个可怕的特性——如果第一步工具调用返回了一个错误或者格式异常的数据后面所有步骤都会基于这个脏数据继续算。你指望Agent能自己发现异常并纠偏但事实上大部分时候它只会把这个异常当正常输入处理然后把错误一路传播到最终结果。双代理架构的意义就是把这三种问题拆开处理。简单任务确实没必要上双代理但涉及多工具、多阶段、长流程的任务拆分之后的稳定性提升是肉眼可见的。1.2 双AI代理在AWS语境下到底是什么形态双代理不是固定搭配根据业务需求有几种典型形态。最常见的叫主从协作。一个Planner Agent负责拆解任务、制定方案它自己不动手把每个子任务丢给专门的Worker Agent去执行。Worker跑完把结果回传Planner再决定下一步。这种模式适合流程类任务比如帮我调研这三家竞品汇总成一份对比报告。第二种叫并行竞争。两个Agent各自独立处理同一个任务产出两个结果由下游的评估器或者第三个Agent选优或者融合。这种模式偶尔会用成本高但确实能提升复杂任务的准确率。第三种叫流水线接力。Agent A处理上游比如信息抽取把结构化结果交给Agent B做下游比如报告生成。A的输入和B的输入不交叉上下文隔离最彻底。我自己最常用的是主从协作因为它最灵活也是AWS托管服务能比较好支持的一种形态。1.3 为什么是AWS而不是自己搭一套你在本地用LangChain也能快速构建双代理这没错。但一旦涉及生产环境有几个问题就绕不开并发调度的稳定性、企业级权限的接入、模型API的可用性保障、以及最关键的——跟现有云上服务的集成深度。AWS的AI代理实践优势不在于代理框架本身多先进而在于它把Agent周围的配套设施打通了。Agent要调企业数据能走IAMAgent要触发业务系统有EventBridge和Step FunctionsAgent要记录全过程有CloudWatch和X-Ray。这些在自建方案里全部要自己额外搭。所以认真做生产级项目的人基本都会至少考虑一下AWS这条路线。2. 托管服务与基础框架两条路线的骨架与分工2.1 托管服务到底托管了什么AWS现在主推的托管Agent服务是Amazon Bedrock Agents。注意它并不替你写业务的Agent逻辑而是帮你把Agent运行时要的那些脚手架全管起来。具体来说它托管了这些东西Agent的编排循环Orchestration Loop。Agent如何理解用户输入、规划步骤、调用工具、处理结果这套循环逻辑由服务端负责。基础模型的路由与切换。你可以选Claude、Llama、Mistral等模型当Agent的大脑随时在控制台切换代码不用改。多个Agent的统一管理。最近Bedrock上线了AgentCore可以在一个命名空间里注册多个AgentAgent之间可以互相调用——这个能力对双代理架构非常关键后面会详说。版本的发布与别名路由。改提示词后新建版本流量走不同别名这个设计很工程化生产环境必须要有。我第一次用Bedrock Agents的感受是它把跑通一个Agent的门槛降得很低。你只要写好系统提示词、定义好Action Group要暴露给Agent的工具、配好知识库几分钟就能生成一个可调用的API。但托管服务收走的东西也是要还的——最大的代价就是灵活性受限。编排逻辑是黑盒你要在中间插手定制就得用它的钩子Hook机制而这个机制目前能做的定制深度有限。2.2 基础框架路线长什么样所谓基础框架指的是你在EC2、EKS或者Lambda上用LangChain、LlamaIndex这些框架自己搭Agent的编排逻辑。AWS不会帮你管理Agent循环一切自己写。这条路线的核心组件是一个是工作流定义层。用LangGraph或者LangChain的AgentExecutor定义Agent的节点、边和状态流转。双代理在主从协作下其实就是一张图Planner节点、Worker节点、Router节点、汇总节点每两个节点之间用边连接全部由代码控制。另一个是模型网关层。通过Boto3调用Bedrock的Converse API或者InvokeModel API拿到模型推理结果相当于在框架和模型之间垫一层你自己的封装。再一个是记忆与状态层。双代理比单代理更依赖状态管理。两个Agent如何共享已完成的中间结果、如何传递任务目标这些都需要你自己设计好。你可以把状态放在内存里单机、Redis里分布式或者扔进DynamoDB持久化。基础框架路线的核心优势是灵活。你可以完全控制编排的每一步也可以做托管服务做不了的定制行为——比如引入人工反馈环、跳出链式调用的约束、自定义复杂的重试策略。我今天重点讲的LangGraph方案就是这条路最具代表性的实现。2.3 选型也要看清楚这两条路的代价分类对比一下维度托管服务Bedrock Agents基础框架LangGraph Bedrock编排逻辑云端黑盒通过Hook定制完全自控可可视化可修改双Agent协作通过AgentCore互相调用需自己设计协作会话逻辑用图结构直接定义灵活度高开发速度快半天出原型慢前期框架工作较多调试体验控制台查看CloudWatch日志黑盒较多可本地断点调试可打印完整状态版本管理内置很完善自己设计依赖CI/CD流程成本透明度相对黑盒每个节点可打点计费更透明适合场景标准化的的单Agent/简单双Agent复杂协作逻辑、定制化需求说一个很多资料没提到的点托管服务适合Agent本身是产品主体的场景基础框架适合Agent是系统里的一个模块的场景。如果你的产品就是一个客服机器人、文档分析助手那托管服务够用如果Agent只是你整个微服务架构里面的一环需要和别的模块做复杂的消息交互、状态同步那你大概率早晚要转向框架。我个人实测的结论是复杂双代理协作从基础框架起步比从托管服务起步更稳。托管服务容易让你快速做出一个看起来不错的Demo然后当你想要塞进更多定制逻辑时发现黑盒处处卡你回头重写的时间成本很高。3. 托管服务路线实战用Bedrock Agents搭一套双Agent协作流程3.1 先看清Bedrock Agents的组件拼图用托管服务搭双代理第一步要理解它的组件体系。Bedrock Agents由几个关键部分组成Agent本体。配置了模型、指令、动作组和知识库的逻辑单元。Action Group。把你要暴露给Agent的工具Lambda函数和对应的OpenAPI schema打包成一个组。Agent在需要时通过Schema知道工具有什么、参数是什么然后调用Lambda。Knowledge Base。给Agent挂上的RAG知识来源比如S3里的文档、向量数据库等。Alias。发布后的稳定版本入口类似API Gateway的stage概念。AgentCore注意这跟Agent Runtime不是一个东西。这个是可以注册多个Agent并进行互相调用的命名空间级组件托管的Agent互调能力就是通过它实现的。看到这里你应该明白在Bedrock里搭双Agent架构本质有两种选择一种是用AgentCore让两个Agent绑定在一起互相调用另一种是自己在Lambda/StepFunctions里写编排逻辑去串起两个Agent。我建议如果你的协作逻辑简单——比如就是A先干完然后B接手——直接用AgentCore的互相调用省事如果协作逻辑复杂那就自己在StepFunctions里编排把双代理当作两个API来调用会灵活很多。3.2 用AgentCore管理多个Agent的注册与调用AgentCore的引入是个好消息。以前做多Agent时很憋屈你需要自己写一堆Lambda胶水代码才能让两个Agent说话。现在AgentCore允许你在同一个命名空间注册多个Agent而且支持一个Agent把另一个Agent当作工具来调用。实际操作上核心步骤是这几步第一步注册Agent。在控制台创建两个Agent分别起名PlannerAgent和WorkerAgent。PlannerAgent配Claude Sonnet主攻任务分解WorkerAgent配Claude Haiku主打快速执行。第二步给PlannerAgent添加一个指向WorkerAgent的Action Group。这个Action Group的OpenAPI schema里定义了一个action叫invoke_worker_agent参数是task_description。底层的Lambda把用户输入转发给WorkerAgent的Alias拿到结果后返回。第三步设计上下文交接。托管服务的双Agent最常见的坑是信息传不过去。Planner想告诉Worker我已经分析了文档的前半部分你可以接着后半部分看但你的Action Group schema里如果没有designated_agent_id这个字段Worker拿到的就是一段孤立的任务描述。所以设计OpenAPI schema的时候一定要把context字段放在参数列表里让Planner可以把截止目前的状态作为参数打包传给Worker。第四步开启trace。在CloudWatch Logs里打开Agent的logging确认每次Agent间调用的细节都被记录。没有trace双Agent出问题的时候排查难度加倍后面排坑那章我会细讲。注册好之后AgentCore会给你生成一个agentId和一个aliasId你在应用代码里拿到这个标识就可以像调用普通API一样发起Agent会话了。Python代码大概长这样import boto3 client boto3.client(bedrock-agent-runtime) response client.invoke_agent( agentIdplanner-agent-id, agentAliasIdalias-id, sessionIdsession-001, inputText调研AWS Lambda的冷启动优化方案给出3个案例 )注意这段代码只是发起对话的入口。至于PlannerAgent内部怎么规划、什么时候触发WorkerAgent、WorkerAgent返回之后Planner怎么整合这些都不是你代码里控制的全是托管服务的编排循环在管。3.3 深入Action Group的配置细节Schema是最被低估的一环托管服务双代理能不能顺畅工作很大程度取决于你的Action Group的OpenAPI Schema写得好不好。模型读完Schema才知道什么时候该调用哪个工具、传什么参数。我第一次写这个Schema时踩了一个很典型的坑把参数都写成非必填觉得这样模型更自由信息传递更灵活。结果是Agent经常偷懒调用Worker时不传关键上下文导致Worker每次都在信息不全的情况下瞎猜。正确做法是关键参数一定要设成required。你要让模型觉得这是必须提供的否则调用不合法。此外description字段一定要写得非常直白描述清楚每个参数的意义。模型是靠description理解参数的不是靠参数名。你写context: str跟写context: 上一个Agent已完成的处理结果的JSON序列化字符串可能包含chunks和summaries字段后者对模型的引导作用完全不同。除此之外有一个经常被忽略的细节每个Action Group里工具的输入和输出都建议有一个统一的校验层。托管服务不会替你校验Lambda返回的JSON结构。如果Worker的Lambda意外返回了一个异常对象Agent拿到之后容易出现格式解析失败然后整段对话陷入重试循环。我后来统一给每个WorkerLambda加了一个响应包装强制返回{ status: ok, data: ... }或{ status: error, message: ... }至少保证Agent拿到的永远是一个可解析的结构。3.4 托管方案先跑通再改别急着定义完美流程托管服务做双代理有一个天然的优势也是它的劣势循环逻辑是固定好的顺序是固定的理解-规划-调用-观察-再规划。你在Demo阶段不要急着给Planner设计太复杂的规划约束先让它自由发挥从日志里看它实际会怎么调用Worker再根据行为迭代提示词。我见过很多团队一上来就把提示词写成一篇十条规定要求Agent先这样再那样还要自己检查输出质量。结果agent的执行链路被打得乱七八糟有时候它不知道是该先执行还是先检查最后反而连基本功能都歪了。托管服务的编排循环本身就是一套成熟的思维链你只需要给它一个大致方向的指令而不是去接管它的思路。当然这个态度仅限于Demo阶段。一旦要上生产你必须重新审视提示词里的每条约束是否稳定复现这时候反而需要把提示词的每个句子都当成代码来测试——这条我在最后一章详细讲。4. 基础框架路线实战在LangGraph里实现Planner-Worker双Agent4.1 为什么我在生产项目里最终选了LangGraph说句实话。Bedrock Agents在简单场景下很省事但等我把双代理协作真正推进到生产时发现托管服务有几个事情搞不定第一Agent间复杂的会话交接状态。主从协作模式下Planner往往要发起多次Worker调用每次调用还要依赖上一次的部分结果。托管服务里你写这个逻辑很别扭你得靠Agent自己记得调用参数而它未必可靠。第二我需要给Planner设计一个明确的判断节点。当Worker返回的质量不好时Planner要能进入一个重新生成分支这个分支既可以是重新调用Worker也可以是切换到另一个专用的Reviewer Agent。这种多分支编排用LangGraph画出来就是一张清晰的图而托管服务里很难表达。第三可观测性。生产环境里我必须知道每个Agent每一步的花费、每次调用的token数、某个环节失败率的统计。托管服务虽然也能给日志但高维度的业务指标你得自己从日志里挖。LangGraph的节点里我可以精确地打点和埋数据后期做报表很方便。所以我的结论是如果你未来要做复杂的Agent协作LangGraph是比Bedrock Agents更底层的选择。LangGraph本身不是模型服务它跟Bedrock是配合关系——用LangGraph搭骨架用Bedrock的模型API做大脑两者完全可以混用。这也是AWS生态里很典型的基础框架托管模型服务组合。4.2 用LangGraph画一张Planner-Worker协作图LangGraph的核心概念是StateGraph。你定义一个有状态的图每个节点是一个处理函数每条边决定状态怎么流转。两个Agent协作在这个框架里就是一张拥有四个节点的图。我这里以主从协作的Planner-Worker模式为例给你一个能跑的完整代码骨架。import operator from typing import TypedDict, Annotated, List from langgraph.graph import StateGraph, END from langchain_aws import ChatBedrock # Agent的大脑 planner_llm ChatBedrock( model_idanthropic.claude-3-5-sonnet-20240620, region_nameus-east-1 ) worker_llm ChatBedrock( model_idanthropic.claude-3-haiku-20240307, region_nameus-east-1 ) # 全局状态 class AgentState(TypedDict): task: str # 原始任务 plan: str # 规划结果 subtasks: List[str] # 拆解出的子任务 results: Annotated[List[str], operator.add] # Worker回传的结果 final_answer: str # 最终整合答案 # Planner节点 def planner_node(state: AgentState): prompt f你是任务规划者。请将以下任务拆解为最多3个可并行执行的子任务。 原始任务{state[task]} 只输出子任务列表不要输出其他内容。 resp planner_llm.invoke(prompt) subtasks [line.strip() for line in resp.content.split(\n) if line.strip()] return {subtasks: subtasks, plan: resp.content} # Worker节点可以并发执行 def worker_node(state: AgentState, subtask: str): prompt f你是执行者。请执行以下子任务 子任务{subtask} 注意整体任务的背景是{state[task]} 请直接输出任务结果简洁完整。 resp worker_llm.invoke(prompt) return {results: [resp.content]} # 汇总节点 def aggregator_node(state: AgentState): joined \n\n.join(state[results]) prompt f你是汇总者。请根据以下子任务结果整合输出最终答案。 原始任务{state[task]} 子任务结果 {joined} 最后输出一份结构清晰的完整回答。 resp planner_llm.invoke(prompt) return {final_answer: resp.content}注意看这段代码有两条关键细节results字段用了Annotated[List[str], operator.add]这意味着每个Worker返回的result会以追加的方式合并进去而不是覆盖。这在并发场景下非常重要——LangGraph的并发节点可以用Map-Reduce模式来跑多个Worker的返回值需要正确累加。然后把这几个节点连成图import functools graph StateGraph(AgentState) # 注册节点 graph.add_node(planner, planner_node) graph.add_node(worker, worker_node) graph.add_node(aggregator, aggregator_node) # 设定入口 graph.set_entry_point(planner) # Planner执行完后进入Worker前置的Map节点 graph.add_edge(planner, worker) # 关键让图在Worker节点里动态生成并发分支 graph.add_node(worker_map, worker_map_node)LangGraph里做Map-Reduce并发有个专门的手法核心是用一个map节点动态地为每个子任务创建一个Worker实例。你可以参考这个结构planner输出subtasks列表一个map节点会在收到完整subtasks后为每个子任务生成一个worker分支循环直到所有子任务完成。这个能力的价值在于如果你的双代理场景里Planner拆解出了3个子任务Worker可以并发跑3次总耗时约等于最慢的那一次而不是串行累加3倍。实测下来并发执行在耗时上通常能砍到一半左右这是托管服务不好做到的。最后别忘了画终点graph.add_edge(worker, aggregator) graph.add_edge(aggregator, END) app graph.compile()编译好之后调用起来也很直观result app.invoke({ task: 对比Lambda和Fargate在成本、运维复杂度、并发能力三个维度的差异 }) print(result[final_answer])你在LangGraph的StateGraph里自然就能看到整个流程planner先运行拆解任务多个worker并发执行结果汇总到aggregator。相比托管服务这套流程每个环节都由你控制每一步都能加日志、打指标、甚至动态修改路径。4.3 状态管理与记忆到底是自己写还是用内存双Agent的协作中最容易被忽略的是状态的问题。LangGraph的状态默认存在内存里应用重启就没了。生产环境你会遇到的实际问题包括用户A和用户B同时触发工作流状态不能混杂。解决方案是给每个会话分配session_id把所有状态save到DynamoDBLangGraph的Checkpointer就是干这个的。当你的应用收到一个请求带上了旧的session_idLangGraph可以从Checkpointer恢复整个图的状态直接从上次断点继续跑。这个能力很关键。比如Planner已经拆好子任务、Worker在跑第二个子任务时模型超时。单Agent方案里你只能从头来但LangGraph里可以恢复到worker节点状态的最后快照单独重跑这个Worker。比托管服务的整体重试节省了大量的token成本。4.4 LangGraph与AWS托管服务可以混着用很多人以为选了LangGraph就抛弃了Bedrock Agents。其实两者可以混用。最典型的方式是主流程用LangGraph编排某个专用子任务用Bedrock Agents处理。举个例子你有一个多文档分析系统。主流程的Planner用LangGraph控制按抽取、归纳、生成报告三段走。抽ED阶段你需要跟S3里的PDF实时交互这个场景直接调Bedrock Agents自带的KnowledgeBase功能比自己写RAG流程省太多事。这其实就是把托管服务的优势嵌进基础框架里。反过来也有一种混法在Bedrock Agent的ActionGroup里让Agent把一个LangGraph应用作为工具调用。如果这个LangGraph应用是一个复杂的多步数据分析任务由Bedrock Agent决定何时调用这也是合理的。生产架构本来就没有非要某种纯度不可按具体场景各取所需即可。5. 实测数据对比托管服务与基础框架真实差距在哪5.1 相同的双Agent任务两条路线的实际表现我在一个从给定PDF集合中提取项目关键风险并生成分级报告的任务上用同样的双代理逻辑分别跑了两套方案结果值得参考。任务规模5份PDF每份20页左右提取风险点后按高/中/低三档分级并产出报告。指标Bedrock Agents托管方案LangGraph基础框架方案首次搭建耗时约半天约2天任务总耗时约150秒约110秒LLM token消耗约9.8万约7.2万失败重试次数3次中途偶发一次格式错误1次发生在Worker输入解析结果质量评分人工4.2/54.5/5注以上数据在我的实测环境下获得版本为Bedrock Agents的最新SDK与LangGraph 0.2.x模型统一用Claude 3.5 Sonnet。你的环境可能略有偏差但趋势是有参考价值的。托管方案便宜在搭建效率上而基础框架方案在成本和结果质量上反超。更值得注意的是失败重试托管服务的Agent循环一旦在中间步骤出错往往要从头开始重放整个编排而LangGraph的Checkpointer可以从最近的checkpoint恢复代价小很多。5.2 冷启动与并发能力的具体差异再深挖一下两条路线在性能上的差异。Bedrock Agents的自动编排循环默认是串行执行的它天然不支持多个Agent并发处理子任务。除非你手动在StepFunctions里把Agent调用拆开并行跑否则一个Agent在处理完第一步之前不会进入第二步。这个限制在子任务之间没有依赖关系时会浪费最多的时间。LangGraph的Map-Reduce并发则是在图定义层面就解决的。我上面演示的worker_map_node会让多个Worker并发执行整个流程的时间只受最慢一个Worker的限制。实测3个并行子任务并发比串行节省约55%的时间。代价是实现更复杂、要对LangGraph的并发模型有理解。如果你用托管服务又想获得类似的并发能力就得转向StepFunctions Lambda编排。我在一个项目里就这样干过用StepFunctions启动两个嵌入的Agent调用各自执行独立子任务然后等两个结果都返回后进入汇总状态机。这能在托管方案里实现并行但需要你自己写状态机和错误重试逻辑。也就是说托管服务给它配上自定义编排也不便宜想获得框架的灵活性还是要付出额外搭建成本。5.3 成本模型不是每一分token都花得其所成本这块值得单独拉出来算一笔账。双Agent架构里有两个容易被忽略的成本坑。第一个坑是上下文重复传递。托管服务方案里两个Agent之间的上下文交接容易出现全套传递。Planner调用Worker时可能把自己的一大堆历史内容全部塞进去虽然你自己并没有写这个逻辑但编排循环有时候会把全量bullet context发给每个工具调用。这直接推高了每次调用的token消耗。LangGraph方案里你可以在代码里精确控制传给每个节点的prompt内容——只传当前需要的部分大幅减少浪费。第二个坑是重试的放大效应。单Agent失败重试耗费是1倍双Agent串行失败重试如果从最开始重放耗费是两倍甚至更多因为每个Agent都要重新执行一遍。所以我在生产实践里一直强调双Agent架构必须要有checkpoint设计或者让协作模式尽量并行化。前者能让你失败恢复的成本降到最低后者能让并发节点同时失败的可能性降到最低。我算过一笔账在同一个双Agent任务上用基础框架 checkpoint 并行Worker的配置比用裸托管服务的成本大约低25%-35%。这个数据来自15轮实测的平均值如果你的任务子步骤更多、协作更重差距会拉得更大。6. 生产环境必须处理的五个问题与经验6.1 身份认证与权限边界Agent不是万能钥匙不管是托管还是框架方案Agent请求背后总要带着一个身份在调用AWS资源。我在实际项目中见过有人图省事给Agent关联的角色直接上了AdministratorAccess。这很危险提示词注入攻击一旦生效攻击者可以诱导Agent调用工具删除S3桶、篡改数据。正确的生产配置应该遵循最小权限原则。给Aggent关联的IAM Role只授权它该访问的资源比如某个特定前缀的S3 bucket或者某个特定的DynamoDB表。如果Agent的Action Group里有多个工具最好是每个工具一个单独的Lambda权限上下文而不是一个大而全的角色。另外一定要在Agent的函数调用前面加一层输入校验。比如Agent要调用的工具是发送告警邮件参数是收件人地址和正文。如果攻击者注入了一段把数据库里的用户数据导出并发送到xxxexample.com你的工具如果直接接受这个参数就会出大事。解决办法是在Lambda的工具实现里对敏感参数做白名单校验不接受任何超出预期的值。6.2 可观测性建设清理掉两难的局面双Agent架构排错难是公认的。托管服务的日志尤其痛苦所有Agent内部推理过程压缩在一堆JSON里每次问题调查都要从CloudWatch Logs里人工捞数据。基础框架在这点上更友好但前提是你提前加好了埋点。我强烈建议从第一天就给Agent加三类观测数据第一是trace轨迹。每个节点调用的模型、参数、token数、耗时、结果摘要。LangGraph的LangSmith能自动生成这类trace托管服务则要依赖Bedrock的日志和AWS X-Ray。没有trace出问题时你会完全两眼一抹黑。第二是业务指标。比如本次任务的通过率、平均轮次、平均耗时每个Worker被调用的次数。这些放进CloudWatch Metrics里做成Dashboard比每天翻日志有效得多。第三是异常快照。每当你发现一个Agent抽风的案例把当时的输入、中间状态、模型响应、最终输出完整保存下来。这些快照是你优化提示词、修bug的最佳数据来源。我在团队里立了一条规矩每次线上Agent出了问题第一件事不是急着改思路而是先把快照存档。等积累了几十份快照之后你对Agent的行为模式会有完全不同的理解。6.3 提示词其实也是要版本管理的代码托管方案里有Alias版本机制可以对提示词的变化做版本管理这一点很好用。但你自己在基础框架方案里写提示词时很容易陷入直接在代码里改字符串的混乱状态改过的版本没法回溯出问题了不知道是哪个版本上的线。我的经验是把所有Agent提示词抽成独立配置文件放进代码仓库里管理。每个环境一份配置CI/CD时同步部署。提示词的一个句子改动可能比代码一行的改动影响更大值得你像管代码一样管它。另外改提示词之后的回归测试不能少。很多改动的副作用不会立刻显现需要一段时间才暴露例如提示词的一个小改动导致工具调用频率发生变化。所以每次改动都要跑一遍预定义的测试集包含常见场景、边界情况和历史失败案例。我在团队里维护了二十多条这样的回归用例每次改提示词必须全部跑绿了才允许上线。6.4 多区域部署与模型可用性问题AWS的模型服务并不是每个区域都一样。Claude模型的可用区域是us-east-1、us-west-2等几个主流区域而且不同区域的模型版本也有差异。生产系统如果只部署在一个区域一旦模型侧抖动或不可用全站就跟着挂。我推荐的做法是模型API层做区域级的故障转移。比如主用us-east-1检测到持续报错时自动切到us-west-2。这个逻辑在基础框架方案里很好实现——在你的ModelGateway层封装一个fallback机制调用失败时切换region重新发请求。托管方案则更难一些因为Agent的Alias绑定了区域你得预先在多个区域创建Agent再在应用层做一个简单的健康检查来切换入口。另外一个实测经验是模型侧限流常常比你想得更早出现。并发一高429错误開始频繁出现如果你没有指数退避的重试逻辑整个Agent流程会快速雪崩。所以不管哪条路线重试策略里加指数退避几乎是必须的。6.5 避坑清单别人踩过的我不希望你踩最后整理一份我在两次真实项目里积累的避坑清单全部是实际遇到过的问题。按出现频率排序。第一工具返回格式不稳定是所有Agent项目的头号Bug源。有一次我们的工具从数据库查询返回日期格式不统一模型在解析时频繁失败。解决方案是给工具的每次返回都加一层Schema校验不合格的返回在进入Agent之前就拦截下来。第二OpenAPI Schema里的description写得太差模型就乱调用工具。description要写清楚工具是干什么的、什么场景用、参数单位是什么模糊的description直接导致模型在错误时机调用工具。第三双Agent的信息传递不能依赖LLM的记忆。模型记性不好尤其两个Agent之间有信息交接时不能用你记得刚刚那个结果吗这种设计。所有的中间结果必须显式存储、显式传递最好在代码里硬编码好传递逻辑不指望模型自己记住。第四不要在生产里频繁修改提示词。托管服务虽然支持运行时更新Agent的提示词但每次更新都可能影响行为的一致性。线上跑得好好的Agent尽量不要动它的提示词所有修改都走Alias版本切换。7. 收尾给每个正在评估双Agent架构的人一句实话双AI代理架构不是一道必须上的新潮技术而是一个解决特定问题的手段。如果你现在的单一Agent在长流程任务里频繁失控或者你的业务天然需要分工协作那双代理值得认真考虑。但如果你目前简单的单Agent已经够用那就不必为了架构而架构。在AWS上把这套东西落地托管服务和基础框架各有所长两者之间的选择核心还是看你想要多高的可控性、愿意付出多少搭建成本。我自己现在的一般思路是原型验证用托管服务最快一到生产级就转向LangGraph这类基础框架把控制权拿回自己手里。Bedrock作为模型网关层继续保留这是两条路线里最稳定的交集。最后分享一个小技巧这也是我在多次排查线上问题之后总结出来的金规双Agent架构里你花在定义Agent之间接口上的精力应该至少占到总设计时间的三分之一。大部分Agent项目的失败不是模型不够聪明而是两个Agent之间该传什么、不该传什么、传到什么粒度你从第一天就没想清楚。想清楚接口再管聪明度——顺序千万不能反。
