Van's Blog

做过 Agent 的人大概都遇到过这一幕:任务跑到第五轮,上下文窗口满了,任务直接失败。不是模型不够聪明,是对话历史里堆了几十万字符的工具输出——搜索结果、网页正文、代码片段,绝大多数在读完那一刻就成了占地方的噪声。 但你有没有好奇过:Claude Code、ChatGPT、Deep Research 这些主流 Agent,到底是怎么处理这个问题的?大多数人对压缩的认知停留在两句口诀:一句是"上下文超过阈值就自动压缩",另一句是"把脏活累活拆给子 Agent,只回传结论"。可真要追问下去——超过阈值之后具体做了什么?摘要怎么写的,丢了什么、留了什么?除了压缩和子 Agent,还有没有别的招?能说清楚的人就不多了。 这些问题的答案,藏在一本开源书里:《AI Agents in Depth》第二章「上下文工程」。作者用一组对照实验把压缩这件事拆得很彻底:六种压缩策略逐一对测,token 消耗、压缩率、任务成功率摆在一起对比;又给了一套生产环境的分层压缩方案,外加一张"什么能删、什么绝不能动"的保留优先级清单。这篇把核心结论提炼给你 ...

当安全工具可以通过类名 SQLInjectionController 直接判断漏洞类型时，我们测试的到底是工具能力，还是靶场本身提供的提示？ 随着大语言模型被广泛应用于代码安全分析，传统漏洞靶场正在逐渐失去其评估价值。许多安全工具在这些靶场上取得极高的检测率，但这并不一定意味着它们在真实环境中同样有效。 原因很简单：传统靶场过于"诚实"了。 它们往往在代码结构、命名和路径中直接暴露漏洞语义，使得工具无需深入分析即可判断漏洞类型。 本文提出一种新的设计方法：构建对抗 AI 的漏洞靶场，并通过自动化验证体系确保漏洞仍然真实存在。 具体来说，我们提出三个核心设计原则： 语义中立（Semantic Neutrality） —— 移除代码中的漏洞语义提示 代码混淆（Code Obfuscation） —— 模拟真实世界的对抗环境 Ground Truth 验证体系 —— 确保混淆后漏洞仍然可触发和利用 这些原则构成了一个新的安全测试基准：面向对抗环境的漏洞靶场（Adversarial Vulnerable Benchmark）。 传统漏洞靶场的问题 漏洞靶场长期以来 ...

项目地址：https://github.com/LuckVd/ClaudeDevKitV2 为什么做这个项目 在使用Claude Code Cli进行开发的时候，即使工具本身已经非常强大，但如果不对项目提前进行规划，而是通过多轮对话进行“对话式”开发，那么往往会有如下问题： AI失焦：比如在开头告诉了AI，修改完之后，严禁自己提交。但偶尔会忘掉该约束。 上下文漂移：随着对话轮次增加，AI更容易被后续局部任务“带偏”，遗忘最初设定的全局目标、边界条件或编码规范，最后虽然局部修改看起来合理，但整体实现已经偏离预期。 修改失控：缺少前期拆解和任务边界约束时，AI容易为了“顺手修好”相关问题而扩大改动范围，导致本来只想做小修小补，最后却引入额外重构、影响未涉及模块，增加回归和排查成本。 例如： 12345678910111213用户：帮我优化一下用户模块的性能 │ ▼AI：好的，我优化了数据库查询... 顺便重构了认证逻辑... 还清理了一些"冗余"代码... │ ▼结果： • 用户模块确实快了 20% • 但认证系统崩了（那不是冗余代码） ...

问题描述 最近扫描器一个poc在扫描时，遇到了一个诡异的现象，扫描器(linux环境)使用向目标服务器发送的Https POST 请求包总是抛出 ConnectionResetError。然而，在win中同样的环境(相同版本的python和requests)包下，却能正常收到 HTTP/1.1 404 Not Found 响应。 123456import requestsrequests.post('https://ip:port/events', json={"id": -1}, verify=False)# 抛出 requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')) 抓包跟踪 12345678910111213141 client -> server [SYN] Seq=0 ...

