<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[寻道AI，探索AI无限可能！]]></title><description><![CDATA[探索未知，分享所知。作为一名系统架构师，我曾带领团队打造多个行业领域的系统平台。如今，我正踏上AI大模型的探索之旅，期待与你一起成长，迎接技术的未来。]]></description><link>https://blog.csdn.net/xiaobing259</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; xiaobing259]]></copyright><item><title><![CDATA[AI Agent 工程化开发实战（四）：工具调用循环——解构 create_agent 背后的机制]]></title><link>https://blog.csdn.net/xiaobing259/article/details/169068490</link><guid>https://blog.csdn.net/xiaobing259/article/details/169068490</guid><author>xiaobing259</author><pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[Agent 是怎么「会调工具」的？本文解构 `create_agent` 背后的工具调用循环：`@tool`、`bind_tools`、`ToolNode`、`tools_condition` 四个零件拼成「模型喊工具 → 工具干活 → 模型收尾」的循环图，再用计算 + 查库 + 联网搜索的多工具案例看模型自己挑工具、连环调用。工程化要点：`recursion_limit` 防死循环、工具的线程安全、超时与模型降级。]]></description><category></category></item><item><title><![CDATA[AI Agent 工程化开发实战（三）：StateGraph 与状态管理——节点、边、Reducer]]></title><link>https://blog.csdn.net/xiaobing259/article/details/168774285</link><guid>https://blog.csdn.net/xiaobing259/article/details/168774285</guid><author>xiaobing259</author><pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[从本篇正式进入 LangGraph 运行时。手写一遍 StateGraph，搞懂四个核心概念——图、节点、边、状态 Schema，再讲清状态如何被合并：默认是「后写覆盖」，消息列表要用 `add_messages` Reducer 追加。最后做一个带记忆的多轮对话 Agent，看清状态跨轮累积；并理清 TypedDict、Reducer 选择、导入来源，以及 StateGraph 与 Functional API 两条写法。]]></description><category></category></item><item><title><![CDATA[AI Agent 工程化开发实战（二）：5 分钟跑通第一个 Deep Agent，然后拆开它]]></title><link>https://blog.csdn.net/xiaobing259/article/details/168774045</link><guid>https://blog.csdn.net/xiaobing259/article/details/168774045</guid><author>xiaobing259</author><pubDate>Fri, 23 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[AI Agent 开发最省力的入口在哪？本文用 `create_deep_agent` 一行代码跑通一个能查天气的 Agent，再把它拆开：内部是 `create_agent`（薄壳）加一套内置中间件栈，文件、子 Agent 等能力都由中间件注入，最终落到 LangGraph 运行时。由此建立「省事往高层、控制往低层」的下沉指南，并给出贯穿后续每篇的「Deep Agents 等价实现」贴士模板。]]></description><category></category></item><item><title><![CDATA[AI Agent 工程化开发实战（一）：Agent 开发的四个层次——积木、运行时、薄壳、套件]]></title><link>https://blog.csdn.net/xiaobing259/article/details/167587674</link><guid>https://blog.csdn.net/xiaobing259/article/details/167587674</guid><author>xiaobing259</author><pubDate>Wed, 14 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[LangChain、LangGraph、Deep Agents 到底什么关系？本文澄清最常见的误解：官方其实是 3 类产品（Runtime / Framework / Harness），但依赖关系上是 4 层——因为 LangChain 被劈成了「积木（langchain-core，在 LangGraph 之下）+ 薄壳（create_agent，在 LangGraph 之上）」两块。用一张调用链图和四道选型定位，帮你建立「自底向上 = 依赖顺序、自顶向下 = 使用顺序」的双向认知]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十八）：全息地图——十七篇判据拼成一张「拿处境一查，就知道看哪篇、抓哪个决策、抄哪段代码」的检索图]]></title><link>https://blog.csdn.net/xiaobing259/article/details/167130140</link><guid>https://blog.csdn.net/xiaobing259/article/details/167130140</guid><author>xiaobing259</author><pubDate>Mon, 12 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[模块四（收尾）的收官篇、全专栏唯一一篇「不挖新题、只做总图与收束」的总纲文。它是开篇《四大支柱》的镜像——开篇自上而下拆骨架（四大支柱 + 三底座 + 双轨路线图），收官自下而上把十七篇合回骨架，再叠一个「拿处境一查」的检索入口。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十七）：金融级 AI 落地——决策可追溯/可复现/可追责/不可抵赖这四件事怎么做]]></title><link>https://blog.csdn.net/xiaobing259/article/details/167121509</link><guid>https://blog.csdn.net/xiaobing259/article/details/167121509</guid><author>xiaobing259</author><pubDate>Wed, 07 Oct 2026 08:00:00 +0800</pubDate><description><![CDATA[「金融级 AI 落地」——把第 16 篇政企五关（准入 + 运维）之后那一层「决策级举证」补上：金融级的第一性不是「跑不跑得动」，是「每一笔放行/拒绝能不能被审计、被复现、被追责、被证明没被改过」，落点是一个纯标准库、离线可跑、可断言的「金融级决策审计链核对器」——把每一笔 AI 决策编码成一条可举证的记录（决策 id + 输入指纹 + 三元组版本 + 依据 + 操作人/审批人/责任人 + 前序链哈希），确定性吐出「这一笔能不能上法庭 + 断链点在哪 + 待人工确认清单」。模块四「行业落地与延展」的第二篇，]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十六）：政企国产化避坑——合规/信创名录/私有化运维/国产硬件适配/原厂支持这五道关怎么过]]></title><link>https://blog.csdn.net/xiaobing259/article/details/167120753</link><guid>https://blog.csdn.net/xiaobing259/article/details/167120753</guid><author>xiaobing259</author><pubDate>Mon, 05 Oct 2026 14:30:00 +0800</pubDate><description><![CDATA[「政企国产化避坑」——把第 15 篇选型地图上「国产化/私有化」那根只标没展开的约束轴，展开成政企落地的五道关（合规 / 信创 / 运维 / 适配 / 支持），顺序锁死「先过边界、再谈性能」，落点是一个纯标准库、离线可跑、可断言的「政企落地五关核对器」——输入「我的处境」（用了哪些组件、什么部署形态、数据什么分级、几个人运维、跑在什么国产硬件上、有没有原厂维保）确定性吐出一份「被哪几关卡住 + 带依据的核对结论 + 待人工确认清单」。模块四「行业落地与延展」的第一篇，给行业落地开门]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十五）：开源工具箱 30+ 选型地图——按“你干的活 × 你的约束”两个坐标轴，把网关/评测/灰度/Prompt 管理/Trace/向量库/推理引擎/多 Agent 框架摊成一张能查]]></title><link>https://blog.csdn.net/xiaobing259/article/details/166641644</link><guid>https://blog.csdn.net/xiaobing259/article/details/166641644</guid><author>xiaobing259</author><pubDate>Wed, 30 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[本文构建了一张基于“任务场景×约束条件”的大模型工程化工具选型地图，打破传统工具清单的无效罗列。横轴为14个核心流水线站点（如网关、评测、向量库等），纵轴为6类关键约束（如数据不出域、团队运维能力等），每格给出可查、可断言的选型判据，复用前十四篇实战结论，拒绝脱离场景的“谁最强”排名。强调“无普适最优，只有约束下的最优”，提供程序化查询能力（rank(query)），实现精准匹配与决策支持，真正解决“记了五十个工具仍选不准”的痛点。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十四）：Multi-Agent 协作实战——N 个三元组 + 一张协作契约边表：单元门与端到端协作门、编排原子发布、跨 Agent 父子 Trace、错误沿边传播与归因]]></title><link>https://blog.csdn.net/xiaobing259/article/details/166641623</link><guid>https://blog.csdn.net/xiaobing259/article/details/166641623</guid><author>xiaobing259</author><pubDate>Mon, 28 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[多Agent协作的痛点不在单个Agent能力，而在“边”——即Agent间的协作契约。本文提出“N个三元组 + 一张边表”的治理框架，强调边层（如schema、超时、兜底、防环、预算）需像代码一样版本化、可追溯。通过编排原子发布、端到端评测、跨Agent trace与错误归因，实现从“单点优秀”到“链路可靠”的跃迁。核心：管好边，才能让多Agent真正协同。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十三）：LLMOps 不完全指南——LLMOps 与 MLOps 的区别到底在哪：发布原子不是模型，是 Prompt/数据/模型版本三元组]]></title><link>https://blog.csdn.net/xiaobing259/article/details/166139292</link><guid>https://blog.csdn.net/xiaobing259/article/details/166139292</guid><author>xiaobing259</author><pubDate>Wed, 23 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[本文揭示LLMOps的核心：一次可信发布的原子单位不是单个模型或Prompt，而是“版本三元组”——即Prompt、数据、模型三者的不可变组合。 作者以亲身事故为例，指出仅管理零件不等于管理发布，导致回滚无据。提出“六站流水线”方案：从注册、评测、发布到观测、反馈与退化监控，将前12篇独立构建的组件串联成可复现、可回滚的飞轮系统。关键在于单一变更原则与三元组指纹，确保每次发布身份清晰、责任可溯。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十二）：RAG 数据工程底座——采集到入库流水线（离线+在线双链路）]]></title><link>https://blog.csdn.net/xiaobing259/article/details/166139118</link><guid>https://blog.csdn.net/xiaobing259/article/details/166139118</guid><author>xiaobing259</author><pubDate>Mon, 21 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[本文聚焦知识库建设的“数据工程底座”构建，指出人工补料无法应对上游出料速度，根源在于缺乏自动化、可追溯的数据流水线。提出六段式流水线：采集（来源管控）、清洗（四道过滤闸）、切片（按类型分层切）、向量化（模型接口封装）、版本/血缘/权限管理、双链路更新（离线批量与在线增量隔离）。通过标准化流程实现文档从源头到入库的持续、干净、可追溯供给，支撑第11篇提出的换版、巡检等治理机制，真正筑牢知识库“粮仓地基”。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十一）：知识库防腐坏——巡检揪出缺/腐/乱、治理先软下架止血、灰度换版可回滚：模型没换、prompt 没换，RAG 正确率却往下掉，先别查模型，查粮仓]]></title><link>https://blog.csdn.net/xiaobing259/article/details/165242919</link><guid>https://blog.csdn.net/xiaobing259/article/details/165242919</guid><author>xiaobing259</author><pubDate>Wed, 16 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[第 10 篇《Human-in-the-Loop 反馈闭环》结尾我讲过一句话：闭环筛到最后，还剩一类我处理不了的样本：用户问的知识点，模型答得没错，是知识库里根本没有、或者躺着过期版本。我原以为这话是说给别人听的，直到上周自己踩进去。用户问“新款 X100 的保修政策”，检索把这句拆开，top 结果回了一页旧文档：库里根本没有 X100 的保修页，躺在那的是上一代 X90 的过期保修政策。我顺手把整库过了一遍，越查越心虚：该有的新政策没有，过期的旧政策当宝，同一款 X80 的“官方参数”在检索结果里三个版本]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（十）：Human-in-the-Loop 反馈闭环——三层清洗打造 Golden Set，拒绝“点赞即真理”]]></title><link>https://blog.csdn.net/xiaobing259/article/details/165242227</link><guid>https://blog.csdn.net/xiaobing259/article/details/165242227</guid><author>xiaobing259</author><pubDate>Mon, 14 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[第 9 篇《Token 成本六维优化》结尾我说过一句话：再压就伤质量，而伤没伤，评测集说了不算——线上真实用户觉得行不行，得有人把话递回来。我把话递回来的方式很朴素：给每个回答挂上点赞点踩，攒够一批回灌 golden set，让质量底线跟着真实反馈走。上线第一周数据漂亮得不像话——500 条反馈，一片叫好。团队兴冲冲把“被赞最多的输出”当 gold 灌进评测集，第二周评测分数开始说胡话：某个被用户狂赞的回答，人工一查是“顺耳但错”的流畅幻觉。那一刻我明白：**把“用户觉得好”直接当“答案是对的”，评测集就废]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（九）：Token 成本六维优化——把 token 账本摊开算：缓存命中、上下文裁剪、小模型路由、重试预算，一份 mock 日流量实测省 60% 成本]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164428158</link><guid>https://blog.csdn.net/xiaobing259/article/details/164428158</guid><author>xiaobing259</author><pubDate>Wed, 09 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[月初我对账单，厂商后台那个总额吓我一跳。查下来模型没调价、业务量也没暴涨，可账单比上月翻了快一倍——问题不是模型贵，是没人算过账。Token 成本是算出来的业务属性，厂商账单只给一口价总额，我把它拉出来一摊，最烧钱的那条链自己就浮出来了。钱大头不在“干活”的输出，而是每次请求重发的 system 前缀、RAG 每问拖回来的 8 篇文档、fallback 到大模型那几条链，还有重试把调用翻倍。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（八）：OTel + LangFuse 全链路 Trace——把网关、护栏、SchemaGate 全部打点串起来，出问题一眼定位到环节]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164427991</link><guid>https://blog.csdn.net/xiaobing259/article/details/164427991</guid><author>xiaobing259</author><pubDate>Mon, 07 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[凌晨一点，`schema_validation_exhausted` 这条结构化告警第三次亮起。下游没崩、没有 500，可“为什么偏偏这单走兜底”连我也答不上来：网关日志显示主路超时、重试 2 次兜到 gpt4；护栏日志显示 medium 风险 strip 放行；SchemaGate 日志显示缺“金额”字段、类型错、重试耗尽。三份日志都对，时间戳也对得上，人肉拼了两小时才凑出因果链。全链路 Trace 治的就是这个毛病：可观测不等于“每环节都打日志”]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（七）：JSON Schema 强约束——模型吐的 json 不合规？schema 校验不通过，重试、兜底、降级一条龙]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164269403</link><guid>https://blog.csdn.net/xiaobing259/article/details/164269403</guid><author>xiaobing259</author><pubDate>Wed, 02 Sep 2026 08:00:00 +0800</pubDate><description><![CDATA[针对模型输出不合规JSON导致下游崩溃、静默NaN或工具传参错误，本文提出输出侧第二道物理闸：JSON Schema结构校验。方案先脱敏（上篇），再经SchemaGate锁格式：校验失败则带反馈重试，超预算返回结构化error object而非500。探讨了四种技术路线（校验+重试、厂商structured output、语法约束采样、json_repair），并给出离线可跑的demo。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（六）：OWASP LLM 2025 安全护栏——prompt injection 拦截 + 敏感信息脱敏的最小实现]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164193351</link><guid>https://blog.csdn.net/xiaobing259/article/details/164193351</guid><author>xiaobing259</author><pubDate>Mon, 31 Aug 2026 08:00:00 +0800</pubDate><description><![CDATA[上线第三周，客服 AI 当着客户的面，把身份证号完整念了一遍。用户那头就一句话：“帮我查一下订单。”——一个攻击性的字眼都没有，是知识库里一条“用户要求核对时输出完整信息”被检索带进了上下文。这就是 OWASP 2025 说的间接注入，RAG 生产态的首要泄露入口。这篇给网关挂两道闸：输入前置拦截 prompt injection，输出后置敏感信息脱敏。上篇留过一句：网关能力清单里“安全钩子”两行是提前留好的挂载点——钩子有了，闸没挂。纯标准库、离线可验，不把用户数据送给第三方审核 API。]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（五）：LLM 网关到底怎么选 - 2026 自研 / LiteLLM/Portkey/Kong/One API 全面对比]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164003347</link><guid>https://blog.csdn.net/xiaobing259/article/details/164003347</guid><author>xiaobing259</author><pubDate>Wed, 26 Aug 2026 08:00:00 +0800</pubDate><description><![CDATA[registry 上线第二周，转人工率又爬回来了。这次不是回滚错版本——是回滚了也没用：值班同学把版本指针切回旧版，等了十分钟，曲线没下来。查日志才看清：线上压根没人按版本 ID 路由——三个服务直连 LLM API，各自写各自的重试，key 散在三个环境变量里，只有一处接了 registry 的 get()。这篇是 LLM 网关选型，但我先不摆参数，只回答一个问题：什么规模，选什么网关，才能让“按版本 ID 路由 Prompt”落地。答案先放这儿：registry 管的是资产，网关管的是路由]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（四）：Prompt 版本管理——把提示词做成可 diff、可评审、可回滚的代码资产]]></title><link>https://blog.csdn.net/xiaobing259/article/details/164002627</link><guid>https://blog.csdn.net/xiaobing259/article/details/164002627</guid><author>xiaobing259</author><pubDate>Mon, 24 Aug 2026 08:00:00 +0800</pubDate><description><![CDATA[Prompt 版本管理：从字符串到工程资产 本文探讨了Prompt管理从随意修改走向工程化的完整方案。当前Prompt管理存在三大痛点：(1)热修改无版本记录，(2)与代码耦合导致回滚粒度粗，(3)缺乏评审机制直接上线。这些问题的核心在于Prompt未被当作"代码资产"管理。 解决方案提出"Prompt即代码"理念，赋予Prompt五项代码待遇： 版本化：用内容哈希作为唯一身份标识，语义版本仅作标签 评审机制：结合人工diff与自动化校验（占位符检查/token预算/契约验证） CI集成：触发最小评测回归，]]></description><category></category></item><item><title><![CDATA[大模型工程化实战（三）：LLM 灰度发布 + 自动熔断，1% 流量试错、指标劣化自动回滚]]></title><link>https://blog.csdn.net/xiaobing259/article/details/163801977</link><guid>https://blog.csdn.net/xiaobing259/article/details/163801977</guid><author>xiaobing259</author><pubDate>Wed, 19 Aug 2026 08:00:00 +0800</pubDate><description><![CDATA[本文探讨了AI系统灰度发布中的关键问题与解决方案。通过一个真实事故案例（因优化Prompt导致回复过短而引发转人工率飙升），指出离线评测的局限性——它只能反映历史数据，无法捕捉线上动态变化。文章提出了一套完整的线上验证框架：影子验证（新旧版本并行比对）、分层放量（1%-100%分五档双门禁控制）和智能熔断（快慢双层的阈值判定）。重点解析了熔断阈值的统计原理（如违规3次法则、3σ校准）和状态机设计（CLOSED/OPEN/HALF_OPEN三态流转），强调监控必须从"被动看"升级为"主动盯"。核心结]]></description><category></category></item></channel></rss>