- 博客(166)
- 资源 (2)
- 收藏
- 关注
RSS订阅
原创 Java并发编程之美
一、前言并发编程相比 Java 中其他知识点学习门槛较高，从而导致很多人望而却步。但无论是职场面试，还是高并发/高流量的系统的实现，却都离不开并发编程，于是能够真正掌握并发编程的人成为了市场迫切需求的人才。本书将通过图文结合、通俗易懂的方式帮助大家完成多线程并发编程从入门到实践的飞跃！本书分为三部分： - 第一部分Java并发编程基础篇主要讲解Java并发编程的基础知识，主要讲解线程有关...
2018-09-01 15:21:57
5728
6
原创 DeepSeek Harness 深度分析：用途、问题、架构原理与使用指南
如果 npm 包在中声明，安装后会自动进入该 Profile 的 bundle layer；普通插件依赖则需由 patch 配置显式挂载。
2026-08-16 10:23:45
449
原创 Codex CLI 是什么？一篇讲清代码 Agent、模型切换与本地部署
Codex CLI 可以配置 Azure 或其他自定义模型服务，包括企业内部网关、模型代理以及兼容所需接口协议的第三方平台。需要注意：支持自定义 Provider，不代表任何聊天 API 都能无缝使用。接口协议、流式响应、工具调用和模型能力都需要兼容。如果模型服务提供兼容接口，可以在export MY_MODEL_API_KEY = "你的密钥" codex服务是否支持 Codex 所需的接口协议；模型是否支持工具调用和流式输出；服务是否会存储上传的代码；是否允许商业使用；
2026-08-08 10:29:56
81
原创 程序猿的有效放松指南
问题错误做法正确做法工作后累刷手机躺平运动 + 户外颈肩酸痛忍着或贴膏药按摩 + 筋膜枪 + 拉伸睡不好、难入睡刷手机等睡意睡前泡澡/泡脚 + 冥想周末想放松睡一整天规律作息 + 主动活动大脑转不动强撑继续微休息 + 切换场景情绪烦躁独自憋着社交 + 运动 + 自然没有创意灵感使劲想散步、洗澡、发呆代码可以注释掉，大脑不能。维护好你自己，才能维护好系统。
2026-07-26 14:30:13
339
原创 Qwen 模型家族技术解析:通用、数学、视觉语言三条线
(通用)、(数学专家)、(视觉语言,重点看 7B 版本)。三者共享同一个基座血缘——Math 和 VL 都是在 Qwen2.5 通用模型基础上继续训练出来的专家模型,理解这层"继承关系"是看懂整个家族设计逻辑的关键。
2026-07-26 14:29:09
222
原创 # RAG 在 Agent 中的使用：从“强制检索“到“按需检索“
Pipeline RAG = 不管三七二十一，先查再说Agentic RAG = LLM 先想一想，该查才查，不该查就直接答核心变化：把 RAG 从"固定管道"变成"可选工具"实现方式：Tool Use API + Agent 循环（while True + stop_reason 判断）关键细节：工具 description 写得好不好，直接决定 LLM 的路由准确率所有能力最终都会变成工具，由 Agent 统一调度。RAG 是工具，SQL 查询是工具，API 调用是工具，代码执行也是工具。
2026-07-12 11:05:41
202
原创 我用 AI 做了个乘法口诀练习工具
暑假第一天，孩子拿着老师发的暑假清单给我看。孩子刚升完一年级，加减法还热乎着，老师就让提前啃乘法了。我第一反应是去买本口诀练习册。翻了翻，都是这种格式：一一得一，一二得二，一三得三……密密麻麻的字，没有图，没有动画，没有声音。孩子照着念了两遍，问我"，二三为什么是六啊"，我说"因为就是六"，她显然不满意这个答案。说得对。"就是六"不是解释，只是记忆。孩子没搞懂乘法是什么，就强行背结果，早晚会忘。我想了个办法：做一个工具，让孩子不只背口诀，还能。
2026-07-10 09:17:44
223
原创 人生100年，工作只是其中一段体验
人生100年，要体验的事太多了：一场说走就走的旅行，一道从没吃过的食物，孩子某个你差点错过的瞬间，父母某个你还没听过的故事，某个普通的早晨突然感到平静、觉得活着本身就已经很好……工作，是这张清单里的一项。认真体验，适可而止，不内耗自己，体验够了就退出。然后，去体验下一件事。这，才是人生该有的样子。大自然不需要你成功，它只需要你来看它一眼。工作不值得你燃烧殆尽，人生值得你全力以赴。如果这篇文章说出了你想说的，转发给需要看到它的人。
2026-07-01 20:36:01
226
原创 扩展-Trae Agent 深度技术分析
Trae Agent 是字节跳动开源的LLM 驱动通用软件工程 Agent，专为自动解决复杂编程任务而设计，包括 GitHub issue 修复、代码重构、单元测试生成等。
2026-07-01 18:59:55
261
原创 RAG — 给模型装上“外部大脑“
不改模型，改输入。传统方式：用户问题 → LLM → 回答（可能幻觉）RAG 方式：用户问题 → 检索相关文档 → 文档 + 问题 → LLM → 有据可查的回答分块策略——决定检索能不能找到完整的、语义连贯的文档片段检索策略——混合搜索 + 重排序 > 纯向量搜索 > 纯关键词搜索Embedding 模型——影响向量质量，但影响力低于分块策略LLM 生成质量——在前三步都做好的前提下，差异最小。
2026-06-26 16:10:52
354
原创 扩展-/goal 与 /loop 实战：一个可以直接运行验证的闭环演示
有了 goal，Agent 在每次行动后都能自己检查距离终态还差多远，不需要问你。
2026-06-26 10:03:17
32
原创 扩展-AI Loop：在Calude code中的实现
goal命令告诉 Claude Code 你最终要达到的状态，不是要做的事情。错误写法/goal 重构用户服务模块这个"目标"Claude 无法验证——重构到什么程度算完成？什么叫做好的重构？Agent 无从判断，要么提前宣告完成，要么永远跑下去。正确写法/goal src/services/user/ 目录下所有 TypeScript 文件通过 ESLint 检查，且单元测试覆盖率不低于 80%，所有测试绿灯这个目标有三个清晰的检验点：ESLint 通过、覆盖率 ≥ 80%、测试全绿。
2026-06-25 09:59:11
484
原创 扩展-Agent Loop：自主执行的工程哲学
单次推理给你一个答案，持续循环给你一个结果。这两件事之间的距离，就是 Agent 工程的全部难度。
2026-06-25 09:56:53
464
原创 Top 5 AI 公司生态对比
工具层 GPTs（自定义 Agent）/ Canvas / Deep Research / Operator。模型层 GPT-4o / o3 / o4-mini / Sora / DALL·E / Whisper。模型层 Llama 4（开源）/ Llama 3.x 系列 / AudioCraft / SAM 2。模型层 Gemini 2.5 Pro/Flash / Imagen 3 / Veo 2（视频）
2026-06-23 10:04:55
335
原创 larksuite-cli&skill
项目概述源码地址：https://github.com/larksuite/clilarksuite/cli 是飞书/Lark 官方出品的命令行工具，GitHub 13.5k stars，551 次提交，活跃度极高。核心定位：同时服务人类用户和 AI Agent。覆盖飞书 18 个业务域：IM、文档、表格、日历、任务、审批、考勤、Wiki、邮件、OKR、视频会议等。技术栈层面 选型语言 Go 1.23（占比 97.5%）
2026-06-23 10:03:38
239
原创 附录 D：具身智能 — 从数字世界到物理世界的延伸
本书讲的所有能力——RAG、Function Call、MCP、Agent——都发生在数字世界里。信息的输入是文字和图片，输出也是文字和代码。但 AI 的边界正在延伸到物理世界。在写第十章 Computer Use 的时候，我有一个很强烈的感受：Computer Use 让 Agent 学会了"操控屏幕"，但屏幕只是人类工具的很小一部分。螺丝刀、手术刀、方向盘、焊枪——这些没有屏幕的工具怎么办？
2026-06-22 09:56:43
214
原创 附录 C：端侧 AI — 隐私 + 低延迟驱动的本地化趋势
本书讲的所有技术——从 Claude API 到 MCP 到 Agent——都有一个隐含前提：你的数据会离开你的设备，经过网络，到达某个云端服务器，被处理后返回结果。在大部分场景下这没什么问题。但在某些场景下，这是不可接受的。我第一次意识到这件事的重量，是在帮一个做健康管理的朋友设计系统原型的时候。用户的需求很简单："分析我的高血压记录和饮食日记，告诉我哪些食物对我血压影响最大。"技术上不难，RAG + 结构化查询就能做。但当我准备写 API 调用代码时，朋友说了一句：“这些数据不能出设备。
2026-06-22 09:56:12
301
原创 附录 B：A2A 协议 — Agent 之间的下一个标准
MCP 解决的是"Agent 怎么调工具"——数据库、搜索引擎、文件系统，这些是被动执行指令的"工具"。A2A 解决的是"Agent 怎么委托另一个 Agent"——有自己推理能力、能自主决策的"同事"。想象这样一个场景：你有一个负责需求分析的 Agent，一个负责代码实现的 Agent，一个负责测试的 Agent，一个负责部署的 Agent。但问题在于，你公司的采集 Agent 是用 Claude 写的，合作伙伴的分析 Agent 是用 Gemini 写的。本书讲的是"人与 Agent 的协作"。
2026-06-21 12:38:13
24
原创 附录 A：给工程师的建议 — 如何在 AI 时代持续保持竞争力
第一句：AI 不会替代工程师，但会用 AI 的工程师会替代不会用的。这句话已经被说烂了，但数据确实在验证它——精英团队和普通团队之间的生产力差距已经拉到接近 2 倍，而且还在扩大。第二句：不要被"自我感觉变快了"骗了。METR 的数据清楚地表明，人们对 AI 效果的高估平均达 40 个百分点。真正的效率提升来自于系统性地把 AI 嵌入工作流（MCP + Skill + Harness），而不是偶尔打开 ChatGPT 问一句。第三句：入门级岗位的萎缩是真实的。
2026-06-21 12:37:38
23
原创 第十三章：AI 能力演进：从 LLM 到自主进化 Agent-后记
我们处在一个罕见的历史窗口期。AI 能力正在高速成熟，但真正能把这些能力转化为可靠系统的工程师，还远远不够。这个窗口期不会永远开着。现在是最好的时机。写于 2026 年致每一位正在把 AI 变成真正有用的东西的工程师“技术的价值不在于它有多先进，而在于它被谁使用，被用来解决什么问题。
2026-06-20 09:36:38
132
原创 第十二章：飞书 CLI — 生产级 Agent 工具的工程解剖
飞书 CLI 的设计可以总结为五个原则，适用于任何"为 Agent 设计工具"的场景。原则一：stdout 是数据，stderr 是其他一切Agent 通过管道消费 stdout。进度条、警告信息、更新提示、日志——任何非数据内容混入 stdout 都会破坏 Agent 的解析链。这个区分必须在架构层面强制，不能靠约定。原则二：错误必须结构化且版本稳定Agent 不看错误文本（文本会随版本迭代改变），它看结构化字段。
2026-06-20 09:35:31
136
原创 第十一章：自主进化 Agent — 越用越强的设计模式
前面所有章节构建的 Agent 都有一个共同的隐含前提：它们在使用过程中不会成长。你用了一年的 Agent，和你用了一天的 Agent，能力边界完全相同。上周它帮你解决了一个 Python 依赖冲突，下周同样的问题再出现，它依然从零开始思考。这在人类同事的视角里不可想象——一个工作了一年的工程师，绝对不可能和入职第一天一样。自主进化 Agent 要解决的就是这个问题：让 Agent 从"工具"变成"同事"，越用越强。本章讲清楚六件事：你的团队每天都会做"代码提交前检查"这件事：跑 linter、跑测试、写提
2026-06-19 08:54:18
55
原创 第十章：Anthropic Harness — 长时间 Agent 的架构哲学
在第七章，我们讨论了上下文管理的两种策略：摘要压缩和滑动窗口。那么为什么 Anthropic Harness 选择了更激进的完整重置（Context Reset）？摘要压缩的根本问题摘要本身是一个 LLM 生成的内容，存在幻觉风险。更重要的是，摘要压缩了细节但保留了"思路"——这恰恰保留了上下文污染的来源。一个 Agent 做了很多错误尝试之后，即使压缩了历史，它的思维方式依然被那些错误尝试所污染。完整重置 + Handoff Artifact 的优势。
2026-06-19 08:53:09
28
原创 第九章：Harness Engineering — 让 AI 系统可测、可信、可运维
前面十章一路在给 Agent 加能力：工具调用、MCP 协议、ReAct 循环、Skill 固化、多模态感知、Computer Use。到这里，你的 Agent 已经能做很多事了——但"能跑"和"敢上线"之间还隔着一道巨大的鸿沟。AI 系统的输出是概率性的，传统的 在这里直接失效；模型出了错，你没法像调试代码一样单步追踪；上线后出了问题，你甚至不知道该看哪个指标。Harness Engineering 就是解决这个"从能跑到可信"的工程方法论：用评估体系替代精确断言，用护栏约束替代人工审核，用可观测性替代
2026-06-18 08:57:40
31
原创 第八章：Skill — 把经验固化为可复用的工作流
Skill 数据结构定义 —— 用 Pydantic 将 YAML 文件映射为类型安全的 Python 对象# 核心原则：在数据加载阶段（而非运行时）暴露结构错误"""Skill 参数定义"""name: str = Field(description="参数名称")type: ArgType = Field(default=ArgType.STRING, description="参数类型")description: str = Field(description="参数说明")
2026-06-18 08:56:57
38
原创 第七章：AI Agent — 自主完成复杂目标
前几章解决的是"单次调用"的问题：RAG 让模型能查文档，Function Call 让模型能调工具，MCP 统一了工具协议。但这些能力有一个共同的天花板——每次调用都需要人来发起，模型完成后交还控制权，下一步怎么走还是人决定。现实的复杂任务不是这样运转的：Agent 的本质是给 LLM 装上一个循环：让模型在完成一步后自己决定下一步，直到目标达成。这个循环加上工具调用能力，就把 LLM 从"问答机器"变成了"能干活的执行者"。本章讲清楚五件事：在第一章我们讲过，LLM 的本质是一个函数：给定输入 tok
2026-06-18 08:56:11
21
原创 第六章：MCP — 工具能力的标准化协议
上一章的 Function Call 解决了"模型能不能调用工具"的问题。但如果你在一个真实团队里推广这套做法，很快会遇到一个新问题：工具越来越多，管理越来越乱。MCP（Model Context Protocol）正是为了解决这个问题而生的——它不是一个库，而是一套协议，定义了工具应该如何注册、发现、调用，让 AI 工具从"各自为政"变成"可插拔的标准件"。本章讲清楚四件事：假设你在一家中型技术公司，三个团队各自维护了 AI 工具：现在你有 4 个 AI 应用需要用这些工具：代码助手、运维 Bot、数据分
2026-06-18 08:55:31
21
原创 第五章：Function Call — 从“说“到“做“
上一章的 RAG 解决了"知识边界"的问题：让模型能看到它训练数据之外的内容。但知道了还不够——在真实的业务场景中，我们需要模型做事，而不仅仅是说话。查一下当前天气、算一道复利、调用支付 API 提交一笔订单——这些都不是文本生成能完成的。Function Call（工具调用） 正是为了弥合这个鸿沟：让 LLM 输出结构化的"意图"，由外部系统去真正执行。本章讲清楚三件事：你让 AI 帮你查一下今天北京的天气，它给你一段流畅的文字：“北京今天天气晴朗，气温约 22 度”。听起来不错，但这是它编的——它根本没
2026-06-18 08:54:47
20
原创 第四章：RAG — 给模型装上“外部大脑“
第二章讲了 LLM 的六个局限，其中两个在工程上最频繁出现：知识截止（训练数据有截止日期）和私有知识盲区（模型永远不知道你公司内部的文档）。RAG（Retrieval-Augmented Generation，检索增强生成）直接针对这两个问题：不用把知识"烧进"模型权重，而是在回答时动态查询外部知识库，把相关文档塞进 Context Window。本章讲清楚四件事：你刚给客服系统接入了 Claude，第一周大家都很兴奋。第二周，工程师开始遇到两类麻烦：痛点一：模型不知道最新发生的事痛点二：模型不知道公司内
2026-06-17 20:40:51
31
原创 AI 能力演进：从 LLM 到自主进化 Agent-前言
2025 年初，我在一家大型互联网公司内部做了一次分享，题目叫"我们应该怎么用 AI"。台下坐着大约 200 名工程师，都是有多年经验的后端、算法、客户端开发。举手的，不到 20 个人。这个比例让我意外。不是因为他们不知道 AI，他们全都知道 ChatGPT，知道 Claude，知道 Copilot。问题在另一边：“知道是一回事，真正用起来是另一回事。我们不知道边界在哪里，也不知道架构怎么搭。这句话，一个做了 8 年后端的工程师说的。他的困惑代表了大多数人的困惑：AI 能力正在高速膨胀，但。
2026-06-17 20:30:51
163
原创 第一章：LLM — 一切的起点
回到本节最初的问题：Embedding、W_Q/W_K/W_V、FFN 这些参数，一开始全是随机数，是如何变成"懂语言"的？答案：三个阶段，解决三个不同的问题初始状态：所有参数随机初始化（Embedding 里"猫"和"巴黎"向量一样随机）─── 阶段一：预训练（详见 1.2.2）────────────────────────在数万亿 Token 上反复预测下一个词，梯度下降调整所有参数。结果：Embedding：相似词向量靠近（"猫"≈"狗"，"猫"≠"巴黎"）
2026-06-17 20:27:04
425
原创 从开源框架看并发设计
pending通道 -> Poller goroutine -> HTTP 请求 ->complete通道 -> Sleep -> 回pending。多个 Poller goroutine 从pending通道获取 URL 资源，发起 HTTP 请求后将结果写入complete通道。StateMonitor 从complete通道接收更新并维护全局状态。通道传递的是指针，同时只有一个 goroutine 拥有资源的访问权，因此不需要加锁。URL 资源在任意时刻要么在pending。
2026-06-16 09:18:22
21
原创 并发陷阱与最佳实践
经过前面章节的学习，读者已经掌握了 Go 并发编程的所有核心工具和设计模式。然而，"知道怎么用"与"用好"之间还有一段距离。在实际工程中，并发程序的 bug 往往具有不确定性——同样的代码，在不同的机器、不同的负载下，可能时而正确、时而出错。这种非确定性使得并发 bug 极难复现、极难调试。本章系统梳理 Go 并发编程中最常见的陷阱，分析每个陷阱的成因和后果，并给出具体的检测手段和最佳实践。每个 goroutine 都必须有明确的退出机制：使用 context 或 done channel 通知退出。
2026-06-16 09:17:49
23
原创 经典并发模式（Pipeline、Fan-out/Fan-in、Worker Pool）
掌握了 goroutine、channel 和 context 之后，我们已经拥有了 Go 并发编程的全部基础工具。但工具本身不等于设计能力——就像掌握了锤子和钉子不等于会建房子一样。Pipeline（流水线）Fan-out/Fan-in（扇出/扇入）和Worker Pool（工作池）。这三种模式由 Go 团队在多次技术分享中反复推荐，是 Go 并发编程的"设计语言"。它们不仅各自解决特定的并发问题，更可以灵活组合来应对复杂的实际场景。Pipeline。
2026-06-16 09:17:18
26
原创 Context——并发任务的控制与超时
本章系统讲解了contextContext 接口的四个方法提供了截止时间查询、取消信号监听、错误获取和值传递四种能力。context 的树形传播确保了父 context 取消时，所有子 context 自动取消。和用于超时控制，WithCancel用于手动取消。context 是第一个参数的约定已成为 Go 生态的通用规范，函数签名应为仅用于传递请求级元数据，不要滥用。下一章我们将在 goroutine、channel 和 context 的基础上，学习三种经典的并发设计模式。
2026-06-16 09:16:45
22
原创 Channel——Go 并发的核心通信机制
Channel 是 Go 并发哲学的核心体现。“不要通过共享内存来通信，而要通过通信来共享内存”——这句话中的"通信"，指的就是 channel。如果说 goroutine 是 Go 并发的执行体，那么 channel 就是 goroutine 之间传递数据和协调控制流的管道。本章将系统讲解 channel 的分类与方向、阻塞规则、关闭规则、select多路复用、happens-before 语义，以及 channel 与time包结合实现超时控制的技巧。无缓冲通道是同步工具，发送和接收必须"握手"；
2026-06-16 09:16:11
54
原创 sync.WaitGroup 与 sync.Once
在前面的章节中，我们学习了互斥锁、读写锁和原子操作，它们解决的是"如何安全地访问共享数据"。如何协调多个 goroutine 的执行顺序。在 Java 中最接近的等价物是——等所有 goroutine 执行完毕后再继续（但与不同，WaitGroup的计数器可以复用，可以多次AddWaitsync.Once则确保某段初始化代码只执行一次，无论多少个 goroutine 并发调用。本章将深入讲解这两个工具的使用方法、内部原理和实践中容易踩的坑。本章讲解了和sync.Once。
2026-06-16 09:15:31
20
99 bottles of oop
2023-01-21
ppt to word ppt转word ppt截图 mfc 源码
2013-03-16
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人