教程六月 15, 2026拆 DAMA 里的 LangGraph 生图工作流:从识别商品到 Critic 重试,这条链是怎么串起来的(内部有项目体验地址)点击体验上一篇先把DAMA这个项目的整体思路记了一遍,这一篇就不再聊大框架了,直接往里拆一条最关键的链:这套电商生图Agent,到底是怎么用LangGraph把一次任务跑起来的。我这次只盯一件事:从用户给一张商品图开始,这条链怎么一步步走到识别、理解、选策略、出图、CriticLangGraph智能体生图工作流源码拆解
复盘六月 3, 2026做 DAMA 这个电商生图智能体时,我先把商品理解、展示策略和质检闭环拆开了这篇记一下我最近在做的一个新项目,名字叫DAMA。它表面上看是个生图项目,但真往下做,很快就会碰到一串更具体的问题:商品怎么理解、卖点图和种草图怎么区分、参考图怎么保真、结果不好时到底该改prompt还是换策略、前端又怎么看到中间过程。我先把这段时间的思路和阶段性做法记下来,后面回头看,也能知道自己智能体生图LangGraph电商图工程化
教程二月 20, 2026详解 OpenClaw 的记忆实现:文件、检索、主动召回和 Memory Flush 是怎么接起来的这篇我想直接回答一个很具体的问题:OpenClaw里的“记忆”到底是怎么实现的。最开始我以为它就是一个向量库加检索。但对着源码看一圈以后,感觉不能这么概括。OpenClaw现在这套实现,至少要拆成四层看:工作区里的记忆文件怎么组织记忆怎么被索引和检索记忆怎么主动插进prompt上下文太长的时候,记忆OpenClaw记忆智能体源码拆解向量检索
教程二月 14, 2026拆 OpenClaw 的 Tool Call:从模型吐出调用到结果回写上一篇我已经把OpenClaw的大执行链路顺了一遍,这一篇不再铺开讲,只盯一个点:toolcall系统到底是怎么转起来的。我这次给自己的问题也很具体:模型把工具调用吐出来以后,谁先接住toolcall在真正执行前过了哪些关参数是在哪里校验和修的为什么OpenClaw的工具系统看起来不像“挂几个函数”OpenClaw工具调用Tool Call源码拆解智能体
教程二月 8, 2026对着 OpenClaw 源码拆一遍:一次 Agent 请求是怎么跑起来的这篇接上一篇OpenClaw的认知文往下写,不过这一篇不聊概念,直接看源码。我这次给自己定的目标很简单:先不管它所有外围能力,只顺着一次openclawagent--message"...",把主执行链路看通。下面这些记录,都是按我这次拉下来的仓库结构记的,重点放在三块:agentruntime在哪OpenClaw智能体源码拆解Agent工具调用
复盘一月 18, 2026OpenClaw 之后,我才开始认真理解智能体到底在解决什么问题这篇不想写成热点感很强的东西,更多还是记一个认知转折。前面几年我一直在做AI、生图、工作流、后端这些事,智能体这个词当然也不是没听过。但很长一段时间里,我对它的感觉始终偏悬空:概念很多,演示很多,真正落到工程里时到底值不值、边界在哪、和普通工作流有什么本质区别,我心里其实并不踏实。OpenClaw出智能体OpenClawAI工作流工程化
复盘五月 6, 2025自动对账、日志追踪和异常恢复,为什么这些东西最后最值钱这篇接在papain的支付状态机和异步回调后面写。如果说前一篇主要在讲“支付结果怎么被业务可靠消费”,那这一篇更像是在讲:系统真正跑起来之后,出了问题靠什么把它拉回来。到了这个阶段,我对自动对账、日志追踪和异常恢复的感受已经很明确了——这些东西前期最容易被当成辅助能力,后面往往会变成系统里最值钱的一.NET自动对账日志异常恢复papain
复盘四月 22, 2025支付状态机和异步回调,我是怎么把它做稳的这篇接papain的第一篇总起文往下写,主要记项目里最硬的一块:支付状态机和异步回调。前一篇写的是,为什么这个项目让我开始真正理解“稳定交付”。这篇就落到具体技术和业务动作上。因为papain这条链里,真正最不能乱的地方,就是支付结果怎么落、异步回调怎么接、状态怎么同步、重复触发怎么拦、失败以后怎么.NET支付状态机异步回调papain
复盘四月 12, 2025从 AI 平台到终端拍报机,我开始真正理解“稳定交付”这篇算是进入papain阶段后的第一篇总起复盘。前面在vchoo那一段,我花了很多时间在AI链路、任务调度、状态流转、异常降级这些问题上。到了papain,这些经验并没有失效,但项目重心已经明显变了。这里要处理的是一套会直接碰到支付、终端执行、状态同步、对账和长期运行的正式业务系统。从这个阶段开始,.NETpapain后端稳定性业务复盘
复盘三月 20, 2025状态一多,接口为什么就开始变复杂了这篇算是把前面那几篇任务调度、异常降级、日志权限的收拢篇把。很多时候接口变复杂,表面上看像是参数变多了、判断变多了、页面要求变多了。真把业务往后做一段时间,会发现很多复杂度其实都长在状态上。状态一开始看起来只是几个字段,后来会慢慢变成整个系统动作边界的承载点。到这个阶段,接口到底能不能继续收得住,很.NET状态流转接口设计后端业务复盘
.NET三月 12, 2025在这个项目里,我对 DDD 架构的阶段理解这篇偏工程文,主要记我在vchoo这类项目里,对DDD架构的一些阶段理解。前面几篇写了任务调度、异常降级、日志权限这些问题,再往回看,很多复杂度都不是某个单点技术单独带出来的。更多时候,是业务对象、状态流转、外部能力、数据存储一起压上来以后,代码开始越来越难收。也是到这个阶段,我才慢慢把DDD当成一.NETDDD架构后端工程化
.NET十月 18, 2024DTO、实体、返回模型到底该怎么分这篇不讲项目故事,直接记一个我在后端里反复撞到的问题:DTO、实体、返回模型到底该怎么分。刚开始写接口时,最省事的做法通常是一个类从头用到尾:接参数用它,落库用它,返回前端还用它。短期看很快,代码一多就开始拧巴。前端要一个字段,数据库是一套结构,服务层里又想补一点业务含义,最后全挤在一个类上,哪里都.NETDTO实体返回模型后端
复盘十月 9, 2024为什么做完这个项目以后,我会越来越在意日志、异常处理和权限这篇还是接在vchoo这条线后面写。前面几篇已经把故事生成、分镜拆分、生图任务调度、超时和降级这些主链路拆开了。那段时间我最大的变化,不只在“把AI能力接进业务”这件事上。项目越往后做,我越能感觉到,系统能不能长期跑下去,很多时候要看的反而是几件很基础、平时又很容易被嫌麻烦的东西:日志、异常处理和权.NET日志异常处理权限后端
复盘九月 26, 2024LLM / ComfyUI 接口异常、超时和降级是怎么处理的这篇继续接vchoo这条主线,专门记外部能力接进业务系统以后最容易把链路打断的几件事:接口异常、超时和降级。前面写了全链路,也拆了生图任务调度。真正把系统往线上放以后,很快就会碰到一个更现实的问题:链路里的每个外部能力都不一定稳定。故事生成会超时,分镜拆分可能返回结构不稳,ComfyUI也可能卡住、.NETLLMComfyUI异常处理降级
复盘九月 17, 2024AI 生图任务调度、取消、重试和进度查询这篇接着上一篇vchoo的全链路复盘往下拆,专门记生图这一层最容易把系统做乱的几件事:任务调度、取消、重试和进度查询。前面从故事到分镜那一段,更多是在把内容链接起来。到了生图这一步,系统开始真正面对耗时任务、批量执行、局部失败和用户等待体验。这里处理得顺不顺,直接决定前端看到的是“可用的产品”,还是.NETAI任务调度ComfyUI后端