- 博客(89)
- 收藏
- 关注
RSS订阅原创 别再把 Agent 和 Chatbot 混为一谈：AI Agent 核心概念一次讲清
用户输入│▼Guardrail（输入安全检查）│▼Context Assembly（组装上下文）│▼Orchestration（Agent 循环）│├── Tool Calling（调用工具获取信息）├── RAG（检索知识库）├── Memory（读写记忆）├── Handoff（委派子任务）└── Structured Output（结构化决策）│▼Guardrail（输出安全检查）│▼Trace（记录全过程）│▼返回给用户概念解决的问题。
2026-05-20 18:44:02
357
原创 MCP 和 Skills：Claude Code 两种扩展机制的本质区别
把 MCP 想象成给机器人装新的机械臂，把 Skills 想象成给机器人写操作手册。机械臂让它能做新事情，操作手册让它把已有事情做好。两者不冲突，也不互相替代。大部分项目两者都会用到：MCP 连接你需要的外部系统，Skills 规范你需要的流程标准。
2026-05-19 12:41:01
421
原创 Claude Code 不只是终端里的 ChatGPT：一个真正能干活的 AI 编程 Agent
claude --agents '{"reviewer": {"description": "代码审查员", "prompt": "你是一个严格的代码审查员"}}'定义自定义 Agent 角色，在会话中切换使用。Claude Code 是目前我用过的最接近"AI 程序员"的工具。它不是完美的——有时候会犯蠢，有时候会过度设计，有时候需要你纠正方向。但它确实在干活，而且干得比大多数人预期的要好。如果你还没试过，花 10 分钟装上跑一个真实任务。比看 10 篇评测文章更有说服力。
2026-05-17 20:16:59
885
原创 Interview Agent：从面试平台到 Agent 工程实战的进化之路
│ │ │：Agent 系统的瓶颈是 I/O 等待——等 LLM 响应、等向量搜索、等文件解析。Virtual Threads 让每个请求可以阻塞等待而不占用平台线程，对于 SSE 长连接和并发 LLM 调用的场景非常合适。：不是直接调 OpenAI SDK，而是用 Spring AI 做抽象层。好处是 LLM Provider 可以动态切换——项目刚实现了多 Provider 动态注册，可以在 DashScope、OpenAI、或其他兼容接口之间无缝切换，不用改业务代码。
2026-05-16 22:57:37
395
原创 【无标题】
前两层都是"预防"，但预防不可能 100%——万一 LLM 还是听了攻击者的话呢？检查 LLM 的响应，一旦发现它已经"叛变"，就把响应拦截掉。具体来说，Spring AI 2.0 的会检查 LLM 响应里是否包含"顺从短语"——比如“我已经忽略”这类明显表示模型放弃了原有角色的话。匹配到就直接拦截，返回一句固定话术（“抱歉，我只能协助面试相关的任务。
2026-05-15 22:01:04
433
原创 一次 LLM 调用评估不完 15 道题：分批评估与两轮汇总的面试评分架构
本地聚合只是机械合并。两批的strengths可能重复（两批都提到"基础知识扎实"），拼在一起不连贯。需要一次 LLM 调用来做"总结的总结"。) {// 1. 把 15 道题的评估结果压缩成两个摘要// 2. 构造总结 prompt，把压缩摘要 + 批次兜底反馈一起传给 LLM// 3. LLM 生成总结// 4. 本地清洗：空字段回退到批次聚合结果= null?分类摘要- Java基础: 平均分 78, 题数 4- Spring: 平均分 65, 题数 3。
2026-05-12 20:49:11
627
原创 Query Rewrite 不是越智能越好：RAG 检索的精确词保护与动态召回
Query Rewrite 是 RAG 的好工具，但不是万能的。它会把"Redis"改成"缓存数据库"，把"JVM GC"改成"Java 垃圾回收"——语义上没错，但精确匹配全丢了。解决方案不是不用 rewrite，而是给它加护栏：提取精确词作为保护对象，跳过单术语改写，用多候选队列兜底，用精确词校验过滤弱召回。整套逻辑不增加 LLM 调用，全是本地规则。如果你在做 RAG，建议从一开始就建精确词保护机制。等上线后发现模型在"合理地胡说"再补，用户已经受过伤了。
2026-05-12 12:24:45
501
原创 限流不是加个计数器就行：用 Lua 脚本实现多维度原子限流
限流看起来简单——加个计数器，超了就拒绝。但在多维度、分布式、需要原子性的场景下，"简单"的方案会暴露出各种竞态和一致性问题。Lua 脚本把检查和扣减放在 Redis 服务端一次性完成，AOP 把限流逻辑从业务代码里抽离出来，注解把配置变成了声明。三层分离，各解决一个问题。如果你的项目已经有 Redis，需要给几个关键接口加上限流，不需要引入 Sentinel 或 Resilience4j 这样的重量级框架——一个 Lua 脚本 + 一个切面就够了。本文代码来自 Interview Agent 项目。
2026-05-11 23:16:12
430
原创 LLM 的 JSON 不靠谱：结构化输出的重试与修复实战
LLM 的结构化输出不可靠，这是当前所有 LLM 应用都要面对的现实。三层防御（直接解析 → JSON 修复 → LLM 重试）是一个务实的工程方案：本地修复处理常见的格式问题，错误注入让重试有针对性，调用方根据业务场景决定失败策略。不需要追求 100% 的结构化输出成功率——那需要完美的 prompt 和完美的模型，两者都不存在。把成功率从 90% 提升到 99.5%，剩下的 0.5% 交给降级和手动重试，这已经是生产可用的水平了。本文代码来自 Interview Agent 项目。
2026-05-11 17:10:16
415
原创 异步任务不用 Kafka 也行：用 Redis Stream 搭一套轻量级 Producer/Consumer 框架
KafkaRabbitMQ部署复杂度高（ZooKeeper/KRaft）中低（已有 Redis）消费者组支持有有有消息持久化磁盘磁盘内存 + AOF延迟毫秒级毫秒级毫秒级运维成本高中低（复用现有 Redis）项目已经有 Redis（用于缓存和分布式锁），不需要额外引入消息中间件。Redis Stream 的消费者组（Consumer Group）功能够用——支持多消费者、ACK 机制、pending entry list。对于一个单体应用的异步任务队列，它刚好够。
2026-05-11 11:32:20
541
原创 Agent 的记忆不是存数据库就行：上下文预算与轻量记忆的设计实战
Agent 的上下文管理不是"把所有信息塞给 LLM"那么简单。有限的预算迫使你做出取舍：什么信息对当前决策最重要？什么信息可以安全地省略或截断？轻量记忆和预算装配是 Interview Agent 项目对这个问题的回答——只存信号，不存载荷；按优先级裁剪，不随机丢弃；共享装配结果，不各自为政。如果你也在做 Agent 工程，建议从一开始就设计好上下文管理策略。等到 memory 膨胀到塞不进 prompt 再重构，成本会高得多。本文代码来自 Interview Agent 项目。
2026-05-10 20:23:54
418
原创 Agent 不是接上 LLM 就完了：三层 Guardrail 与审批恢复机制的设计实战
Agent 工程不只是"接上 LLM + 工具调用"。当 Agent 面向真实用户、处理真实数据时，安全性和可靠性是和功能同等重要的工程问题。三层 Guardrail 和审批恢复机制是 Interview Agent 项目对这个问题的回答——它不完美（正则检测有局限、BLOCK_REPLAY 策略偏保守），但它是根据实际踩坑经验迭代出来的，比从零设计一个"完美"方案更务实。如果你也在做 Agent 工程，建议从第一天就考虑 Guardrail 和审批机制。等到线上出了问题再补，成本会高得多。
2026-05-10 15:35:26
759
原创 RAG 不是接上就完了：从 mock 到真实评测的实战记录
Mock harness 不能省——它验证的是编排逻辑（query rewrite、参数选择、拒答路径），改了 RAG 代码后必须跑。但它衡量不了真实效果。向量检索预设文档真实 pgvectorLLM 生成固定逻辑真实 qwen-plus用途回归测试效果验证运行条件无外部依赖需要基础设施。
2026-05-10 00:46:48
386
原创 从上传到可问答：Interview Agent 的知识库 RAG 链路
原始文件不要塞进业务数据库，放进 S3 兼容对象存储更合适。向量化是耗时且不稳定的任务，应该通过 Redis Stream 异步处理并落状态。RAG 质量不只取决于大模型，检索参数、query rewrite、命中校验同样关键。如果你正在做 Java RAG 项目，可以先不要急着优化 prompt。先问自己三个问题：文件能不能重试处理？向量化失败前端能不能看见？检索不到时系统会不会胡答？这三个问题回答清楚，RAG 才真正从 Demo 走向工程。
2026-05-07 18:00:41
263
原创 布隆过滤器 vs 布谷鸟过滤器：面试和实战到底怎么选？
说实话，之前我一直觉得布隆过滤器就够了，不就查个存在性吗。但当业务里真的需要"用户取消关注后要从集合里删掉"这种需求的时候，布谷鸟过滤器就成了唯一选择。布隆过滤器解决的是"有没有"，布谷鸟过滤器解决的是"有没有且能不能删"。下次面试被问到这两个，别再一脸懵了。
2026-05-06 13:59:27
211
原创 我是怎么把一个普通 AI 聊天项目改造成工程化 Agent Runtime 的
这个项目做到现在，我觉得最大的收获不是某个具体技术，而是对"Agent 工程化"有了真实感受。大模型调 API 很容易，但“让 Agent 行为可解释、可约束、可调试、可演进”，才是真正难的地方。Turn、Trace、Memory、Guardrail、Approval——每一个模块单独看都不复杂，但它们组合在一起，才让 Agent 从一个"聊天页"变成了一个有执行状态、有安全边界、可以持续迭代的系统。如果你也在做 Java 后端方向，想找一个把 Spring AI 用深的实践项目，这个方向真的值得搞。
2026-05-05 23:35:56
256
原创 我为什么给 Agent 上下文组装预留后续必需片段预算
最近看里的 Agent 上下文组装逻辑时，我注意到一个很容易被忽略、但实际上很影响稳定性的细节：上下文预算不是“按优先级从前往后塞满”就完了，而是要主动给后面的必需片段留位置。这件事听起来有点细，但我觉得它比“多截断一点文本”重要得多。因为 Agent 的上下文不是普通的字符串拼接，它背后是一次有顺序、有层次的决策输入。如果前面的高优先级内容把预算吃光，后面本该保底出现的信息直接消失，模型拿到的就不是“精简版上下文”，而是“结构被破坏的上下文”。
2026-04-26 13:37:23
743
原创 为什么工作台列表要避免 N+1 查询
最近在看的 Agent 工作台读模型时，我又被一个老问题提醒了一次：很多人平时知道 N+1 查询是坏味道，但一到“列表页顺手补一点关联信息”这种场景，还是很容易写回去。结果不是代码跑不通，而是数据量一上来，接口耗时会突然变得很难看。这个问题在后台管理页、工作台、运营列表里尤其常见。因为这类页面天然就不是“只查一张表”，而是先拿主列表，再顺手补用户、消息、审批、日志、状态摘要。开发时每一步都很顺手，但如果这些补充信息是按行单独查，最后就会变成经典的 N+1。
2026-04-25 23:49:37
287
原创 为什么远程调用别包进 Spring 事务里
这两天看不是“整段流程保护罩”，它更适合包住短而确定的本地状态变更，不适合顺手把远程模型调用、工具调用这类慢操作一起包进去。很多人第一次写这类流程时，很容易觉得“这一整轮要么全成功，要么全失败”，于是想把chat()整体放进一个事务里。直觉上很完整，实际上风险很高。因为数据库事务一旦拉长，连接、锁、行版本和回滚成本都会一起拉长；而远程调用偏偏最不稳定，慢的时候慢，失败的时候还不一定能按你的预期回滚。这里的处理我觉得很对路。
2026-04-24 22:48:56
404
原创 心跳超时后，我为什么不在 Netty 里直接群发离线通知
前两天回头整理的连接链路时，我又确认了一次：离线这件事，最好别在一个 Netty handler 里“顺手做完”。很多聊天系统一开始都会这么写，连接断了，服务端立刻把用户从本机连接表删掉，然后直接给房间里其他人群发一个“某某已离线”。单机 demo 这么做当然能跑，但只要你开始有多台 IM 节点，问题就会很快冒出来。里其实已经给了一个很明确的分层信号：心跳超时只负责发现“这个连接该断了”。它通过判断连接长时间无活动，然后给当前连接写一个离线消息，最后把 channel 关掉。
2026-04-24 12:03:00
230
原创 我为什么在 WebSocket 上坚持用二进制帧 + Protobuf，而不是直接传 JSON
前段时间我在翻的消息链路时，又一次确认了一件事：做实时聊天这类高频交互场景，协议层真的不该图省事。很多项目一上来就选 WebSocket + JSON，因为调试方便、前后端都熟。但这个项目没有这么做，而是在和里，明确用了这套格式。我现在反而越来越认同这种“看起来麻烦一点”的设计，因为它把消息边界、消息类型和业务负载拆得很干净，后面的 Netty 分发链路也因此简单很多。
2026-04-24 11:49:00
197
原创 限流为什么要把同一个方法的 Redis Key 放进同一个 Cluster Slot
里还有个小信号值得注意：它会先在里把 Lua 脚本scriptLoad到 Redis，然后运行期再走evalSha。这说明这套实现不是只想“能跑”，而是希望把脚本执行路径也收紧到生产可用状态。所以我现在看这段代码，最有意思的不是“又写了一个限流切面”，而是它把面试题里常被一句带过的 Cluster 约束，真正落实到了 Key 设计上。很多时候，工程质量就在这种小地方分高下。🙂。
2026-04-23 22:47:37
479
原创 我为什么在审批态读取 Memory 失败时，宁可退回初始快照也不直接把整个请求打崩
如果答案是“没有”，再果断失败。在这个案例里，审批记录、turn、trace 仍然在，所以回退到初始快照是合理的。但审批态的很多请求，其实只是“查看当前审批状态”或者“在已经批准后恢复结果”。但到了审批态，如果仍然直接把异常往上抛，最终效果会很差: 用户已经点过批准，只是想刷新一下结果，却因为一份历史 memory 损坏而拿到整页报错。做 Agent 系统时，大家很容易把注意力放在「模型决策」「工具调用」「审批机制」这些显眼环节上，但线上真正容易把用户体验打碎的，往往是一个看起来不起眼的小点: 状态恢复。
2026-04-23 22:47:07
668
原创 [特殊字符] LeetCode 做题笔记（二）：678. 有效的括号字符串
low：当前最少可能的未匹配左括号数（尽量把当用）high：当前最多可能的未匹配左括号数（尽量把当用）✅贪心法精髓用区间表示所有可能状态，避免指数级枚举是保证前缀合法的关键❌常见错误忘记low不能为负（前缀中右括号不能超过左括号）最终判断写成high == 0（应该是low == 0，只要有一种可能完全匹配即可）当空字符串的情况被忽略（体现在low-1和high+1的区间扩展）💡举一反三20. 有效的括号32. 最长有效括号贪心区间思想可迁移到其他"不确定性选择"问题。
2026-03-16 20:59:36
536
原创 [特殊字符] LeetCode 做题笔记（一）：1878. 矩阵中最大的三个菱形和
✅收获几何枚举题的坐标变换技巧Java中TreeSet移除最小值，迭代器默认升序"边界和"与"区域和"的区别❌易错点菱形顶点重复计算（每条边累加时注意端点）半径枚举的边界条件（while而非for更易控制）结果去重 + 降序输出的细节（TreeSet转数组时注意顺序）
2026-03-16 20:58:40
287
原创 MySQL锁机制：从懵逼到入门，我花了三年
MySQL 的锁机制，说复杂也复杂，说简单也简单。核心就几点：行锁是锁在索引上的—— 没索引 = 表锁RR 级别有间隙锁，RC 级别没有—— 这是性能差异的关键临键锁 = 记录锁 + 间隙锁—— RR 级别的默认策略MVCC 负责快照读，锁负责当前读—— 两者配合实现隔离唯一索引等值查询会优化—— 临键锁退化成记录锁锁是用来保护数据的，不是用来折磨开发者的。理解它，才能用好它。希望这篇文章能帮你少走点弯路。如果还有疑问，欢迎留言讨论。毕竟，我也是从懵逼过来的。
2026-03-15 20:46:10
401
原创 关于 MySQL 的锁，你真的分清楚了吗？
MyISAM只有表锁，InnoDB支持行锁。InnoDB 行锁依赖于索引，无索引则锁全表。RR 隔离级别下，非唯一索引的查询会加(包含间隙)，容易导致性能问题和死锁。RC 隔离级别下，只加，并发更好，是互联网高并发场景的推荐选择。排查锁问题主要靠和表。理解这些机制，相信你不仅是一个八股小能手，更是一位数据库Infra 大神。
2026-03-15 20:12:52
379
原创 CLAUDE.md For AQ-Chat
Four AI assistants triggered by @mention in messages: 小Q (QA), 小T (text-to-image), 小V (text-to-voice), 小M (multi-model). Implemented as a Chain of Responsibility in。
2026-03-15 18:55:53
521
原创 如何在面试中优雅地把自己“卖”个好价钱？
你在技术面试中，用过最有效的“推销话术”是什么？你觉得什么样的项目经历最能打动面试官？欢迎在评论区分享你的实战心得！
2026-03-12 22:07:30
600
原创 互联网界“小龙虾”：OpenClaw，AI 时代的“数字劳工”还是“安全黑洞”？
OpenClaw 让我们看到了未来的曙光————电脑不再是需要我们不断敲击的工具，而是一个拥有灵魂的协作伙伴。但这只“小龙虾”现在还处于猛兽阶段，想养它，你得先拥有足够的驯兽技巧。
2026-03-11 21:45:55
395
原创 突破实时瓶颈：从零构建高性能 WebSocket 实时通讯架构
为了极致性能，我没有直接在 WebSocket 中传输冗长的 JSON，而是设计了一套二进制私有化协议（基于 Protobuf 序列化）。好处： 减少了报文体积（节省带宽），且序列化与反序列化速度远超 JSON，有效降低了 CPU 的压力，为支撑单机 10万+ 并发连接奠定了基础。WebSocket 不是一个简单的“聊天室工具”，它是构建现代实时 Web 应用的骨架。
2026-03-11 14:00:23
977
原创 从“写代码”到“编排智能”：AI 浪潮下后端开发的范式转移
AI 的兴起，正在把后端开发者从“代码实现者”推向“系统架构师”。如何将 AI 封装为一种可控的、稳定的微服务组件，并构建出能够承载智能业务的健壮骨架。未来的后端开发，比拼的不再是代码量的堆砌，而是对复杂系统的洞察力以及将不稳定技术落地为稳定商业价值的工程化能力。
2026-03-10 21:47:31
632
原创 软件开发的“最后时刻”：当公司开始用 AI Agents 全权交付项目
那篇文章里的公司之所以敢这样做，是因为他们把“项目”当成了“一次性消费品”。停止低水平的重复劳动： 如果你的工作内容是可以被 Agent 轻易模拟的“CRUD”或“模式化编码”，那么你现在就处在淘汰的边缘。转向“系统架构防御”： 未来的开发，不再是构建系统，而是管理系统。你需要学习如何设计能够对抗 AI 幻觉的架构，学习如何构建可观测性（Observability）体系，确保 AI 在瞎搞的时候，你能第一时间发现并切断。掌握“AI 治理（Governance）”
2026-03-10 02:45:00
243
原创 别被“AI 智能”洗脑了：OpenClaw 背后，是你不敢想象的“算力收割”与“隐私裸奔”
OpenClaw 现在之所以火，是因为它利用了人们对 AI 的盲目崇拜，同时也利用了大家对技术底层成本和安全逻辑的无知。别为了“酷”去烧钱，那是开发者和资本的角斗场。别把电脑的最高权限交给一个未经验证的 AI 模型，那是你数字资产的生命线。在这个 AI 泛滥的时代，我们必须学会的不是如何更积极地拥抱新技术，而是如何更坚决地守住自己的财务与隐私边界。让 OpenClaw 的那帮开发者去烧他们的钱、去担他们的风险吧。
2026-03-09 23:45:00
269
原创 别被 AI 的“酷炫”给骗了：为什么我们越来越容易被这种“爆火”带节奏？
最近，这个名字突然在网上疯狂刷屏，好像全世界都在讨论它。各大科技号都在发视频，配着极具科技感的音乐，剪辑着各种流畅的演示画面。
2026-03-09 19:22:43
356
原创 24个球中找异常球：如何用 4 次称重锁定目标？
在进入具体步骤前，我们先看一眼底层的数学逻辑。天平称重是一个典型的三进制问题。左重右重平衡如果有 n 次称重机会，我们最多能分辨 3n种状态。对于 24 个球，由于我们不知道它是“偏重”还是“偏轻”，所以每个球都有 2 种可能的异常状态（重或轻）。总共有 24 × 2 = 48 种可能性。如果称重3 次：33= 27 种可能性。27 < 48，显然无法覆盖所有情况。如果称重4 次：34= 81 种可能性。81 > 48，因此理论上 4 次称重完全可行。信息量的最大化。
2026-03-03 22:12:16
655
原创 八股篇（2）：关于 Sychronized 那些你不得不知道的知识
是 Java 提供的原子性内置锁，这种内置的并且使用者看不到的锁也被成为监视器锁。使用之后，会在编译之后在同步的代码块前后加上和字节码指令，他依赖操作系统底层互斥锁实现。它的作用主要就是实现原子性操作和解决共享变量的内存可见性问题。执行指令时会尝试获取对象锁，如果对象没有被锁定或者已经获得了锁，锁的计数器+1。此时其他竞争锁的线程则会进入等待队列中。执行指令时则会把计数器-1，当计数器值为 0 时，则锁释放，处于等待队列中的线程再继续竞争锁。
2026-03-02 20:18:02
809
原创 面试必会：手写单例模式（从零到完美的五种实现）
实现方式懒加载线程安全防止反射/序列化攻击推荐等级饿汉式❌✅❌⭐⭐DCL (双重检查)✅✅❌⭐⭐⭐⭐静态内部类✅✅❌⭐⭐⭐⭐⭐枚举❌✅✅⭐⭐⭐⭐⭐面试建议如果面试官让你写一个“完美的”单例，直接写静态内部类或DCL（记得解释volatile如果面试官问“哪种方式能防御反射攻击”，一定要提到枚举。你的支持是我创作的最大动力。
2026-02-22 21:00:58
1052
原创 云端编排与算力解构：2026 春晚亿级 AI 互动背后的极致弹性架构
从 2026 春晚的技术实践可以看出，Java 后端已不再是孤立的业务逻辑载体，而是云原生编排中的一个灵活节点。通过极致扩容原生编译与虚拟线程的结合，后端架构成功实现了在不拥有物理机房的前提下，对亿级流量的完美支撑。这种以 FinOps 为导向、以极致弹性为目标的开发思维，标志着大厂后端开发已从“系统维护”时代迈向了“算力治理”时代。
2026-02-20 19:51:12
739
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人