单模型编排四阶段改造复盘：从提示词、护栏到记忆与清理
这次复盘对应 ats_iot_ai 近期一轮比较完整的单模型编排内核治理。目标不是“再做一套新框架”，而是在不改外部 API 契约、不打乱 SSE 事件语义的前提下，把原本耦合较重的编排实现，收敛成可以继续演进的 runtime 分层。 先给结论：这轮改造真正完成的，不是几个 helper 函数的搬家，而是把项目推进到了“单 LLM 编排 + Java MCP 工具执行”的清晰架构上，并且把 pr
项目技术选型调研：通用Agent与LangGraph+LlamaIndex对比
这篇文章基于实际业务场景（原子查询工具 + RAG 分析）给出技术选型依据，重点对比 OpenClaw 这类强 Agent 项目与 LangGraph + LlamaIndex 组合方案。 1. 调研结论（先给结论）对于当前项目定位（“可控的数据查询与分析助手”，而非“全自主代码代理”），推荐主选型为： 编排内核：LangGraph 数据/RAG 层：LlamaIndex 工程护栏参考
单 LLM 节点不是简化：OpenClaw Prompt 注入范式与护栏工程化重构
前言这篇文章写给已经在做 Agent 编排、并且踩过“意图层拆太多 + Prompt 越改越乱 + 护栏和主流程耦合”坑的工程师。 核心观点先摆在前面： 单 LLM 节点不是“把所有事都丢给模型”。 OpenClaw 的关键价值，不在“单节点”，而在“模型自决 + 工程护栏 + Prompt 注入可插拔”。 真正可维护的实现，必须把 决策、注入、护栏、记忆 四层切开。 一、单节点到底是什么：
从双层意图到单 LLM 自决：OpenClaw 范式与护栏工程化落地
很多 AI 编排系统一开始都会走到同一个架构： 先做 intent parser（判定 chat / tool） 再进入 ReAct（plan/act/observe） 这套架构可控，但随着需求复杂化，经常出现三个问题： 决策重复（先判一次 intent，再让 planner 再判一次） 状态割裂（intent 状态和 tool 状态不同步） prompt 分裂
从零把 uni-app 接到微信开发者工具：HBuilderX 全流程与踩坑复盘
这篇写给后端同学：不懂前端也能把 uni-app 项目跑到微信开发者工具里预览页面。 核心结论先说： uni-app 源码目录不能直接当小程序目录导入微信开发者工具。 必须先用 HBuilderX 编译，拿到 unpackage/dist/build/mp-weixin 产物。 再让微信开发者工具打开这个产物目录（或通过 project.config.json 的 miniprogramRoot
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（签名
基于 OpenClaw 对照改造 iot-framework AI Orchestrator：终结非工具问题 CLARIFY 循环
背景这次改造聚焦一个真实线上体验问题：用户问的是通用解释类问题（本质不需要工具），Orchestrator 仍然进入 ReAct 规划，随后触发 CLARIFY，并在后续交互里反复追问，形成“看起来一直要补信息”的循环感。 目标很明确：在不扩大系统复杂度的前提下，借鉴 OpenClaw 的分层思路，把“是否需要工具”尽早判定，把 CLARIFY 收紧到真正可执行的场景，让非工具问题直接回到 CHA
奥卡姆剃刀式瘦身重构：ats_iot_ai AI 控制面分类复盘
这次复盘记录的是 ats_iot_ai 一轮典型的「奥卡姆剃刀式瘦身重构」：不再追求架构层面的概念完整性，而是优先保证主流程简单、稳定、可持续迭代。 背景：项目开始失控，必须回到核心 flow随着功能和抽象层不断叠加，编排链路已经从“可理解”滑向“难维护”：策略层、评估层、策略守卫与验证层交织，导致新增一个行为就要跨多个抽象点改动。这轮重构的目标很明确：聚焦核心 flow，把系统重新收敛到一条可解