152 篇文章带有标签 “llm”

为进一步提升公司代码安全自动化防护能力，研发中心围绕Strix多智能体网络安全渗透测试工具，针对开源Java漏洞实训平台JavaSecLab开展白盒深度代码审计与系统化渗透测试选型论证。本次评估重点考察Strix在复杂业务逻辑场景下的漏洞挖掘效能、标准化报告输出能力，以及对接CI/CD研发流水线的集成适配潜力，具体论证情况如下：

1. Strix：LLM驱动的多智能体安全审计架构

Strix是基于大语言模型（LLM）构建的自动化渗透测试工具，核心能力为多智能体协同检测。本次测评对象JavaSecLab基于Spring Boot、MyBatis‑Plus、Layui等主流技术栈搭建，Strix可实现源代码、框架配置、业务逻辑、第三方依赖组件的全域覆盖。 借助深度扫描模式，工具完成全量代码静态分析、漏洞溯源与完整数据流审计，成功识别出反序列化RCE、SQL注入、认证绕过、SSRF、XXE等多类型安全漏洞，覆盖代码层、依赖层、业务逻辑层多个风险面。

2. 深度审计执行流程与多维度结果输出机制 Strix具备高自主化审计执行能力，内部调度8类专业智能体协同完成任务；以JavaSecLab深度审计任务为例，单次任务LLM调用次数约306次，Token消耗约21.5M。

摘要

大语言模型驱动的代码生成技术正在重构传统软件工程的生产模式，软件开发重心逐步从手工代码编写迁移至需求定义、约束建模与质量验证环节。上海交通大学林云副教授提出 需求编译（Requirement Compilation） 理念，以 ARC（Agentic Requirement Compilation）智能体需求编译框架为核心，探索把大规模多模态业务需求文档直接转化为可运行软件系统的技术路径，同时开展面向智能体软件工程的课程教学改革，推动开发者从“代码工人”向“智能体架构师”转型。本文基于该前沿报告，梳理智能体软件工程范式变革背景、ARC框架技术原理、现存技术痛点、教学实践方案，同时分析产业落地瓶颈与未来研究方向，为Agent软件工程领域提供研究参考。

关键词：智能体软件工程；需求编译；ARC框架；大语言模型；测试驱动开发；DSL领域特定语言

一、引言

传统软件工程流程以人工编码为核心，需求、设计、编码、测试环节由人主导完成。生成式大模型出现后，单轮提示词生成小程序代码已经较为成熟，但面对包含数十至数百业务场景的大规模真实业务需求时，通用大模型普遍存在需求理解不全、逻辑幻觉、边界场景遗漏、架构混乱、需求‑代码不可追溯等问题，很难直接产出完整可维护的软件系统，形成AI编程的“复杂性高墙”。

现有Agent编程大多聚焦于代码补全、小脚本生成，缺少一套完整的、工程化的端到端链路：即从非结构化

• Kimi K3: Open Frontier Intelligence

一、研究背景

大型语言模型（LLM）的发展一直沿着两条轴线推进：

• 第一轴：预训练规模扩展——在部署前投入更多计算，训练更大的模型、使用更多的数据。这是传统意义上的"Scaling Law"。
• 第二轴：测试时计算扩展——通过强化学习和推理时增加思考预算，让模型在回答问题时"想得更久"。

近年来，OpenAI的o系列、Anthropic的扩展思维模型、DeepSeek-R1和Kimi K1.5等工作，让"测试时扩展"成为前沿研究的核心焦点。然而，开源社区在第二条轴上进展迅速，但在第一条轴上却明显滞后——大多数开源模型仍停留在1T参数规模左右。随着越来越复杂的推理和智能体方法被应用于规模相近的预训练模型上，开源进展面临趋同风险，而与最强大专有系统（Claude、GPT系列）的差距可能持续扩大。

与此同时，真实世界的智能体任务需要处理超长上下文（如软件工程仓库、数万页文档、多天跨度的对话），要求模型同时具备大参数规模、长上下文窗口和原生多模态理解能力。Kimi K3正是在这一背景下诞生的：同时推进两条扩展轴，将预训练基础扩展到前所未有的3T类参数规模，同时在1M上下文长度上扩展强化学习、推理努力和长周期交互。

二、要解决什么问题

Kimi K3要解决的核心问题可以概括为以下

