Customized Spec：我的 AI 开发流程规范（PO/架构师监管 + 多Agent并行）

这不是“多加一层流程”，而是把已经在做的事情变成可复用、可审计、可并行扩展的工程规范。 为什么要做这份 Spec过去 AI 研发里最常见的问题不是“模型不够强”，而是： 需求口径经常漂移，执行层只能边做边猜。 多个 Agent 并行时，边界不清，返工和冲突频繁。 结果难复盘，出了问题只能靠个人记忆追责。 所以我把流程标准化为 Customized Spec：用 PO/架构师做监管闭环
AI
#AI工作日志 #Spec #PO #架构 #Multi-Agent #工程流程

里程碑进展：Orchestrator 动态范式编排（Plan-and-Solve / ReAct / Reflection）落地

动态范式 Orchestrator 改造完成，本文记录本轮里程碑的目标、交付、兼容性与下一步计划。 1) 里程碑目标 将单路径编排升级为“按意图动态选择策略”的多范式执行框架。 在不破坏既有事件契约的前提下，引入 Plan-and-Solve / ReAct / Reflection 三类策略能力。 补齐可观测链路，支撑后续运行质量评估与策略演进。 2) 本次完成内容（按模块
AI
#AI工作日志 #ReAct #MCP #Orchestrator #Plan-and-Solve #Reflection #里程碑

Dify 还是自研 RAG：铸造 MES/ERP 场景的架构共创与落地计划

背景与目标本篇用于把一次“Dify vs 自研 RAG”的架构讨论整理成可复盘记录，避免后续只记结论、不记前提。 讨论前提： 已完成一轮 Python AI 控制面重构。 需要快速接入铸造行业知识库能力。 同时满足“生产可用”和“可作为面试项目叙事”两类目标。 数据来源复杂（公众号、书籍、工艺参数文档、行业文档），噪声高、知识密度高。 业务并行存在 MES 实时数据工具调用 + 行业知识问答两类
AI
#AI工作日志 #MCP #AI工程 #RAG #Dify #架构设计 #知识库

里程碑进展：Java AI 模块配置与依赖清理（MCP 版）

里程碑范围本次里程碑聚焦 Java 侧 AI 模块的“减法治理”：明确 MCP 方案的保留项，移除历史遗留配置与依赖，降低维护复杂度并收敛运行面。 配置清理结果（YAML）在本地 YAML 配置中，已完成 MCP-only 重构的配置收口： 删除历史遗留且已废弃的配置段：ai.model、ai.store、ai.prompt、ai.archive。 保留当前仍在使用的配置段：ai.mcp、ai.
AI
#AI工作日志 #MCP #Java #AI工程 #里程碑 #依赖治理 #配置清理

动态范式编排：Plan-and-Solve + ReAct + Reflection 在 MCP AI 控制平面上的优化

本文围绕现有 Java MCP 工具执行层与 Python 控制平面之间的联动，先梳理当前实现快照，再提出一套以 Plan-and-Solve、ReAct 与 Reflection 为基础的动态范式编排优化方案，最终形成可复盘的执行路线、灰度策略与风险表。 当前实现快照Java MCP 工具链路Java 侧已经打通了内部 MCP 入口：GatewayEntryService（enterprise-
AI
#Agent #ReAct #MCP #Orchestrator #AI工程 #Plan-and-Solve #Reflection #架构分析

纯 Java AI vs Java MCP + Python Control Plane：重构方案与落地模块解析

背景第一版 AI 能力是典型的纯 Java 单体实现：请求进入 Java Web 层后，直接在同一进程内完成模型调用、工具路由、业务执行与响应拼装。这个方案早期上线快，但随着需求从「能用」走向「可控、可观测、可扩展」，问题开始集中暴露： 推理编排和业务工具耦合，修改工具策略会影响主链路稳定性。 流式输出与长任务状态管理能力弱，run 生命周期缺少统一抽象。 多工具权限控制分散在业务代码里，审计链
AI
#AI工作日志 #MCP #Python #Java #AI工程 #架构设计