味儿福德詹的小站
  • 首页
  • AI
  • 归档
  • 分类
  • 标签
  • 关于

AI Chat 网关化重构工作日志:Java AI Gateway 签名上下文与 Python 鉴权落地

本篇记录本次 AI Chat 网关化重构的落地结果,重点是把请求入口、认证与业务上下文注入统一收口到 Java 网关,再由 Python 控制平面执行编排。 改造摘要 Java 成为 AI Gateway 统一入口: 前端不再直连 Python,而是走 /api/ai/*。 Java 在转发到 Python 前注入两类内部头: X-AI-GW-TOKEN X-AI-BIZ-CONTEXT(签名
2026-02-28
AI
#AI网关 #Java #Python #FastAPI #鉴权 #联调复盘 #SSE #AI工作日志

基于 OpenClaw 对照改造 iot-framework AI Orchestrator:终结非工具问题 CLARIFY 循环

背景这次改造聚焦一个真实线上体验问题:用户问的是通用解释类问题(本质不需要工具),Orchestrator 仍然进入 ReAct 规划,随后触发 CLARIFY,并在后续交互里反复追问,形成“看起来一直要补信息”的循环感。 目标很明确:在不扩大系统复杂度的前提下,借鉴 OpenClaw 的分层思路,把“是否需要工具”尽早判定,把 CLARIFY 收紧到真正可执行的场景,让非工具问题直接回到 CHA
2026-02-28
AI
#FastAPI #AI工作日志 #ReAct #Orchestrator #OpenClaw #CLARIFY #奥卡姆剃刀

奥卡姆剃刀式瘦身重构:ats_iot_ai AI 控制面分类复盘

这次复盘记录的是 ats_iot_ai 一轮典型的「奥卡姆剃刀式瘦身重构」:不再追求架构层面的概念完整性,而是优先保证主流程简单、稳定、可持续迭代。 背景:项目开始失控,必须回到核心 flow随着功能和抽象层不断叠加,编排链路已经从“可理解”滑向“难维护”:策略层、评估层、策略守卫与验证层交织,导致新增一个行为就要跨多个抽象点改动。这轮重构的目标很明确:聚焦核心 flow,把系统重新收敛到一条可解
2026-02-27
AI
#AI工作日志 #ReAct #重构复盘 #架构简化 #ats_iot_ai

PyCharm 调试 Uvicorn/FastAPI 与日志可见性排查

最近在调试一个 FastAPI + Uvicorn 的项目时,遇到两个高频问题: PyCharm 里到底怎么正确配 uvicorn main:app? 代码里明明写了 LOGGER.info(...),控制台却看不到日志? 这篇只讲可直接落地的做法。 1) PyCharm 里如何用 Uvicorn 调试新增一个 Python 类型 Run Configuration: Run: Module
2026-02-27
#Python #FastAPI #Uvicorn #PyCharm #调试

AI Chat 重构总复盘:Java MCP 收口、LLM 路由与稳定性治理

目标与边界本轮重构的目标是把 AI 聊天从“Java 单体链路”收敛为“Python 控制平面 + Java MCP 执行平面”,并解决线上已暴露的问题: 普通聊天误入 ReAct MCP 工具失败导致 run 直接失败 Qwen 超时后返回 echo 联调时 Python/Java token 不一致导致 MCP 401 边界上,Java 只保留 MCP + Tool 能力;会话编
2026-02-27
AI
#FastAPI #AI工作日志 #MCP #Qwen #ReAct #稳定性 #重构复盘

AI控制面生产化改造:LLM意图路由与ReAct执行边界

这次改造把 ats_iot_ai 的 Orchestrator 从 MVP 规则路由,切到生产模式的 LLM 驱动编排。 背景线上痛点很明确:process_input 里 IntentRouter.route(query) 主要依赖模式匹配,无法稳定处理语义歧义、槽位缺失和复杂意图。与此同时,React 执行层存在 query 二次解析,执行边界不够清晰。 目标是把链路拉直为: Understa
2026-02-25
AI
#AI工作日志 #Qwen #ReAct #Orchestrator #IntentRouter #PolicyEngine #Verify

ReAct Orchestrator 意图识别升级:踩坑与 QA 纪要

这篇记录来自一次真实的架构评审:我们发现当前 Orchestrator 在意图识别阶段还偏“query直通”,导致后续策略选择和工具调用容易偏离用户真实意图。本文沉淀核心踩坑、关键 QA 结论和可执行改造路径。 背景当前链路已经可用:/ai/runs + SSE + Tool Call。但意图层的主要问题是: 路由以规则/关键词为主,语义理解和槽位抽取不足。 Policy 更像静态映射
2026-02-25
AI
#AI工作日志 #ReAct #Orchestrator #AI工程 #意图识别 #Tool Calling

Java/Python MCP 401 排查里程碑:Token 对齐与方案简化

本篇记录本次 Java/Python MCP 401 问题的收敛结论、方案调整与发布证据。 里程碑结论 401 根因已确认:Java 侧与 Python 侧在 MCP 鉴权 token 上不一致,导致请求头 X-AI-MCP-TOKEN 校验失败。 方案已简化:Python 侧仅保留一个配置入口 MCP_API_TOKEN,默认值固定为 AAA,移除复杂 fallback 链路,减少歧义
2026-02-22
AI
#Java #Python #AI工作日志 #MCP #里程碑 #401排查

RAG可插拔改造复盘:OpenSearch混合检索、RRF与增量Ingest

一句话结论这轮我把 RAG 从“单一本地检索”改造成“可插拔检索链路”:新增 OpenSearch Provider(BM25+向量+过滤)、Hybrid RRF、低置信/复杂 Query 的 rerank 触发、分钟级增量 ingest + upsert,并通过 fallback + 默认开关关闭确保 /ai/runs 主链路稳定不受影响。 Done 标准 检索 Provider 可
2026-02-21
AI
#AI工作日志 #RAG #OpenSearch #工程复盘 #STAR

Customized Spec:我的 AI 开发流程规范(PO/架构师监管 + 多Agent并行)

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

搜索

Hexo Fluid