当 AME 决定给产线配一个 AI 大脑

痛点：产线的“知识诅咒”

我负责的设备越来越复杂。上位机框架有16份配套文档，视觉系统有厚厚的技术论证报告，PLC程序、电路图、运维手册……加起来超过300页。

然后我发现一个规律：产线工程师每天问我的问题，前10个几乎一模一样。

• “这个报警代码是什么意思？”
• “换型的时候配方怎么导？”
• “运动卡初始化失败怎么办？”

这些问题答案都在文档里，但文档太长了，没人会通读。资深工程师被重复问题淹没，新人不敢问、不知道去哪问。产线不缺知识，缺的是随时可用的知识。

这是我决定做 AgentClaw 的起点。不是“我想学AI”，而是“产线有这个痛”。

选型：LangGraph 还是 AutoGen？（踩坑记录）

我的目标很明确：做一个能查文档、能推理、能调用工具的智能问答系统。

调研了一圈2026年的Agent框架，选项有三个：LangGraph、CrewAI、AutoGen。

我先试了AutoGen。微软出品，概念很先进（对话驱动多Agent）。但实际跑起来问题一堆：

• 0.10版本API全部重写，网上90%的教程作废。
• Python 3.13直接不兼容旧版。
• 在公司内网代理环境下初始化就报 ProxyError。

结论：AutoGen在2026年4月这个时间点，不适合工程落地。放弃。

CrewAI倒是跑通了。角色定义直观，代码简洁。但它有两个硬伤：不支持对话记忆（用户问完“上位机架构是什么”，再问“那它怎么扩展”，Agent完全不记得上一句），而且LLM配置和主项目不兼容，需要单独管理。

最后锁定 LangGraph。理由三个：

1. 图编排灵活：我需要的不只是线性流程，而是“先分析问题类型，再决定是查文档还是调计算器”的条件路由。
2. 状态持久化：MemorySaver 天然支持多轮对话，thread_id 隔离会话。
3. 生态成熟：文档完善，社区活跃，踩坑能找到答案。

这个选型过程花了我三天。但它决定了后续所有工作是在填坑还是在爬坡。

落地：从 RAG 到 ReAct Agent 的进化

第一版我只做了 RAG：把文档切成块，向量化存进 ChromaDB，用户问问题就检索相关片段喂给 LLM。

效果还行，但很快暴露问题：

• 用户问“节拍0.162s，一天能产多少颗？”，RAG 检索到“CT目标0.162s/2颗”，但不会算。
• 用户问“飞拍为什么不可行？”，RAG 检索到 GRR 数据表，但不会推理因果链。

我需要 Agent 具备两个新能力：调用工具 和 多步推理。

这就引入了 ReAct 模式（Reasoning + Acting）。我用 LangGraph 的 create_react_agent 一行代码搭起骨架，然后用 @tool 装饰器定义了工具：

• search_documents：检索向量库。
• calculate：安全计算数学表达式（白名单+禁用builtins）。

Agent 的行为变了：它收到“节拍0.162s，一天产能”时，会先调用 calculate 算出 24*3600/0.162*2，再用 search_documents 查良率数据，最后综合给出答案。

RAG 让 Agent 能“读”，ReAct 让 Agent 能“想”和“做”。

尝试：多 Agent 协作（效果与反思）

复杂问题需要多视角。我设计了三角色协作：分析师（拆解问题）→ 程序员（设计方案）→ 审核员（把关结论）。

LangGraph 实现很自然——三个节点，线性边。CrewAI 我也跑通了，代码更简洁。

但实测下来，我必须诚实地说：在当前阶段，多 Agent 的边际收益不明显。

• 调用链路变长（3次LLM调用），延迟从2秒变成6秒。
• 成本和token消耗翻3倍。
• 对于90%的产线问题，单 Agent + 好工具已经足够。

这是一个重要的工程判断：不是技术越先进越好，而是匹配场景。多Agent更适合需要多角色博弈的开放式任务，而产线问答是收敛的。

我把多Agent保留为可选模式，但默认推荐单Agent。

交付：AI 不是玩具，是服务

Demo跑通只完成了30%。真正的挑战是让它稳定地跑起来。

我做了几件“非AI”但至关重要的事：

1. FastAPI 服务化：把 Agent 封装成 REST API，让上位机、Web UI、甚至企业微信机器人能统一调用。
2. 安全中间件：产线环境不能接受注入攻击。我加了三层防护——敏感词过滤、SQL注入正则、请求长度限制。
3. 结构化日志：每次API调用的耗时、token消耗、session_id全部记录。没有日志，出问题就是盲人摸象。
4. Docker 容器化：Python 环境、ChromaDB 依赖、模型文件全部打包。一条 docker-compose up -d 在任何服务器上跑起来。

这些工作占了我60%的时间。它们和AI无关，但它们决定了这个系统是“Demo”还是“服务”。

反思：AME 做 AI 的独特价值

AgentClaw 没有发明新算法，也没有发论文。它只是一个用现成技术解决真实问题的工程实践。

但这也正是 AME 做 AI 的独特价值所在：

• AI 工程师关心模型精度、SOTA分数。
• AME 关心系统稳定性、故障恢复时间、新人上手成本。

我用 AME 的思维做 AI：把它当作产线上的一个“工站”来设计。它有明确的输入（用户问题）、输出（回答）、节拍（响应延迟）、质量标准（准确率）、运维手册（日志与健康检查）。

当我把 AgentClaw 部署到 Docker，配置好健康检查，写好 FACA 错误记录集（36条踩坑实录）的那一刻，我感觉我不是在做 AI，我是在为一个新的数字工站做设备导入。

这，就是一个 AME 在 AI 时代的打开方式。