本文档基于Strix 多智能体网络安全渗透测试工具，对开源 Java 漏洞实训平台 JavaSecLab 开展深度白盒代码审计与系统性安全渗透测试。依托 Strix 多智能体协同检测能力，本次测试覆盖项目全部源代码、框架配置、业务逻辑及第三方依赖组件，完整挖掘、归类、验证项目内置的各类安全漏洞。

JavaSecLab 作为面向安全学习、代码审计、安全开发与工具测评的综合型 Java 漏洞靶场，集中复现了 Web 安全、代码缺陷、组件漏洞、业务逻辑风险等大量典型安全问题。本次通过 Strix 深度扫描模式，完成全量代码静态分析、漏洞溯源、数据流审计、风险定级与攻击路径复盘，累计检出严重、高危、中危、低危多维度安全漏洞，覆盖反序列化 RCE、SQL 注入、认证绕过、SSRF、XXE、XSS、模板注入、文件操作漏洞及第三方依赖高危 CVE 等核心风险场景。

Strix 命令行帮助文档

基于 strix 1.3.1 源码（https://github.com/usestrix/strix）逐行核对 CLI 与运行逻辑编写。所有命令参数对应真实代码位置，可直接复制使用。

⚠️ 合规前提：Strix 是自动化渗透测试工具，仅可用于你拥有或已获书面授权的应用/资产。未经授权扫描他人系统属于违法行为。本指南所有示例目标均假设你拥有测试权限。

一、项目定位

Strix 是一个开源 AI 渗透测试工具，部署自主 AI agent 团队对应用进行漏洞发现与验证。核心区别于静态扫描器（SAST）：agent 像真实红队一样动态运行代码、构造 PoC、验证可利用性，产出可复现的漏洞报告而非误报堆积。面向开发与安全团队，支持 CI/CD 集成。

仓库：https://github.com/usestrix/strix ｜ 版本：1.3.1 ｜ License：Apache-2.0

二、技术栈

面向 LLM · RAG · Agent 的高精度文档解析引擎 ｜ 实测版本 3.4.4 ｜ 含本地真实跑通经验与踩坑实录

• 【WorkBuddy】MinerU使用指南

一、介绍：MinerU 是什么

MinerU（opendatalab/MinerU）是一个面向 LLM · RAG · Agent 工作流 的高精度文档解析引擎。它把 PDF / 图片 / DOCX / PPTX / XLSX / 网页转换为机器可读的 Markdown / JSON，供下游检索、抽取与处理。它的起源是 InternLM 预训练过程中的科学文献符号（公式、表格）转换需求，因此对公式和表格的处理是强项。

一句话定位：把"人类看的文档"变成"模型能吃的干净结构化数据"——这是任何 RAG / 知识库 / 文档智能产品的第一道摄入层。

1.1 能力矩阵

下面是 CLAUDE.md 文件的内容，用于改善 Claude Code 的行为，源自 Andrej Karpathy 的观察 关于 LLM 编码陷阱的总结。

CLAUDE.md

旨在减少大语言模型常见编码错误的行为准则。可根据项目特定说明按需合并。

权衡： 本准则偏向谨慎而非速度。对于琐碎任务，请自行判断。

1. 编码前先思考

不要假设。不要掩饰困惑。要呈现权衡。

实施之前：

• 明确陈述你的假设。如果不确定，就提问。
• 若存在多种解读，请呈现出来——不要默默选择一种。
• 若有更简单的做法，请说出来。在必要时坚持己见。
• 若某事不清楚，就停下来。指出困惑所在。提问。

2. 简单至上

用最少的代码解决问题。不添加任何推测性内容。

• 不添加需求以外的功能。
• 不为一次性代码创建抽象。
• 不提供未要求的“灵活性”或“可配置性”。
• 不对不可能发生的场景进行错误处理。
• 如果你写了 200 行，而本可以 50 行完成，那就重写。

问问自己：“一位资深工程师会认为这过于复杂吗？” 如果会，就简化它。

3. 外科手术式的修改

只碰你必须改的。只清理你自己弄乱的。

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构没有坏的东西。
• 即使你有不同做法，也要遵循现有风格。
• 若注意到无关的无效代码，提出来——但不要删除。

当你的修改造成孤立代码时： 删除由你的修改导致的未使用的导入/变量/函数。

一、技术方案

1.1 总体架构

采用 “公众号前端 + 智能客服中台 + 知识库底座” 三层架构：

