田间地头,拖拉机突然熄火,农民翻遍手册也找不到故障原因——这种场景比我们想象的更常见。设备维修的痛点一直很明确:技术文档分散、专业术语晦涩、现场人员经验参差不齐。Amazon Bedrock AgentCore 的出现,让"对着机器说句话就能定位问题"这件事变得可落地了。
这篇文章拆解一个完整方案:用 AgentCore Runtime + Strands Agents SDK 构建一个农机维修助手,让农民和现场技师通过自然语言完成故障诊断、零件识别和维修步骤查询。
AgentCore 的架构角色
AgentCore 不是单一服务,而是三个能力的组合:
- Runtime——托管 Agent 的执行环境,配合 Strands Agents SDK 定义 Agent 行为、工具调用和编排逻辑。
- Knowledge Base——基于 RAG 的知识检索,把厂商维修手册、零件目录、故障代码表等文档变成可查询的结构化知识。
- Memory——对话持久化,让多轮诊断不丢失上下文。用户说"上次那个液压泵的问题",助手能接上。
底座模型选用 Amazon Nova 2 Lite,轻量、低延迟、成本可控,适合现场移动端交互场景。
整体数据流如下:
用户语音/文字输入
→ AgentCore Runtime (Strands Agent 编排)
→ 调用 Knowledge Base 检索维修文档 (RAG)
→ 调用 Memory 读取历史对话上下文
→ Nova 2 Lite 生成诊断建议 + 零件编号 + 维修步骤
→ 返回结构化回复
用 Strands Agents SDK 定义维修 Agent
Strands Agents SDK 是 AgentCore Runtime 的配套开发框架,核心思路是:声明工具、定义 Agent、让模型自主决定调用顺序。下面是一个可改造运行的 Agent 定义示例。
# repair_agent.py — 农机维修助手 Agent 定义
# 前置依赖:pip install strands-agents-sdk boto3
from strands_agents_sdk import Agent, tool
import boto3
import json
# ---------- 工具定义 ----------
@tool(name="query_knowledge_base", description="从维修手册和零件目录中检索相关信息")
def query_knowledge_base(query: str, top_k: int = 5) -> str:
"""调用 Bedrock Knowledge Base 进行 RAG 检索"""
kb_client = boto3.client("bedrock-agent-runtime")
response = kb_client.retrieve(
knowledgeBaseId="YOUR_KB_ID", # 替换为你的 Knowledge Base ID
retrievalQuery={"text": query},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": top_k
}
}
)
results = []
for r in response.get("retrievalResults", []):
content = r["content"]["text"]
source = r.get("location", {}).get("s3Location", {}).get("uri", "未知来源")
results.append(f"【来源: {source}】\n{content}")
return "\n---\n".join(results) if results else "未找到相关维修信息。"
@tool(name="lookup_part_number", description="根据设备型号和故障描述查找替换零件编号")
def lookup_part_number(equipment_model: str, symptom: str) -> str:
"""从零件目录中匹配零件编号"""
# 组合更精准的检索查询
refined_query = f"{equipment_model} {symptom} 替换零件 零件编号"
return query_knowledge_base(refined_query, top_k=3)
@tool(name="get_repair_procedure", description="获取厂商批准的维修操作步骤")
def get_repair_procedure(equipment_model: str, component: str) -> str:
"""检索标准维修流程"""
procedure_query = f"{equipment_model} {component} 维修步骤 操作规程"
return query_knowledge_base(procedure_query, top_k=5)
# ---------- Agent 定义 ----------
repair_agent = Agent(
name="equipment-repair-assistant",
model="us.amazon.nova2-lite-v1:0", # Nova 2 Lite 模型 ID
instructions=[
"你是一名专业的农机设备维修助手,服务于农民和现场维修技师。",
"诊断流程:先确认设备型号和故障现象,再检索相关维修文档,最后给出诊断结论和操作建议。",
"所有维修步骤必须引用厂商批准的规程,不得自行编造。",
"如果信息不足,主动追问用户:设备型号、故障代码、异常声音/烟雾等细节。",
"回复中必须包含:1) 可能的故障原因 2) 所需替换零件编号 3) 维修步骤摘要 4) 安全警告。",
],
tools=[query_knowledge_base, lookup_part_number, get_repair_procedure],
)
# ---------- 运行交互 ----------
if __name__ == "__main__":
# 单轮测试
result = repair_agent.run(
"我的 John Deere 8R 拖拉机液压系统压力不足,仪表显示故障代码 E-HYD-042"
)
print(result)
# 多轮对话(Memory 由 AgentCore Runtime 在部署模式下自动管理)
# 本地开发模式下可手动传入 conversation_id 模拟持久化
运行前需要替换 YOUR_KB_ID 为你实际创建的 Knowledge Base ID。本地测试用 python repair_agent.py 即可;部署到 AgentCore Runtime 后,Memory 持久化会自动生效。
Knowledge Base 的文档准备
RAG 的效果直接取决于文档质量。农机维修场景建议准备三类数据:
| 文档类型 | 内容示例 | 存放路径建议 |
|---|---|---|
| 维修手册 | 故障代码表、诊断流程图 | s3://kb-docs/manuals/ |
| 零件目录 | 零件编号、兼容型号、图示 | s3://kb-docs/parts-catalog/ |
| 操作规程 | 拆装步骤、扭矩参数、安全警告 | s3://kb-docs/procedures/ |
创建 Knowledge Base 的核心命令:
# 创建 Knowledge Base(需先在 S3 上传文档并创建向量存储)
aws bedrock-agent create-knowledge-base \
--name "equipment-repair-kb" \
--description "农机维修手册与零件目录知识库" \
--knowledge-base-configuration '{
"type": "VECTOR",
"vectorKnowledgeBaseConfiguration": {
"embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
}
}' \
--roleArn "arn:aws:iam::YOUR_ACCOUNT:role/BedrockKBRole"
# 记下返回的 knowledgeBaseId,填入上面的 Python 代码
# 关联数据源(指向 S3 文档目录)
aws bedrock-agent create-data-source \
--knowledge-base-id "YOUR_KB_ID" \
--name "repair-manuals" \
--data-source-configuration '{
"type": "S3",
"s3Configuration": {
"bucketArn": "arn:aws:s3:::kb-docs",
"prefixes": ["manuals/", "parts-catalog/", "procedures/"]
}
}'
# 触发同步(将文档向量化入库)
aws bedrock-agent start-ingestion-job \
--knowledge-base-id "YOUR_KB_ID" \
--data-source-id "YOUR_DS_ID"
文档格式支持 PDF、Word、TXT、Markdown。建议维修手册用 PDF(保留图示),零件目录用结构化 Markdown(方便精确检索编号)。
Memory 让多轮诊断不断线
现场维修诊断很少一轮结束。典型对话可能是:
用户:拖拉机启动后 5 分钟就熄火 助手:请确认故障代码 用户:代码 E-ENG-108 助手:燃油供给系统异常,可能原因……需要检查燃油滤清器 用户:滤清器换了还是不行 助手:结合之前的 E-ENG-108 和换滤清器无效,建议检查高压油泵……
AgentCore Memory 自动保存每轮对话的上下文,模型在后续轮次中能读取完整历史。部署到 Runtime 后,只需在 Agent 配置中声明 Memory 策略:
# 在 Agent 定义中增加 Memory 配置(部署模式)
from strands_agents_sdk import MemoryConfig
repair_agent = Agent(
name="equipment-repair-assistant",
model="us.amazon.nova2-lite-v1:0",
instructions=[...],
tools=[...],
memory=MemoryConfig(
strategy="CONVERSATION_SUMMARY", # 对话摘要策略,节省 token
max_history_turns=20, # 保留最近 20 轮
),
)
CONVERSATION_SUMMARY 策略比逐轮存储更省 token——对移动端场景(网络带宽有限)尤其重要。如果需要完整逐字记录(比如合规审计),改用 FULL_CONVERSATION。
部署到 AgentCore Runtime
本地测试通过后,部署到 AgentCore Runtime 让助手变成一个可调用的服务:
# 创建 AgentCore Runtime 应用
aws bedrock-agent-core create-app \
--name "repair-assistant-app" \
--runtime-type "STRANDS_AGENT"
# 上传 Agent 代码包
aws bedrock-agent-core deploy-agent \
--app-id "YOUR_APP_ID" \
--agent-entry-point "repair_agent.py" \
--s3-code-uri "s3://agent-code/repair-agent.zip"
# 获取调用端点
aws bedrock-agent-core get-app-endpoint --app-id "YOUR_APP_ID"
部署后,前端(移动 App 或 Web)通过 HTTPS 调用 Agent 端点,传入用户消息和 session_id(用于 Memory 关联),即可完成多轮交互。
落地前需要想清楚的几件事
文档覆盖度是成败关键。 Knowledge Base 里没有的故障,模型只能"猜"。上线前务必盘点:覆盖了多少设备型号?故障代码表是否完整?零件目录是否更新到最新版本?
安全警告不能省。 农机维修涉及高压液压、旋转部件、化学物质。Agent 的 instructions 里硬编码了"必须包含安全警告",但这只是模型层面的约束。生产环境建议在工具返回结果中做二次校验——如果检索到的规程包含安全标签,强制在回复中高亮展示。
成本控制。 Nova 2 Lite 单次推理成本很低,但 RAG 检索每次都会调用 embedding + 向量搜索。高频场景下,考虑对常见故障代码做缓存层,减少 KB 查询次数。
多语言。 农机手册通常是英文,但用户可能说中文或西班牙语。Nova 2 Lite 支持多语言理解,但检索查询建议翻译为文档原始语言(英文),召回率更高。可以在 query_knowledge_base 工具中加一步翻译预处理。
这个方案的核心价值不是"又一个聊天机器人",而是把厂商几十年积累的维修知识,通过 RAG + Agent 编排,变成现场人员真正能用上的诊断能力。从代码到部署,整条链路都在 AWS 体系内,不需要自建向量数据库或推理服务器。如果你手上有结构化的维修文档,最快一天就能跑起一个可交互的原型。