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.
动态范式编排：Plan-and-Solve + ReAct + Reflection 在 MCP AI 控制平面上的优化
本文围绕现有 Java MCP 工具执行层与 Python 控制平面之间的联动，先梳理当前实现快照，再提出一套以 Plan-and-Solve、ReAct 与 Reflection 为基础的动态范式编排优化方案，最终形成可复盘的执行路线、灰度策略与风险表。 当前实现快照Java MCP 工具链路Java 侧已经打通了内部 MCP 入口：AiMcpEntryService（atsi-iot/atsi
纯 Java AI vs Java MCP + Python Control Plane：重构方案与落地模块解析
背景第一版 AI 能力是典型的纯 Java 单体实现：请求进入 Java Web 层后，直接在同一进程内完成模型调用、工具路由、业务执行与响应拼装。这个方案早期上线快，但随着需求从「能用」走向「可控、可观测、可扩展」，问题开始集中暴露： 推理编排和业务工具耦合，修改工具策略会影响主链路稳定性。 流式输出与长任务状态管理能力弱，run 生命周期缺少统一抽象。 多工具权限控制分散在业务代码里，审计链