层级	功能	技术选型建议
接入层	公众号对话入口，支持文字、图片、视频等多模态输入	微信公众号开发接口
智能客服中台	意图识别、知识检索、问答生成、智能路由（AI/人工分流）	RAG架构 + 大模型API（通义千问/Qwen、文心一言等）
知识库底座	产品手册、FAQ、历史工单、维修案例的结构化存储与向量检索	向量数据库 + 结构化知识库

1.2 核心功能模块

1. 智能问答：基于RAG（检索增强生成）架构，系统从知识库中检索相关文档，再由大模型生成精准答案。方案匹配准确率可达92%以上。

2. 多模态故障识别：支持客户上传故障图片/视频，利用多模态大模型进行图像识别与故障推理，自动推送处理建议。

3. 智能路由与转人工：AI首轮处理常规问题，疑难问题自动转接人工客服，实现“AI首轮服务＋人工兜底”的协同模式。

4. 知识自进化：系统在问答过程中持续学习，客户采纳的答案自动整理为问答对，不断优化知识库。

1.3 实施路径（建议分三期）

在大语言模型（LLM）的生产落地中，自回归生成的 $O(N)$ 延迟始终是制约用户体验与系统吞吐的瓶颈。投机采样（Speculative Decoding）通过引入轻量级的“草稿模型（Draft Model）”先行生成候选 Token，再由大模型（Verification Model）进行并行校验，成为了当前最主流的加速方案。

本文将针对当前业界前沿的三种草稿模型方案——DFlash（纯并行）、DSpark（半自回归） 与 Eagle3（纯自回归） 进行深度架构剖析、技术指标对比及选型建议。

一、 核心架构与生成机制对比

三种方案的本质区别在于“生成速度（并行度）”与“草稿质量（接受率）”的权衡。以下图表直观展示了它们在计算模式上的根本差异：

graph TD
    %% 样式定义
    classDef flash fill:#d4edda,stroke:#28a745,stroke-width:2px;
    classDef spark fill:#fff3cd,stroke:#ffc107,stroke-width:2px;
    classDef eagle fill:#f8d7da,stroke:#dc3545,stroke-width:2px;

    subgraph DFlash ["DFlash: 纯并行 O(1)"]
        direction LR
        In1[输入 Token] -->|一次性前向传播| P1[Token 1] & P2[Token 2] & P3[Token 3] & P4[Token 4]
        note1[...]:::flash
    end

    subgraph DSpark [DSpark: 半自回归 - 带修正]
        direction LR
        In2[输入 Token] -->|马尔可夫并行生成| S1[候选池]
        S1 -->|置信度轻量筛选| S2[高概率 Token 块]
    end

    subgraph Eagle3 ["Eagle3: 纯自回归 O(N)"]
        direction TB
        In3[输入 Token] --> E1[草稿 Token 1]
        E1 -->|作为下一步输入| E2[草稿 Token 2]
        E2 -->|作为下一步输入| E3[草稿 Token 3]
    end

    class DFlash flash;
    class DSpark spark;
    class Eagle3 eagle;

1. DFlash (纯并行 / 无修正)

• 机制：完全打破传统的自回归依赖。利用位置编码或修改 Attention Mask，在单次前向传播中强行“同时”预测未来多个位置的 Token。
• 特点：拥有极致的 $O(1)$ 时间复杂度，草稿生成阶段几乎不占用时间。但由于缺乏 Token 间的显式上下文依赖，预测长度越长，准确率（接受率）崩塌越严重。

2. DSpark (半自回归 / 马尔可夫 + 置信度调度)

• 机制：介于并行与串行之间。利用轻量级的马尔可夫链（Markov Chain）或浅层 Head 快速并行产生多个候选 Token，并在其上叠加一套置信度（Confidence）评估系统。
• 特点：在 $O(1)$ 并行生成的基础上增加了“轻量修正”过滤。系统会根据当前生成的置信度动态截断低质草稿，实现 $O(1) + \text{修正}$ 的动态时间复杂度，在速度与质量之间取得了极佳的平衡。

本文基于 DeepSpec 开源代码，以 Qwen3-4B + DSpark 为具体实例，从算法思想、模型架构、训练数据流、推理流程四个维度，逐行拆解代码，帮助你完整理解 DSpark 草稿模型的训练与推理工作原理。

DeepSpec 核心工作原理

DeepSpec 训练草稿模型的本质是：在目标模型的 backbone 架构上，构建一个更小的 draft 网络，使用目标模型预计算的 hidden states 作为监督信号进行训练。

