AI控制面生产化改造：LLM意图路由与ReAct执行边界
这次改造把 ats_iot_ai 的 Orchestrator 从 MVP 规则路由，切到生产模式的 LLM 驱动编排。 背景线上痛点很明确：process_input 里 IntentRouter.route(query) 主要依赖模式匹配，无法稳定处理语义歧义、槽位缺失和复杂意图。与此同时，React 执行层存在 query 二次解析，执行边界不够清晰。 目标是把链路拉直为： Understa
ReAct Orchestrator 意图识别升级：踩坑与 QA 纪要
这篇记录来自一次真实的架构评审：我们发现当前 Orchestrator 在意图识别阶段还偏“query直通”，导致后续策略选择和工具调用容易偏离用户真实意图。本文沉淀核心踩坑、关键 QA 结论和可执行改造路径。 背景当前链路已经可用：/ai/runs + SSE + Tool Call。但意图层的主要问题是： 路由以规则/关键词为主，语义理解和槽位抽取不足。 Policy 更像静态映射
Java/Python MCP 401 排查里程碑：Token 对齐与方案简化
本篇记录本次 Java/Python MCP 401 问题的收敛结论、方案调整与发布证据。 里程碑结论 401 根因已确认：Java 侧与 Python 侧在 MCP 鉴权 token 上不一致，导致请求头 X-AI-MCP-TOKEN 校验失败。 方案已简化：Python 侧仅保留一个配置入口 MCP_API_TOKEN，默认值固定为 AAA，移除复杂 fallback 链路，减少歧义
RAG可插拔改造复盘：OpenSearch混合检索、RRF与增量Ingest
一句话结论这轮我把 RAG 从“单一本地检索”改造成“可插拔检索链路”：新增 OpenSearch Provider（BM25+向量+过滤）、Hybrid RRF、低置信/复杂 Query 的 rerank 触发、分钟级增量 ingest + upsert，并通过 fallback + 默认开关关闭确保 /ai/runs 主链路稳定不受影响。 Done 标准 检索 Provider 可
Customized Spec：我的 AI 开发流程规范（PO/架构师监管 + 多Agent并行）
这不是“多加一层流程”，而是把已经在做的事情变成可复用、可审计、可并行扩展的工程规范。 为什么要做这份 Spec过去 AI 研发里最常见的问题不是“模型不够强”，而是： 需求口径经常漂移，执行层只能边做边猜。 多个 Agent 并行时，边界不清，返工和冲突频繁。 结果难复盘，出了问题只能靠个人记忆追责。 所以我把流程标准化为 Customized Spec：用 PO/架构师做监管闭环
里程碑进展：Orchestrator 动态范式编排（Plan-and-Solve / ReAct / Reflection）落地
动态范式 Orchestrator 改造完成，本文记录本轮里程碑的目标、交付、兼容性与下一步计划。 1) 里程碑目标 将单路径编排升级为“按意图动态选择策略”的多范式执行框架。 在不破坏既有事件契约的前提下，引入 Plan-and-Solve / ReAct / Reflection 三类策略能力。 补齐可观测链路，支撑后续运行质量评估与策略演进。 2) 本次完成内容（按模块
Dify 还是自研 RAG：铸造 MES/ERP 场景的架构共创与落地计划
背景与目标本篇用于把一次“Dify vs 自研 RAG”的架构讨论整理成可复盘记录，避免后续只记结论、不记前提。 讨论前提： 已完成一轮 Python AI 控制面重构。 需要快速接入铸造行业知识库能力。 同时满足“生产可用”和“可作为面试项目叙事”两类目标。 数据来源复杂（公众号、书籍、工艺参数文档、行业文档），噪声高、知识密度高。 业务并行存在 MES 实时数据工具调用 + 行业知识问答两类
里程碑进展：Java AI 模块配置与依赖清理（MCP 版）
里程碑范围本次里程碑聚焦 Java 侧 AI 模块的“减法治理”：明确 MCP 方案的保留项，移除历史遗留配置与依赖，降低维护复杂度并收敛运行面。 配置清理结果（YAML）在本地 YAML 配置中，已完成 MCP-only 重构的配置收口： 删除历史遗留且已废弃的配置段：ai.model、ai.store、ai.prompt、ai.archive。 保留当前仍在使用的配置段：ai.mcp、ai.