单 Agent 编排里，Prompt、JSON Schema 与 Function Calling 该怎么收口

最近我把一个 FastAPI + LangGraph 的控制平面，从“多节点编排”一路砍到“单节点 Agent Loop”。 砍到最后，最费脑子的地方已经不是“节点怎么连”，而是这三个问题： prompt 里到底该塞什么。 工具的输入约束到底该放在哪一层。 如果要接官方 function calling，它和现在这套 response schema + JSON 解析 有什么本质区别。 这篇就
AI
#Agent #Function Calling #LangGraph #Prompt工程 #工程化 #控制平面

把多节点 Agent 编排压成单节点 ReAct：一次真实重构复盘

前段时间我把一条原本还算“规矩”的 Agent 编排链路，硬生生压成了单节点。 原始版本大概是这种气质： bootstrap plan tool_validate tool_call clarify chat 看起来层次分明，像一张写给评审看的 UML 图。真跑起来以后，感受更像在组装机关枪，每多一个节点，代码体积、状态字段、测试断言和联调排查成本就跟着长。 这篇文章记录的就是一次比较彻底的收
AI
#AI工作日志 #Agent #LangGraph #ReAct #架构重构 #复盘

MCP、Tool Spec 与 Function Calling：别把三层协议揉成一锅粥

前言最近排查一条 AI 工具链路时，最容易把人绕进去的不是模型发疯，也不是某个参数名写错，而是脑子里把三层东西混成了一层： Java 侧维护的 AiTool / ToolSpec Python 侧拿到的 tool list / schema 模型侧的 function calling / tool calling 一开始看起来都像“工具定义”。看久了就会产生一种错觉：既然都有 name + d
AI
#AI工作日志 #Function Calling #AI Agent #MCP #Tool Calling #JSON Schema

一场被 pip 镜像污染带偏的 Python 升级故障：从 RemoteDisconnected 到干净 venv

这篇文章整理自一段公开聊天记录，主题很朴素：一台 Ubuntu 服务器上，项目本来只是想装依赖，结果 pip install -r requirements.txt 一路刷出 RemoteDisconnected('Remote end closed connection without response')。乍看像镜像站抽风，再看像 Python 3.11 升级后遗症，继续看又像
AI
#AI工作日志 #Python #故障排查 #Ubuntu #pip #运维

别再靠 Prompt 硬劝模型吐 JSON：Structured Outputs、Function Calling 与国产模型能力盘点

前言很多团队第一次做结构化输出，都会写出一句极其熟悉的咒语： 1请严格输出 JSON，不要解释 然后几轮之后，程序收到的内容往往是： 一坨长得像 JSON 但少了逗号的文本 一个合法 JSON，但字段缺了一半 一个字段结构没问题，但值一本正经地胡说八道 这不是模型跟你作对，这是你把三件不同的事混在了一起： Prompt 约束 Structured Outputs / JSON mode F
AI
#AI工作日志 #Function Calling #Qwen #JSON Schema #Structured Outputs #Prompt Engineering #Kimi #GLM #DeepSeek

AI Agent Security 实现实践：对话阶段防泄露、防工具暴露与审计

这次改的是一个 FastAPI + LangGraph + MCP 的 AI 控制平面。问题起点很朴素：用户问了一句“你有哪些工具”“你的执行流程是什么”，模型老老实实把内部工具和编排动作抖出来了。系统没崩，脸先丢了。 这篇记录只写本次已经提交的 security 补丁，不展开下一阶段的 ContextBuilder 重构。换句话说，这是一篇 pre-context-builder 版本的安全落地
AI
#AI工作日志 #Agent #LangGraph #Security #Prompt Injection #FastAPI

LangGraph 编排重构复盘：一次把“能跑”改成“可证据化运行”的实战

这次改造最有意思的地方，不是“把编排迁到 LangGraph”这件事本身，而是我们把一个常见工程陷阱踩出来又填平了： 到底是要“快速把 case 跑通”，还是要“把系统做成可长期治理”。 答案很明确：后者。 下面按真实时间线复盘，尽量给可复现证据，不讲玄学。 1. 讨论分歧：要不要用 fallback 快速过 case中途一度出现典型诱惑： 用户说“1号炉”，那就直接从 query 里正则提
AI
#AI工作日志 #LangGraph #重构复盘 #Tool Schema #联调实战

LangGraph 从字段拼接到 MessagesState：两次提交把编排链路收口

这篇记录复盘最近两次连续提交： 76539e9：refactor(langgraph): 全量收口到MessagesState单一状态源 2138513：refactor(langgraph): 删除未激活respond节点并清理导出 一句话总结：把编排状态从“字段搬运工模式”改成“消息主链模式”，再把没上班的节点请出工位。 先说改造前的问题在这次重构前，编排链路同时维护几套上下文来源： q
AI
#AI工作日志 #工程复盘 #LangGraph #架构重构 #FastAPI

LangGraph Checkpoint、Event 和 Replay：别把状态快照当业务事件

调试 LangGraph 时，最容易踩的一个坑不是代码写错，而是脑子里把三件不同的东西混成了一件事： event checkpoint replay 表面看它们都能回答“这轮到底发生了什么”，于是很多项目自然会冒出一个问题： “既然 LangGraph 已经有 checkpoint 和 replay，我自己写的 event 机制是不是多余了？” 这个问题我最近在一套 AI 编排服务里来回掰扯了
AI
#AI工作日志 #LangGraph #Checkpoint #调试 #架构复盘

LangGraph Checkpoint 改造复盘：从内存快照到可恢复执行

这次改造的目标很朴素：让编排流程别再“断电失忆”。 项目原来已经有 LangGraph thread_id，也已经把澄清流程做成了 interrupt/resume 语义。但 checkpoint 用的是进程内内存 saver，服务重启后现场直接蒸发。于是用户问一句“继续”，系统看着你，内心是“我是谁我在哪”。 下面按 STAR 记录这次改造，顺便把关键 QA 和踩坑细节摊开讲清楚。 S
AI
#AI工作日志 #LangGraph #复盘 #Checkpoint #STAR