因此，适配新模型的核心工作量是让 draft 模型能够"理解"目标模型的内部表示——这包括：

• 复用目标模型的 tokenizer、embedding、归一化层、旋转位置编码等组件
• 从目标模型的特定层抽取 hidden states 作为 draft 模型的输入
• 保持注意力机制、MLP 结构与目标模型一致

一、DSpark 是什么：核心思想

DSpark 是一种面向推测解码（Speculative Decoding）的草稿模型训练方法。它的核心洞察可以总结为一句话：

"让草稿模型在训练时就学会——给定目标模型某几层的 hidden states，一次性猜出接下来的 N 个 token 是什么。"

传统训练语言模型是自回归的：输入 t0, t1, t2，预测 t3。

• DSpark 论文

北京大学　DeepSeek-AI

摘要

推测解码（Speculative Decoding）通过将草稿生成与目标验证解耦来加速大语言模型（LLM）推理。尽管最近的并行 drafter 能够在单次前向传播中高效 Proposed 长令牌序列，但由于缺乏令牌间依赖关系，它们面临着接受率快速衰减的问题。此外，不加区分地验证这些扩展块会浪费关键的批次容量在具有高拒绝风险的令牌上，严重降低了高并发服务系统中的吞吐量。

我们提出了 DSpark，这是一个推测解码框架，统一了高吞吐量的并行生成与自适应的、负载感知的验证。为了保持草稿质量，DSpark 利用半自回归架构——将并行主干与轻量级顺序模块耦合——引入块内依赖建模并缓解后缀衰减。为了优化系统效率，DSpark 采用置信度调度验证，根据估计的前缀存活概率和引擎特定的吞吐量配置文件，动态地为每个请求定制验证长度。

在跨多个领域的离线基准测试中，DSpark 在已接受长度方面显著优于最先进的自回归和并行 drafter。当部署在 DeepSeek-V4 服务系统中并处理实时用户流量时，DSpark 成功缓解了验证浪费。与已确立的生产基线（MTP-1）相比，DSpark 在匹配的吞吐量水平上加速了每用户生成速度 60%–85%。

结合 DSpark 论文与代码实现，全面剖析 DeepSpec 的工作原理与核心组件。

项目地址：https://github.com/deepseek-ai/DeepSpec DSpark 论文：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

DSpark 是 DeepSeek 提出的一套无损加速大模型推理的“看人下菜碟”机制。 传统加速手段（推测解码）通常是让小模型一次性盲目盲猜一大串后续 Token，再让大模型统一验证。但这存在两个痛点：小模型猜得越往后越不准（多模态冲突导致“后缀衰减”）；高并发时，大模型花大力气去验证那些猜得不准的 Token，会严重压垮系统吞吐。

DSpark 的核心突破就在于两点：

1. 猜得更准（半自回归）： 它在原有的单次并行生成网络后，拼了一个极轻量的小尾巴（顺序头），在几乎不增加延迟的情况下，让后面的 Token 能根据前面猜出的 Token 进行自适应修正，大幅提升长序列的猜测准确度。
2. 动态裁剪（置信度调度）： 它能实时感知系统的硬件负载与并发压力。如果并发高、大模型很忙，或者发现后面小模型猜的置信度太低，它就会果断把不靠谱的后缀砍掉，只送靠谱的前缀给大模型验证。

通过这种“高质量猜测”与“负载感知动态裁剪”的结合，DSpark 在保障大模型输出质量完全无损的前提下，成功

Pi 是一个模块化的 AI 编码智能体 Monorepo，使用 TypeScript 构建。它提供统一的 LLM 抽象层、通用的智能体运行时、丰富的终端 UI 框架，以及完全可扩展的编码智能体命令行工具。

1. 项目概览

Pi（@earendil-works/pi-mono）是由 Mario Zechner 开发的 AI 编码智能体 Monorepo，设计理念是模块化、可扩展、供应商无关。它将多个 LLM 供应商的复杂性抽象为统一 API，提供强大的智能体运行时和工具执行能力，并附带生产就绪的终端 UI。

核心能力

