生产环境的AI agent幻觉不是demo里的"偶尔抽风"——它意味着真金白银的订单错误、客服投诉、合规风险。AWS工程师Elizabeth Fuentes最近把一套笔记本上的防幻觉demo搬上Amazon Bedrock AgentCore，结果发现：托管基础设施不仅扛住了流量，还让业务规则的迭代从"改代码 redeploy"变成了"改数据库行"。
这套方案的核心矛盾很典型：本地demo用硬编码数据、内存规则、单用户验证，技术验证通过了，工程化却卡壳。生产化需要回答三个问题——数据放哪、规则怎么热更新、工具调用怎么不跑偏。Fuentes的解法是把5种防幻觉技术全部 infrastructure-as-code 化。
从笔记本到生产：一张表看懂替换逻辑
先看改造前后的对照。本地demo的硬编码业务规则，换成DynamoDB动态配置；in-process的工具函数，拆成Lambda serverless；内存里的向量检索，接入S3+知识图谱。
技术栈选型有讲究。Strands Agents负责agent编排，原生支持tool calling和guardrail hooks；MCP（模型上下文协议）作为统一接口，把工具调用路由到Bedrock AgentCore Gateway。类似模式可以平移到LangGraph、AutoGen、CrewAI。
部署依赖两个独立CDK stack。HotelBookingAgentStack先跑，承载核心预订逻辑；GraphRAGStack后加，补FAQ能力。这种分层让MVP和增强功能解耦，避免一次性堆复杂度。
数据库驱动的guardrail：改行数据就能纠偏agent
demo 04里的业务规则是Python硬编码——改个阈值要动代码、跑CI、重新部署。生产版本把规则结构化进DynamoDB，每条规则包含两个关键字段：
fail_message描述违规本身，steer_message指导agent自我修正。比如"最大10人"的规则，steer_message会明确告诉agent："15人预订不可行，但你可以调整为10人继续，并告知用户"。
这种设计把"拦截"和"引导"分开。单纯阻断会让agent僵住，而给出修正路径能让对话继续。enabled字段支持灰度——新规则先关，验证完再开，不用碰代码。
validate_booking_rules工具在agent执行前读取DynamoDB，把规则检查从编译期挪到运行期。业务方自己改表，工程师不用on-call。
Semantic tool routing：让agent别乱抓工具
幻觉的另一种表现是"工具错配"——该查房价的时候去调支付接口。Fuentes用语义路由解决这个问题：工具不再靠名字匹配，而是基于描述向量的相似度检索。
实现上，工具描述预先嵌入向量库，agent的意图同样向量化，Top-K相似度决定调用哪个Lambda。这比关键词匹配容错率高，"我要订房"和"我想住宿"不会指向不同工具。
MCP在这里扮演关键角色。它标准化了工具发现的协议，Gateway层统一处理鉴权、限流、日志，agent侧只关心语义匹配结果。
Knowledge graph：把FAQ从"检索段落"变成"遍历关系"
最后一块拼图是GraphRAGStack。传统RAG把文档切成块、算相似度、拼上下文，容易丢失实体关系。知识图谱把酒店、房型、政策变成节点，预订规则、退改条款变成边。
agent回答"这家酒店带泳池的家庭房周末价格"时，图谱查询能精确定位节点路径，而不是在整篇文档里捞片段。幻觉率下降的同时，答案的可解释性提升——你可以回溯agent走了哪条边。
这套架构的隐性收益是审计友好。DynamoDB里的规则版本、Lambda的调用日志、图谱的查询路径，全部可追踪。合规团队要查"为什么agent拒绝了这笔预订"，能拉出完整证据链。
Fuentes在GitHub开源了完整代码，两个CDK stack一键部署。她的观察是：很多团队卡在"demo漂亮、生产翻车"，不是因为算法不够聪明，而是基础设施没给算法纠错的余地。
当业务规则能从数据库实时流入agent行为，当工具调用能被语义层拦截误操作，当知识检索从"模糊匹配"变成"关系遍历"——幻觉没有被消灭，但被关进了可观测、可干预、可回滚的笼子里。这大概是2024年大模型工程化最务实的进展之一。
你的agent生产化卡在哪一步？是规则热更新、工具路由，还是知识检索的精度？
热门跟贴