把多节点 Agent 编排压成单节点 ReAct：一次真实重构复盘
前段时间我把一条原本还算“规矩”的 Agent 编排链路，硬生生压成了单节点。 原始版本大概是这种气质： bootstrap plan tool_validate tool_call clarify chat 看起来层次分明，像一张写给评审看的 UML 图。真跑起来以后，感受更像在组装机关枪，每多一个节点，代码体积、状态字段、测试断言和联调排查成本就跟着长。 这篇文章记录的就是一次比较彻底的收
MCP、Tool Spec 与 Function Calling：别把三层协议揉成一锅粥
前言最近排查一条 AI 工具链路时，最容易把人绕进去的不是模型发疯，也不是某个参数名写错，而是脑子里把三层东西混成了一层： Java 侧维护的 AiTool / ToolSpec Python 侧拿到的 tool list / schema 模型侧的 function calling / tool calling 一开始看起来都像“工具定义”。看久了就会产生一种错觉：既然都有 name + d
一场被 pip 镜像污染带偏的 Python 升级故障：从 RemoteDisconnected 到干净 venv
这篇文章整理自一段公开聊天记录，主题很朴素：一台 Ubuntu 服务器上，项目本来只是想装依赖，结果 pip install -r requirements.txt 一路刷出 RemoteDisconnected('Remote end closed connection without response')。乍看像镜像站抽风，再看像 Python 3.11 升级后遗症，继续看又像
别再靠 Prompt 硬劝模型吐 JSON：Structured Outputs、Function Calling 与国产模型能力盘点
前言很多团队第一次做结构化输出，都会写出一句极其熟悉的咒语： 1请严格输出 JSON，不要解释 然后几轮之后，程序收到的内容往往是： 一坨长得像 JSON 但少了逗号的文本 一个合法 JSON，但字段缺了一半 一个字段结构没问题，但值一本正经地胡说八道 这不是模型跟你作对，这是你把三件不同的事混在了一起： Prompt 约束 Structured Outputs / JSON mode F
AI Agent Security 实现实践：对话阶段防泄露、防工具暴露与审计
这次改的是一个 FastAPI + LangGraph + MCP 的 AI 控制平面。问题起点很朴素：用户问了一句“你有哪些工具”“你的执行流程是什么”，模型老老实实把内部工具和编排动作抖出来了。系统没崩，脸先丢了。 这篇记录只写本次已经提交的 security 补丁，不展开下一阶段的 ContextBuilder 重构。换句话说，这是一篇 pre-context-builder 版本的安全落地
LangGraph 编排重构复盘：一次把“能跑”改成“可证据化运行”的实战
这次改造最有意思的地方，不是“把编排迁到 LangGraph”这件事本身，而是我们把一个常见工程陷阱踩出来又填平了： 到底是要“快速把 case 跑通”，还是要“把系统做成可长期治理”。 答案很明确：后者。 下面按真实时间线复盘，尽量给可复现证据，不讲玄学。 1. 讨论分歧：要不要用 fallback 快速过 case中途一度出现典型诱惑： 用户说“1号炉”，那就直接从 query 里正则提
LangGraph 从字段拼接到 MessagesState：两次提交把编排链路收口
这篇记录复盘最近两次连续提交： 76539e9：refactor(langgraph): 全量收口到MessagesState单一状态源 2138513：refactor(langgraph): 删除未激活respond节点并清理导出 一句话总结：把编排状态从“字段搬运工模式”改成“消息主链模式”，再把没上班的节点请出工位。 先说改造前的问题在这次重构前，编排链路同时维护几套上下文来源： q
LangGraph Checkpoint、Event 和 Replay：别把状态快照当业务事件
调试 LangGraph 时，最容易踩的一个坑不是代码写错，而是脑子里把三件不同的东西混成了一件事： event checkpoint replay 表面看它们都能回答“这轮到底发生了什么”，于是很多项目自然会冒出一个问题： “既然 LangGraph 已经有 checkpoint 和 replay，我自己写的 event 机制是不是多余了？” 这个问题我最近在一套 AI 编排服务里来回掰扯了