能力	说明
统一 LLM API	9 种 API 协议和 30+ 供应商品牌的单一接口。只需修改一个字符串即可切换供应商。
智能体运行时	完整的智能体循环，支持并行工具执行、消息注入队列和上下文压缩。
丰富的终端 UI	独立的终端 UI 框架，支持差异化渲染、文本编辑器、图片显示和浮层系统。
扩展系统	80+ 扩展示例、20+ 生命周期钩子。可注册工具、命令、快捷键和供应商。
Web 组件	基于 Lit 的聊天 UI，支持沙箱化 Artifact 渲染（HTML、SVG、PDF、DOCX 等）。
多运行模式	交互式终端、管道友好的打印模式，以及用于 IDE 集成的 JSONL RPC 模式。

包依赖关系图

graph TD
    subgraph "第一层：基础层"
        ai["<b>pi-ai</b><br/>统一 LLM API<br/>30+ 供应商"]
    end
    subgraph "第二层：运行时层"
        agent["<b>pi-agent-core</b><br/>智能体运行时<br/>工具执行"]
    end
    subgraph "第三层：UI 层"
        tui["<b>pi-tui</b><br/>终端 UI 框架<br/>零依赖"]
    end
    subgraph "第四层：应用层"
        coding["<b>pi-coding-agent</b><br/>编码智能体 CLI<br/>扩展与工具"]
        webui["<b>pi-web-ui</b><br/>Web UI 组件<br/>Lit + Tailwind"]
    end

    ai --> agent
    agent --> coding
    tui --> coding
    ai --> webui
    tui --> webui

    style ai fill:#1f6feb,stroke:#388bfd,color:#fff
    style agent fill:#238636,stroke:#3fb950,color:#fff
    style tui fill:#8957e5,stroke:#bc8cff,color:#fff
    style coding fill:#da3633,stroke:#f85149,color:#fff
    style webui fill:#e3b341,stroke:#d29922,color:#fff

图 1: Pi monorepo 包依赖关系图 — 4 层架构，5 个包

DeepSeek-V4

简介

我们在此发布 DeepSeek-V4 系列的预览版本，包括两个强大的混合专家（MoE）语言模型 —— 总参数量 1.6T（激活 49B）的 DeepSeek-V4-Pro，以及总参数量 284B（激活 13B）的 DeepSeek-V4-Flash，两者均支持长达 一百万 token 的上下文。

DeepSeek-V4 系列在架构与优化方面引入了多项关键升级：

1. 混合注意力架构：我们设计了一种结合压缩稀疏注意力（CSA）与重度压缩注意力（HCA）的混合注意力机制，大幅提升长上下文处理效率。在 1M token 上下文设定下，DeepSeek-V4-Pro 的单 token 推理 FLOPs 仅为 DeepSeek-V3.2 的 27%，KV 缓存仅占其 10%。
2. 流形约束超连接（mHC）：我们引入 mHC 来增强传统的残差连接，在保留模型表达能力的同时，提升信号跨层传播的稳定性。
3. Muon 优化器：我们采用 Muon 优化器以实现更快的收敛速度和更高的训练稳定性。

两款模型均在大于 32T 的多样化高质量 token 上进行了预训练，并随后执行了全面的后训练流程。后训练采用两阶段范式：首先独立培养领域专属专家（通过 SFT 与基于 GRPO 的强化学习），随后通过 on-policy 蒸馏将不同领域的专长整合至单一模型中。

DeepSeek-V4-Pro-Max 作

编码智能体的核心组件——编码智能体如何借助工具、记忆与仓库上下文，让大语言模型在实际应用中更高效

Sebastian Raschka 博士 2026年4月4日

本文将讲解编码智能体与智能体框架的整体设计：它们是什么、如何工作，以及各模块在实际中如何协同。读过我《从零构建大语言模型》《从零构建推理模型》两本书的读者经常问到智能体相关问题，因此我整理了这份可直接参考的说明。

总体而言，智能体之所以成为重要议题，是因为当下大语言模型实用系统的进步，不只在于模型本身更强，更在于我们如何使用模型。在许多真实场景中，模型外围的系统——如工具调用、上下文管理、记忆机制——与模型本身同等重要。这也解释了为何 Claude Code、Codex 这类系统，会比在普通聊天界面中使用同款模型显得能力强得多。

本文将拆解编码智能体的六大核心组件。

Claude Code、Codex CLI 与其他编码智能体

你大概率熟悉 Claude Code 或 Codex CLI，简单来说，它们本质是智能体式编码工具：在大语言模型外层封装一层应用层（即智能体框架），让编码任务更便捷、性能更优。

