用 Amazon Bedrock 搓了个客服 Agent 发现模型太

让 AI 跑业务流程最怕的就是它“自以为是”。我最近在折腾一个基于 Amazon Bedrock 的客服 Agent 工作流，本来以为只要把逻辑写清楚就行，结果在测试阶段被坑了。这个项目要求 Agent 能区分用户是在报 Bug、问 FAQ 里的问题，还是需要转人工，整体架构是 Bedrock AgentCore + AgentCore Gateway，后端挂了 AWS Lambda 和 DynamoDB 来处理数据和 FAQ 检索。

虽然最后跑分拿到了 0.83 的正确率，一次性过了，但那两个没跑通的 case 给了我很大启发：模型“理解了需求”并不等于“拥有了执行动作所需的全部信息”。

具体到报 Bug 这个场景，我在 Prompt 里明确规定了创建工单必须满足三个条件：问题的详细描述、复现步骤、以及出问题的环境。按理说，缺任何一个，Agent 应该追问用户。结果在测试中，有两个 case 出现了模型自作聪明的情况——它通过上下文大概猜到了用户在什么环境下操作，于是直接跳过追问环节，强行帮用户创建了工单。

这种“脑补”在 Demo 阶段看起来很智能，但在真实公司业务里就是灾难。如果一个 Bug 报告缺少复现步骤，开发人员拿到工单后还是得回头问用户，这完全没起到提效作用。这让我意识到，构建 Agent 的核心不在于让它能回答，而在于定义它在什么时刻必须停止执行并要求补充信息，或者直接把球传给人工。

这次折腾下来的技术链路大概是这样的：

一、整体架构分工

• Bedrock AgentCore：充当大脑，负责意图识别和编排。
• AgentCore Gateway：作为入口，处理请求的分发。
• AWS Lambda：执行具体动作的“手”，比如去 DynamoDB 里查 FAQ 答案或者写入 Bug 工单。
• DynamoDB：存放 FAQ 知识库和工单记录。

二、Prompt 的博弈
在写 Prompt 时，我发现它承担的角色远超想象。它不仅是指令，更是整个业务的“规则书”。我得在 Prompt 里把边界划得极其死，比如：

If the user is reporting a bug, you MUST verify the following three pieces of information before calling the create_ticket function:
1. Detailed description of the problem.
2. Steps to reproduce the bug.
3. The environment where the bug occurred.

![用 Amazon Bedrock 搓了个客服 Agent 发现模型太](/uploads/articles/1428b375988143a4.webp)

If any of these are missing, do NOT assume the value. Ask the user specifically for the missing information.

即便写成了这样，模型在面对一些模糊表述时依然想走捷径。下次我会尝试把“检查信息完整性”作为一个独立的验证步骤，而不是揉在同一个指令里。

三、避坑经验
这次最快地让我上手的是看到后端 Lambda 怎么与 Agent 交互。当你看到 Agent 尝试调用函数但参数缺失时，你才会意识到 Prompt 里的约束力有多弱。如果你也在尝试构建类似的工作流，建议在评估阶段多加一些“故意缺失信息”的负面测试用例，逼模型学会说“我不知道，请告诉我”。

总之，这次尝试让我明白，一个好用的 Agent 应该是克制的。它不需要表现得无所不知，而需要像个专业的客服一样，在信息不足时敢于打断用户并要求补全，而不是在那儿凭直觉猜。