- 博客(1110)
- 问答 (1)
- 收藏
- 关注
RSS订阅
原创 关于文章首发平台调整的声明
后续涉及技术总结、开发经验、问题记录、源码分析、学习笔记等内容，将优先发布在博客园。CSDN 平台可能会根据实际情况进行同步更新，但不再作为首发渠道。此次调整主要是出于个人内容管理、写作习惯以及长期沉淀的考虑。即日起，本人后续原创文章将不再于 CSDN 平台首发，文章首发平台正式调整至博客园。博客园将作为本人后续文章的主要发布平台，敬请关注。
2026-07-05 00:22:11
259
原创 Day 9：回答必须带引用来源，前端要能展开查看
文章摘要 Day 8 主要实现了AI回答的引用溯源功能，解决业务方无法验证回答准确性的问题。后端改造包括：为检索片段添加编号，要求模型在回答中使用[数字]标注引用来源，并将来源信息（文档名、片段位置、原文等）返回前端。前端需展示引用列表，支持点击查看完整片段。这一改进使业务方能够逐条核对AI回答与原始文档的一致性，增强了回答的可信度和可用性，特别是在退款政策等关键场景中。
2026-07-18 21:20:09
245
原创 Day 8：AI 要从公司资料里找答案
今天把 Day 7 建好的向量索引和 Day 5 留下的 mock 知识库工具之间的断层接上了。封装了 Chroma 的相似度搜索，从关键词匹配换成了语义检索，改动虽然集中在两个文件，但效果是让 Agent 第一次真正基于公司上传的资料来回答问题，而不是靠几条写死的 mock 数据假装在查知识库。前端也跟着落地了两个新组件，处理单条片段的分数展示和原文展开，把它们装在一起，再通过的动态组件映射接进现有的聊天流程，整个过程对现有工具调用骨架的改动控制在最小范围。
2026-07-18 21:06:19
364
原创 大模型调用脱敏接口时，如何保证查询实体的一致性
摘要： 大模型与业务系统结合时，若第三方接口对返回数据脱敏（如将"张三"替换为"李四"），会导致大模型因实体名称不一致而误判。问题本质在于脱敏破坏了实体身份的连续性。解决方案包括：1）在调用链路中使用稳定的业务ID（如学号）替代姓名，确保实体关联不受脱敏影响；2）更完善的假名化方案，即在输入阶段将真实姓名统一映射为匿名标识（如STUDENT_001），使大模型全程使用假名处理，避免暴露真实信息。两种方案均通过技术手段分离展示层与实体标识，确保数据隐私的同时维持语义一致性。普通姓名脱敏因缺乏稳定性不被推荐，而
2026-07-18 20:50:31
471
原创 第二周概述
技术上后端提供一个检索调试接口，支持设置 top_k 等参数，并同时支持向量检索、关键词检索和混合检索几种策略，还能对结果做 rerank，前端则新增一个独立的调试页面，包含查询输入框、检索参数设置面板、召回结果列表、分数展示以及最终进入模型的上下文预览，方便直接对比不同检索策略的效果差异。真实场景里资料的格式五花八门，可能是售后政策的 PDF、产品说明的 Markdown、接口文档的 Word，也可能是常见问题的表格或历史工单的 CSV，系统需要有一套统一的方式来接收和管理这些异构文档。
2026-07-12 14:53:05
179
原创 Day 7：文档太长，需要切片和索引，前端要能看到处理状态
今天把 Day 6 遗留的两个问题一起解决了，一是文档处理不再是一次性同步跑完、卡住请求的黑盒操作，而是拆成解析、切片、向量化三个阶段的后台流水线，每一步都会更新状态、写一条可追溯的日志，二是文档终于真正具备了被检索的基础，切好的片段经过 Embedding 转成向量、写进本地的 Chroma 索引，不再只是一段用来展示的摘要文字。前端也跟着补上了细粒度的状态标签、片段数量展示和处理日志入口，还加了一套简单的轮询，管理员不用守着页面手动刷新就能看到进度往前推进。
2026-07-12 14:52:06
309
原创 Day 6：业务方上传了一堆文档，系统要能管理
第一周结束时，Agent 已经能聊天、能给结构化回答、还能协同查订单、工单、用户三套业务系统，但客服团队试用了几天后，业务方提出了一个新方向，光靠 AI 的通用知识和这几个业务系统的实时数据还不够，很多客服日常要回答的问题其实都写在公司自己的资料里，比如售后政策规定退款期限是几天、产品说明书里某个功能怎么用、常见问题文档里已经有的标准答案，这些内容 AI 目前完全不知道。业务方计划把售后政策、产品说明、接口文档、常见问题、运维手册、历史工单这些格式各异的资料都丢给系统，让 AI 以后回答问题时能查这些资料再
2026-07-12 14:48:02
385
原创 Day 5：把聊天页面升级成业务 Agent 工作台
昨天把订单查询工具接上之后，客服团队试用了几天又提了新的诉求，用户找客服很少只问一件事，经常是先问订单发货状态，接着问自己是不是 VIP 能不能加急，最后又扯到之前提交的一个工单还没处理，这几件事分别对应订单、用户、工单三套后台系统，客服自己处理时也是来回切几个系统页面反复核对。业务方希望 AI 能把这几件事一次性串起来处理，而不是只会查订单这一件事，所以今天要给 Agent 再接入工单、用户、知识库三个工具，让它具备协同调用多个工具、综合多个来源信息给出结论的能力。工具一多，另一个问题也随之而来，客服光看
2026-07-12 14:44:03
327
原创 Day 4：AI 不能只聊天，还要能查订单
昨天把回答变成结构化卡片之后，客服团队的反馈很快又更进了一步，用户问“帮我查一下订单 202606050001 为什么还没发货”，AI 只能凭对话历史里的只言片语猜一个答案，猜不对客服还得自己去后台查一遍订单系统，这就完全没有省下人力。业务方要的不是一个更好看的猜测，而是 AI 真的去查一下订单系统再回答，所以今天要做的是给 Agent 接入第一个工具，让它在判断出用户在问订单状态时自动调用查询接口拿到真实数据，再基于这份数据组织回答。这一步还牵出一个绕不开的问题，工具调用往往要经过好几轮模型推理才能收敛，
2026-07-12 14:38:10
370
原创 从聊天记录到真正的记忆：为 AI Agent 设计一套分层记忆系统
主题和记忆解决的是“对话该怎么组织”，但还有另一类问题跟对话轮数无关，而是单次输入本身就超出了模型能处理的长度，比如聊天轮数堆积到几百轮，或者用户一次性甩过来几十万 Token 的日志、合同、代码仓库。这一节要解决的是这类超长内容怎么在不丢信息的前提下塞进有限的上下文里。如果 Chunk Summary 数量本身也多到超过上下文限制，答案很简单，继续摘要，也就是让摘要本身也可以递归。这是典型的 Map-Reduce 思路，先分别总结各个分组，再总结这些总结，直到最终结果能放入模型上下文为止。
2026-07-05 17:24:56
257
原创 Day 3：业务方要求 AI 按固定格式返回，前端要能展示卡片
昨天把聊天主链路跑通之后，客服团队试用了一下，很快提了一个很实际的问题，AI 回复的一段自由文本，客服看完还是得自己判断这到底是订单问题还是账号问题，这次回答靠不靠谱，要不要转给人工处理。业务方的诉求很明确，AI 的输出不能只是聊天记录里的一段话，而要能直接支撑客服的决策，所以今天要做的是把接口的返回值从纯文本升级成结构化数据，字段包括问题类型、回答内容、置信度、是否需要人工介入和建议操作，前端也要跟着新增组件，把这些字段渲染成一张信息完整的回答卡片。后端这一块的核心变化是让模型的输出从一段文本变成一个符合
2026-07-05 00:37:35
253
原创 Day 2：先做一个能聊天的页面
今天把"能对话"这件事从架构图变成了用户能亲手体验的功能。后端提供了一个无状态的接口，靠前端每次带上完整的消息历史来实现多轮对话的上下文，这是今天刻意选择的最简单方案,后面消息量变大之后大概率要换成服务端维护会话、只截取最近若干轮上下文发给模型这类更节省成本的做法,但作为第一版把链路跑通,今天这种做法足够。前端把聊天页面拆成了ChatViewChatInput三层，请求状态和错误信息统一收在ChatView。
2026-07-05 00:35:54
382
原创 Day 1：需求来了：公司想做一个 AI 知识工单助手
这一天没有写一行业务逻辑，做的都是打地基的事，但恰恰是这些地基决定了后面二十天能不能顺利往下走。需求拆清楚之后，才知道对话交互、知识问答、业务查询、风险控制、权限管理、效果验证这六块能力分别对应第几周要做的事，不至于走到中途才发现漏了一块没考虑。系统架构画出来之后，前端管理后台、后端各服务模块、底层基础设施之间的调用关系有了图可以对照，后面每加一个功能都知道该放在架构的哪一层。前后端项目骨架搭起来之后，代码从第一天起就有地方安放，不会出现功能越堆越多、目录越来越乱的情况。页面路由规划出来之后，/chat。
2026-07-05 00:27:11
274
原创 第一周概述
工作从需求拆解和系统架构设计开始，明确前后端各自的职责边界和交互方式，再据此规划出完整的页面路由体系，覆盖对话、知识库、工单、审核、执行记录、评估和配置等核心场景。这一天是本周的收官，目标是把前四天积累的能力整合成一个真正可用的业务 Agent 工作台，而不只是一个功能堆砌的聊天页面。这一周虽然只有五天，但节奏并不轻松，从零搭建项目骨架开始，逐步跑通聊天主链路、让回答具备结构化的业务价值、赋予 AI 调用外部系统的能力，最终落地成一个具备基础工具调用能力的业务 Agent 工作台。
2026-07-05 00:14:18
277
1
原创 Day 3：Kotlin基础（二）
昨天已经把变量、类型、函数和字符串模板过了一遍，它们解决的是“数据怎么表示、逻辑怎么封装、结果怎么输出”的问题。但程序真正开始变得有用，往往是从控制流程开始的。用户输入不同，程序要给出不同反馈，数据不止一条，程序要重复处理，某个条件还没满足，程序就要继续等待或重试。这些都不是单靠变量声明能完成的。今天要讲的ifwhenfor和while，就是 Kotlin 里最基础也最常用的控制流工具。
2026-06-28 21:12:00
386
原创 Day 2：Kotlin基础（一）
昨天搭好了 Android Studio，今天正式进入 Kotlin 语言基础。写 Android 应用本质上就是用 Kotlin 描述界面长什么样、数据怎么流转、用户操作怎么响应，这些最终都会落到变量、类型、函数和字符串拼接这四个基本功上。今天把它们逐个搞清，明天就能直接用 Kotlin 写出有逻辑的程序代码了。
2026-06-28 21:11:23
326
原创 Day 1：环境搭建
接着进入 Setup Wizard，选择安装类型为 Custom（自定义安装）进入自定义安装界面，在这个界面中我们只修改Android SDK的下载路径，默认的下载路径在 C 盘用户文件夹下，我们需要将这个路径修改到其他盘，最后确认 SDK 组件列表，点击 Finish。Android Studio 是 Google 官方推出的 Android 集成开发环境（IDE），基于 IntelliJ IDEA 构建，整合了代码编辑、编译构建、调试、性能分析和模拟器，是 Android 开发的标准工具。
2026-06-28 21:10:30
280
原创 17【.NET10 实战--孢子记账--产品智能化】--报表智能解读
这次改造已经搭好了“数据到理解”的主路径。前端可以继续用旧接口画图，同时调用新接口展示智能总结、风险提醒和行动建议。预算部分的数据基础比较扎实，因为它能直接拿到预算总额、剩余金额、使用率和趋势。普通报表部分已经能做月度收支和分类占比解读，但收入/支出的判断目前依赖名称关键词，这是后续最值得补强的数据契约点。整体上，这次新增内容不是简单加了两个接口，而是建立了一个可扩展的解读框架。
2026-06-28 15:11:40
714
原创 Week 4 --Day 5：总结输出与展望
在四个周的学习中，我们已经反复触及 LangSmith 的追踪功能，但 LangSmith 的能力远不止于此，它提供的评估（Evaluation）功能可以让你用数据集系统性地测试 Agent 在不同输入下的表现，实验（Experiments）功能支持 A/B 对比不同模型或提示词的效果，而 LangSmith Engine 则更进一步，能够自动监控线上 trace、检测异常模式、甚至提出修复建议。标签的入门级任务，从修复文档拼写错误到补充某个集成模块的测试用例，都是熟悉开源协作流程的练手机会。
2026-06-27 23:28:15
208
原创 Week 4 --Day 4：调试、优化与前沿探索
一个 Agent 应用从原型走向生产的过程中，调试能力和运行效率是两个最容易被低估却最终决定成败的因素。在开发阶段，单步执行和 print 语句或许能帮助我们定位问题，但当一个 Agent 同时服务于数百个用户、每一步推理都涉及多次模型调用和工具执行时，传统的调试手段就会迅速失效，你无法在服务器上打断点，也不可能逐行阅读成千上万条日志。
2026-06-27 23:27:14
310
原创 Week 4 --Day 3：项目三 — 数据分析智能体
一个对数据库结构一无所知的模型不可能凭空写出能正确执行的查询语句，因此在 SQL 生成之前，系统必须先执行一个 Schema 探查步骤，自动列出数据库中所有可用的表名，然后根据问题的语义选择相关的表并获取其详细的列定义。这段解析代码使用了简单的字符串分割和类型推断，虽然在实际项目中更好的做法是在节点间传递结构化的 JSON 数据而非文本，但文本格式的优点是 LLM 可以直接阅读和理解中间结果，便于调试时通过 LangSmith 或终端日志追踪数据流转的每一步。字段筛选出不同等级的用户，再与订单表联查求和。
2026-06-27 23:25:53
319
原创 16【.NET10 实战--孢子记账--产品智能化】--通用OCR
本文针对孢子记账项目中的OCR识别功能进行智能化改造，提出了一种通用化设计方案。原实现存在OCR服务商强耦合问题，业务代码直接依赖百度SDK，导致切换服务商或模型时需修改代码并重新发布。解决方案包括： 抽象IOcrProvider接口，统一OCR调用边界，业务层仅依赖接口而不感知具体实现。 设计通用结果模型OcrRecognitionResult，标准化不同OCR服务的返回数据结构。 实现OpenAI兼容的OpenAiCompatibleOcrProvider，支持通过Nacos配置热切换模型、提示词等参数
2026-06-27 23:20:13
458
原创 Week 4 --Day 2：项目二 — 代码审查助手
工具是 Agent 感知世界和改变世界的触角。在 LangChain 中定义一个工具最直接的方式是使用@tool装饰器，它会自动将函数的签名和 docstring 转化为模型可以理解的工具描述，包括工具名称、用途说明和参数类型。
2026-06-20 22:28:17
361
原创 Week 4 --Day 1：项目一 — 智能客服系统
工具是 Agent 与外部世界交互的桥梁。在智能客服系统中，我们至少需要三个业务工具：订单查询工具让 Agent 能够根据订单号或用户信息查找物流状态与订单详情、退款审核工具负责检查退款条件并执行或拒绝退款操作、转人工工具在 Agent 判断自己无法妥善处理时将对话连同上下文一起转交给人工坐席队列。在 LangChain 中定义工具最简单的方式是使用@tool装饰器。
2026-06-20 22:27:12
311
原创 15【.NET10 实战--孢子记账--产品智能化】--财务健康智能建议
这种"采集—推理—降级"的三层架构，将代码与模型的边界划分得清晰而优雅——代码不再试图模拟人类的判断力，而是专注于自己擅长的事务性工作；模型不再被当作一个黑盒 API 随意调用，而是被赋予了明确的角色和严谨的输入输出契约。当模型可用时，用户获得的是有温度、有个性、能真正共情的建议；当模型不可用时，规则引擎确保用户至少不会面对空白或报错。这种"AI 增强而非替代"的设计哲学，也正是孢子记账在整个智能化改造过程中始终坚持的原则。
2026-06-20 22:25:14
348
原创 Week 3 --Day 4：生产级部署
前三天的学习让我们掌握了 LangGraph 的核心能力，从单个 Agent 的 ReAct 循环到复杂的多智能体协作系统，这些知识已经足以构建功能完备的 LLM 应用。然而一个在本地下运行正常的 Agent 距离真正的生产级服务还有一段关键的距离。这段距离不体现在功能性上，而体现在系统面对真实世界不可预测性时的韧性。
2026-06-14 21:46:56
257
原创 Week 3 --Day 3：多智能体协作系统
在前两天的学习中，我们使用 LangGraph 构建了从简单 ReAct 循环到复杂多节点流水线的 Agent 工作流，这些图在单个 Agent 的范畴内已经相当强大。然而当你把越来越多工具塞进同一个 Agent，或者让同一个 Agent 同时处理代码审查、数据分析、客户沟通这些性质迥异的任务时，单 Agent 架构的瓶颈会逐渐暴露。最直观的问题是上下文膨胀，每次工具调用，尤其是网页搜索、数据库查询、文件读取这类会返回大量内容的操作，都会在消息历史中堆积数据，很快逼近模型的上下文窗口上限。更深层的问题是工具
2026-06-11 00:27:52
415
原创 Week 3 --Day 2：LangGraph 进阶
本文介绍了如何使用LangGraph构建复杂工作流，重点探讨了三个进阶特性：多节点顺序流水线、条件路由和状态管理。通过内容生产流水线示例，展示了如何将研究、分析、写作、审核等节点串联成工作流，并实现审核不通过自动返工的条件路由机制。文章还解释了LangGraph的状态管理机制，包括继承MessagesState自动获得消息追加能力，以及混合reducer的设计模式。这些技术为构建可定制、带决策能力的AI工作流提供了基础支持。
2026-06-11 00:27:13
280
原创 Week 3 -- Day 1：LangGraph 入门
本文介绍了LangGraph的设计理念和核心概念。LangGraph是一个低层Agent编排框架，适用于构建多步骤、有条件分支的复杂工作流，其灵感来自Pregel系统和Apache Beam，通过有向图模型实现对Agent执行流程的精确控制。核心概念包括StateGraph（定义状态模式）、Node（执行具体逻辑的函数）、Edge（节点间的路由关系）以及特殊虚拟节点START/END。文章展示了如何构建一个基于ReAct循环的Agent工作流，包括工具定义、模型绑定、状态设计和图构建。LangGraph强调
2026-06-09 21:46:07
514
原创 14【.NET10 实战--孢子记账--产品智能化】--智能生成预算
经过前面三篇文章的铺垫，我们先后完成了硅基流动平台的接入配置、大模型接入方式的技术选型，以及 LLM 调用层的统一封装，孢子记账的智能化基础设施已经基本就绪。从现在开始，我们的目光将从"怎么接入 AI"转向"用 AI 做什么"，将大模型能力真正嵌入到具体的业务场景中，让用户能够实实在在地感受到智能化带来的体验提升。而我们将要攻克的第一个智能化功能，就是。
2026-06-07 23:44:48
280
原创 第2周学习笔记
工具是 Agent 系统中最基础的单元。@tool@tool"""搜索客户数据库中的匹配记录。"""return f"在数据库中找到了@tool def search_database(query : str , limit : int = 10) - > str : """搜索客户数据库中的匹配记录。""" return f"在数据库中找到了 {limit } 条与 ' {query } ' 相关的结果。
2026-06-06 16:16:31
272
原创 Week 2 -- Day 5：Agent 系统（下）— Function Calling 与 create_agent
在 Day 4 的学习中，我们理解了 Agent 系统最核心的概念，工具（Tool）和 ReAct 推理循环。今天我们要进一步深入两个在实际开发中至关重要的主题，底层的 Function Calling 机制，以及 LangChain v1 中最强大的 Agent 构建入口和它背后的中间件（Middleware）系统。如果把 Day 4 的内容比作理解了汽车发动机的工作原理，那么今天我们要学习的是整车的电控系统和底盘架构，它们让 Agent 从"能跑"进化为"稳定、可控、可扩展"。
2026-06-06 16:15:38
407
原创 Week 2 -- Day 4：Agent 系统（上）— 工具与 ReAct
文章摘要： 本文介绍了如何通过LangChain v1构建具备行动能力的Agent系统。主要内容包括：1) 工具定义，使用@tool装饰器将Python函数转化为模型可调用的工具，强调参数类型和描述文档的重要性；2) ReAct（推理+行动）模式，详细解释了模型如何在思考与行动间交替进行以解决复杂问题；3) Agent构建的演进，从旧版create_react_agent到新版更灵活的create_agent中间件系统。文章通过代码示例展示了工具创建、参数定义和Agent构建过程，突出了新版API的可组合性
2026-06-05 23:44:10
308
原创 Week 2 -- Day 3：RAG 系统构建（下）
今天我们要做的，就是把这一堆零散的文本 chunk 转化为机器能够理解的数值向量，存入向量数据库，并在用户提问时从中检索出最相关的内容，最终拼接到大模型的提示词里，形成一个完整的检索增强生成（RAG）问答系统。在这个空间中，语义相近的文本会被映射到几何上彼此靠近的点，而语义无关的文本则相距甚远。举例来说，"猫是一种宠物"和"狗是人类的好朋友"这两句话虽然字面完全不同，但它们都涉及"家庭宠物"这一语义范畴，因此在向量空间中大概率会聚在一起，而"今天的股票大涨"则可能落在完全不同的区域。值得一提的是来源追踪。
2026-06-04 23:42:37
412
原创 Week 2 -- Day 2：RAG 系统构建（上）
本文介绍了 RAG（检索增强生成）技术及其在LangChain中的实现流程。RAG通过动态检索外部知识解决大模型数据局限问题，广泛应用于企业知识库等场景。文章重点讲解了RAG前两步：文档加载和文本分割，包括LangChain提供的丰富文档加载器（如PDF、Markdown等）和递归字符分割器（RecursiveCharacterTextSplitter）的使用方法。通过调整chunk_size、overlap等参数可以优化文本分割效果，平衡检索精确性与语义完整性。最后建议实践不同文档格式的加载和分割参数对比
2026-06-03 00:56:29
231
原创 Week 2 -- Day 1：Model IO 与模型抽象
如果说 LangChain 是一套乐高积木，那么 Model I/O 就是那几块最核心的底板砖，无论你搭建的是简单的问答链还是复杂的多智能体系统，一切逻辑的起点都是"把数据交给模型，把模型的结果拿回来"。本周我们正式进入 LangChain 核心组件的深度学习，第一天的主题就是把 Model I/O 这一层吃透，理解 LangChain 如何用统一抽象屏蔽不同模型厂商的差异，掌握模型参数的调优哲学，以及学会根据任务特征动态选择合适的模型。
2026-06-02 00:57:01
304
原创 13.【.NET10 实战--孢子记账--产品智能化】--封装LLM
本文介绍了在孢子记账项目中封装LLM调用层的必要性及设计思路。通过对比直接调用OpenAI SDK的弊端，提出了构建统一封装层的方案，旨在解决微服务架构中配置分散、代码重复等问题。文章详细阐述了封装层的设计目标与核心功能，包括面向业务的接口设计、结构化配置模型以及重试机制。重点介绍了IOpenAIService接口的简洁设计原则和OpenAIOptions配置类，强调了重试与指数退避策略对系统稳定性的重要性。该封装层将作为微服务架构中的基础组件，为后续更多AI能力的集成提供统一接入点。
2026-05-31 23:22:44
296
空空如也
下载了最新的微信开发者工具，创建小程序报错，有谁遇到过？该怎么解决
2021-10-23
TA创建的收藏夹 TA关注的收藏夹
TA关注的人