编码智能体专为软件工程场景设计，其关键不只在于模型选择，更在于外围系统：仓库上下文、工具设计、提示词缓存稳定性、记忆能力、长会话连续性。

这个区分很重要，因为人们谈论大语言模型的编码能力时，常把模型、推理行为、智能体产品混为一谈。

Harness 工程：给 AI 智能体一个"可靠的家"

想象一下，你有一个非常聪明但有点冲动的助手——它知识渊博、能说会道，但有时候会：

• 忘记五分钟前你们讨论的事情
• 直接执行危险操作而不问你
• 在复杂任务中迷路，绕来绕去
• 做错了事，但你不知道为什么

这就是没有 Harness 的 LLM 智能体。

什么是 Harness？

Harness 这个词在英文里有"马具"、"安全带"的意思。在 AI 智能体的世界里，它就是那个让智能体既能够发挥能力，又不会失控的"安全脚手架"。

这个隐喻是有意的：

• 马是 AI 模型——强大、快速，但它自己不知道去哪里
• Harness是基础设施——约束、护栏、反馈循环，以富有成效地引导模型的力量
• 骑手是人类工程师——提供方向，而不是亲自奔跑

用一个更贴近生活的比喻：Harness 就像是智能体的"驾驶舱 + 安全带 + 导航系统 + 黑匣子"的组合体。

根据 Harness Engineering 将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。

真实故事：Harness 工程的威力

在我们深入技术细节之前，让我们看看几个真实的例子，了解为什么 Harness 工程如此重要：

WikiLLM

利用 LLM 构建个人知识库的系统。WikiLLM 将原始素材"编译"成结构化、交叉链接的高质量中文 Wiki，可在 Obsidian 中查看。

本项目基于 Andrej Karpathy 提出的理念构建。详见：LLM Knowledge Bases

项目概述

WikiLLM 的工作流包括：

1. 数据摄入：源文档（文章、论文、代码库、数据集、图像）被索引到 raw/ 目录
2. Wiki 编译：LLM 增量地"编译"原始数据成 markdown 文件的 wiki，包含摘要、反向链接、分类概念和相互链接的文章
3. IDE：Obsidian 用作前端查看原始数据、编译后的 wiki 和可视化
4. 问答：LLM 可以通过研究相关数据来回答针对 wiki 的复杂问题
5. 输出：结果渲染为 markdown 文件、Marp 幻灯片或 matplotlib 图像，可在 Obsidian 中查看
6. Linting：LLM"健康检查"发现不一致、填补缺失数据、建议新文章候选
7. 额外工具：诸如 wiki 上的朴素搜索引擎等额外工具

核心原则

• LLM 编写和维护所有 wiki 数据；手动编辑很少见
• 用户探索和查询被归档回 wiki 以增强它
• 系统专注于 markdown 文件和 Obsidian 兼容格式
• 图像被下载到本地 以便 LLM 轻松引用

目录结构

• LLM Knowledge Bases

最近我发现一个非常实用的方法：利用大语言模型（LLM）为各类感兴趣的研究方向搭建个人知识库。这样一来，我近期消耗的模型令牌中，用于处理代码的占比大幅减少，更多被用于处理知识（以 Markdown 文件和图片形式存储）。最新的大语言模型在这方面表现十分出色。具体做法如下：

数据导入

我先将各类源文件（文章、论文、代码仓库、数据集、图片等）归档到 raw/ 目录下，再通过大语言模型逐步“编译”生成一份知识库，这份知识库本质就是按目录结构组织的一系列 .md 文件。 知识库会包含 raw/ 目录下所有数据的摘要、反向链接，还会将数据按概念分类、撰写对应词条并完成相互关联。 为把网页文章转为 .md 文件，我习惯使用 Obsidian 网页剪藏插件，同时通过快捷键将相关图片批量下载到本地，方便大语言模型直接调用。

集成开发环境

我把 Obsidian 当作前端 IDE，既能查看原始数据、编译后的知识库，也能查看衍生的可视化内容。 需要重点说明的是：整个知识库的内容撰写与维护均由大语言模型完成，我几乎不直接手动修改。我还试用过多款 Obsidian 插件，以其他形式渲染和查看数据（比如用 Marp 制作幻灯片）。

问答交互 真正有意思的是，当知识库规模足够大时（比如我近期的研究知识库已有约 100 篇词条、40 万字），就可以向大语言模型智能体提出各类复杂问题