RAG 中的 Chunk 切分策略 在构建 RAG（Retrieval-Augmented Generation）系统时，Chunk 切分是最容易被忽视但影响最关键的步骤之一。 很多人把 RAG 的失败归咎于： LLM 模型不够强 检索算法不先进 向量数据库选型错误 但真正的常见原因是： Chunk 切分策略选择不当 本文将系统讲清楚： 为什么 RAG 必须进行 chunk 切分 5 种主流 chunking 方法及适用场景 chunk_size 和 chunk_overlap 如何配置 不同文档类型应该用什么策略 如何评估和优化 chunk 效果 生产环境的工程化实践 一、为什么 RAG 必须进行 Chunk 切分？ 1.1 Embedding 模型的上下文窗口限制 所有 embedding 模型都有最大输入长度： OpenAI text-embedding-3-small: 8191 tokens OpenAI text-embedding-3-large: 8191 tokens Cohere embed-english-v3.0: 512 ...

在学习RAG时，注意到其中的Embedding机制，跟深度学习中的Embedding进行了对比，发现两者虽然原理一致，但并不能完全算是同一个东西。因此做此记录。 在构建 RAG（Retrieval-Augmented Generation）系统时， Embedding是其中最为基础的一步，RAG 的第一步不是“生成”，而是“检索”。 而检索的基础，是一个结构良好的语义向量空间。 本文将系统讲清楚： RAG 中的 embedding 到底是什么 它和传统 DNN / TextCNN 中的 embedding 是否相同 分类损失 vs 对比损失的本质区别 语义 embedding 是如何训练出来的 为什么 RAG 必须依赖专门训练的 embedding 一、RAG 中的 Embedding 在做什么？ RAG 的流程是： 文档切分成 chunk 每个 chunk 转换为 embedding(文本 → embedding 模型 → 向量（如 1536 维）) 存入向量库 用户提问 → 转换为 embedding 计算相似度 → 取 Top- ...

项目地址：ClaudeDevKit AI辅助开发大型项目管理框架 一、项目是什么 ClaudeDevKit 是一个专为 AI 编程助手设计的项目治理框架。 一句话概括：让 AI 在帮你写代码的同时，不会乱改你的核心代码、不会破坏你的 API、不会忘记当前在做什么任务。 解决的问题 痛点 场景 ClaudeDevKit 的解决方案 代码被乱改 AI "顺手"修改了核心模块导致崩溃 三级文件保护机制 API 被破坏 AI 改了接口参数，调用方全挂 Breaking Change 自动检测 状态混乱 每次新会话都要重新解释项目 PROJECT.md 统一状态管理 提交不规范 AI 生成的 commit message 看不懂 Conventional Commits 自动生成 目标跑偏 AI 改着改着就偏离了当前任务 目标追踪系统 失败场景：没有 ClaudeDevKit 会怎样 缺失的机制 失败场景 后果 没有目标追踪 AI 在多个模块之间"游走"，改完 A 又去"优化" B 任务 ...

goroutines and concurrency 使用关键字go func()可以启动一个协程。 123456789101112131415161718package mainimport ( "fmt" "runtime")func say(s string) { for i := 0; i < 5; i++ { runtime.Gosched() fmt.Println(s) }}func main() { go say("world") // create a new goroutine say("hello") // current goroutine} 对于这个例子，其中runtime.Gosched()是显示指定让出cpu，执行另一个协程。该例子执行结果为 123456789helloworldhelloworldhelloworldhelloworldhe ...

参考资料：*Build Web Application with Golang* 开发环境 vscode + go1.21.5 +wsl Ubuntu20.04 go项目结构分为GoPath和GoModules两种。 GoPath 在GoPath模式下，所有和go项目相关的文件都在环境变量$GOPATH指向的路径下。在该路径下存在三个子路径： 1234$GOPATH├── src/ for source files whose suffix is .go, .c, .g, .s.├── pkg/ for compiled files whose suffix is .a.└── bin/ for executable files src存放所有的 Go 源代码文件，pkg存放编译后的库文件(.a 文件)，bin存放可执行文件。 这样导致的问题就是文件结构不自由并且多个项目的依赖管理困难。 注： #mjx-cc57f19{ display:contents; mjx-assistive-mml { u ...