Claude code设计 背景 claude code具体是干什么的就不用跟大家说了： 那我们从工程的角度去拆解他： 其产品本质可以理解为： CLI/TUI 外壳 -> 输入编译器 -> 多轮 Agent Loop -> 模型调用适配层 -> 工具执行器 -> Hook/Permission -> Session/Transcript/Plan/FileHistory 设计进化 我们从chatbot到真正的agent就是有了工具调用！ 但是工具调用又会带来一些问题： 工具注册与发现：谁来管理工具的注册表？如何让模型知道有哪些工具可用？如何在不重启系统的情况下动态添加新工具？ 参数校验：谁来校验工具调用的参数？模型可能传递错误类型的参数、缺少必填字段、或传入超出范围的值。校验逻辑放在哪一层？ 权限管控：谁来决定某个工具调用是否应该被执行？模型可能要求执行 rm -rf /，这显然不应该被允许。但有些操作在特定上下文中是安全的——如何平衡安全性与效率？ 错误恢复：工具执行可能失败，API 调用可能超时，LLM 的输出可能不符合预期格式。每一种错误场景 ...

对话循环 异步生成器 Claude Code 的对话主循环是一个以 async function* 定义的异步生成器。它不是一次性执行完毕的普通函数，而是一个可暂停、可恢复、可取消的"活"的流程。每一次 yield 就像心跳的一次搏动，将流式事件推向调用方。 这个设计选择值得用更多篇幅来理解。在传统的编程模型中，函数调用是同步的：调用者发起请求，被调用者执行计算，返回结果。但 Agent 的交互模式打破了这种同步假设——模型可能需要几十秒才能完成一次响应，而且响应是逐 token 到达的；工具执行可能耗时数分钟，期间需要实时反馈进度；用户可能随时中断操作，要求立即停止。 面对这些需求，传统的函数调用模型力不从心。异步生成器提供了完美的答案：它像一个可以随时暂停和恢复的"协程"，在"生产者"（对话循环）和"消费者"（UI 渲染层）之间建立了一条实时的事件管道。 整个对话循环的入口是一个导出的异步生成器函数，它接受一个参数对象，可向外产出五种类型的事件（流式事件、请求开始事件、消息、墓碑消息、工具调用摘要）， ...

架构设计 openclaw最近也是非常火爆啊，作为一个这么优秀的智能体来说，我们最关注的就这个agent的上下文和记忆系统是怎么去设计的！ 记忆 openclaw设计最好的就是他的记忆完全是由markdown去做的，AI更好的适配Markdown。 主要是有长期记忆和会话记忆组成： Memory.md：这里是用户的个性记忆，比如喜好，编码记忆等等，其实就是我们coding agent里面的AGENT.MD 一样,这部分记忆是不会被压缩的 会话记忆：是根据会话sessionID来的，一个session里面包含多个时间的文件夹记忆，这里面详细写了Openclaw的执行过程。然后这部分记忆是进行压缩的时候进行写入的 举例： 123456789101112# 核心记忆与设定## 用户偏好 (User Preferences)* 偏好使用 `pnpm` 而不是 `npm` 或 `yarn`。* 极其讨厌在代码里留 `console.log`，提交代码前必须清理。## 项目架构准则 (Project Directives)* **数据库连接:** 这个项目使用的是 TiDB，所有的数据库查询超 ...

背景 在人工智能走向自主智能体（AI Agents）的进程中，2026年标志着一个关键的转折点。过去，行业的焦点集中在提升大语言模型（LLM）的参数量和推理能力上；但如今，瓶颈已经发生了转移——AI智能体生成代码和解决方案的速度，已经远远超过了人类团队能够验证其安全性和正确性的速度。 “Harness工程”最先由业界从2025年底开始提出。它着眼于为AI智能体提供一个完整的运行环境和工作流，使模型使用工具、执行多步任务，真正“做实事 如果一个演示系统有 90% 的成功率，这仅仅是完成了“第一个九”。在实际生产中，一个包含10个步骤的 Agentic Workflow 如果每步只有 90% 的可靠性，那么它每天会失败超过6次。仅靠提示词工程（Prompt Engineering）根本无法达到生产级别的稳定性。 就是说 真正卡你的不是 Agent 写代码的能力，而是围绕它的结构、工具和反馈机制跟不上 不是我们模型的能力限制，是你没准备好给他一个适于写代码的环境！ 所以我们的Harness Engineering就是相当于汽车的壳子，模型相当于我们的发动机！ 在OpenAI的定义中，harn ...

核心设计 标准 RAG 系统核心模块 我们将 RAG 系统分为数据准备流 (Offline) 和 查询处理流 (Online) 两大支柱模块： A. 数据准备模块 (Data Ingestion Pipeline) 这是系统的“知识预处理厂”，负责将非结构化数据转化为机器可理解的格式。 加载器 (Document Loaders)：对接多种数据源（PDF, Notion, Confluence, SQL）。 清洗与转换 (Clean & Transform)：去除噪声（如 HTML 标签）、处理特殊字符。 分块策略 (Chunking Strategy)：将长文拆分为固定长度或语义段落，通常带有重叠部分（Overlap）以保持上下文连贯性。 向量化 (Embedding)：利用 $BGE$、$text-embedding-3$ 等模型将文本块转化为高维向量。 存储 (Vector Storage)：存入向量数据库（如 Milvus, Pinecone, ElasticSearch），并附带元数据（Metadata）以便后续过滤。 B. 核心功能组件 检索器 (Retr ...

基本概念 1.工作流 (Workflow) 与 Agent 的异同 Workflow（工作流）： 在 Java 生态中，Workflow 的本质是有限状态机 (FSM) 的高级抽象。无论是传统的 Activiti/Flowable，还是现代的分布式工作流引擎 Temporal，其核心逻辑都是预定义的。 技术本质：它是 Graph-based 的。开发者在编码阶段就定义好了 $Next = f(State, Input)$。 工程优势： 幂等性与重试机制：由于路径确定，我们可以轻松实现节点级别的事务回滚（Saga 模式）或断点续传。 可观测性：每一个 State 的流转都在数据库中有明确记录，审计和排障极其简单。 Java 类比：就像是一个严谨的 Switch-Case 逻辑或 Chain of Responsibility（责任链模式），虽然复杂，但永远在控制之中。 然后比如我们常用的langgraph，Spring AI alibaba graph这些都是基于工作流的。是智能体早期的一个实现。就是相当于把AI作为我们平常链路的一个部分，去调用了下API做推理的任务 然后在工 ...

1. 引言：理解大模型交互的本质 在实际业务场景中，与大语言模型（LLM）的交互，本质上是基于无状态API调用的概率推断过程。由于模型具有发散性思维，如果我们仅提供简单的指令，往往会得到非结构化的长文本、低质量的发散性内容，甚至是“模型幻觉”（Hallucination）。 为了让AI在逻辑推理、内容生产和信息提取等业务流中稳定发挥作用，我们必须通过工程化的手段来约束其输出。提示词（Prompt）就是我们控制大模型输出格式、规范业务逻辑、处理异常边界的核心工具。 2. 提示词的二元结构解析 为了让AI准确理解并执行任务，我们在工程上通常将提示词划分为两个核心层级，它们在模型的注意力权重和功能定位上截然不同： 系统提示词（System Prompt）：定规矩（高权重） 这是智能体的“底层操作系统”。它具有全局最高权重，负责定义AI的角色设定、思维链路（CoT）、可用工具集、硬性规则约束以及异常处理的兜底机制。 用户提示词（User Prompt）：派任务（动态权重） 这是具体的“业务工单”。它结合历史上下文（Memory），告诉AI当前具体的业务诉求是什么、执行任务所需的背景数据在哪里 ...

背景 之前的文章介绍了提示词该怎么去写？具体的系统提示词应该包含什么部分，这一期我们来讲一下提示词该怎么去写！AI的回复的效果更好！这也是我们上下文去管理的一个好的办法。 你的提⽰词，就是模型做预测的全部依据。 它设定了预测路径的起点和⽅向。写得越精确、信息越丰富、结构越清晰，模型⾛上⾼质量路径的概率就越⼤。写得越模糊，模型就越会滑向最泛化的统计均值，产出⼀段正确但毫⽆洞察⼒的废话。 我们提示词的骨架就主要是： 在什么背景下做（Context）、具体做什么（Task）、产出⻓什么样（Format） Context: 这部分就是我们俗称的上下文工程的部分！ 提供上下⽂就是在压缩模型的猜测空间。你交代的背景越多，它需要⾃⾏发挥的余地就越⼩，输出也就越精准。 要有意识地检查⼏个维度。你是谁或让 AI 扮演谁：⼀个"资深安全⼯程师"和⼀个"初级开发者"⾯对同⼀段代码，分析的视⻆和深度完全不同。受众是谁：同⼀份技术⽅案，写给⼯程师看和写给不懂技术的⾼管看，语⾔和侧重截然不同。为什么要做：⽬的决定取舍，"总结这份合同"有⼀百种总结法，&q ...

待思考： 什么是Skills？ 他的好处？为什么这么设计？跟我们直接将提示词按文件划分有什么区别 渐进式披露在skills上怎么体现的，有什么好处？ skills的拆分，我如何确定一个东西可以作为一个skills 然后我提示词命中了多个skills怎么处理？ 跟skills绑定的工具我怎么处理?怎么去按需加载 1.什么是skills？ 在 AI 架构（特别是类似 Semantic Kernel 或各类 Agent 框架）中，Skill（技能/插件）是一个封装了特定领域能力的独立模块。它不仅仅是一段提示词，它是**“意图（Prompt）+ 动作（代码/工具/API）+ 数据结构（输入/输出 schema）”**的集合体。 一个比较完整的 Skill 往往包含： 意图描述：它解决什么问题（适用范围），不解决什么（边界） 触发信号：什么样的用户请求应该命中它（关键词/语义/结构） 工作流程：步骤化 SOP（先做什么、再做什么、失败怎么办） 输入输出契约：需要哪些输入、输出长什么样（模板/字段/格式） 工具策略：需要哪些工具、何时用、参数怎么填、如何校验结果 质量控制：检查清单（自检点） ...

工作流解析 整体工作流的流程图: 123456789101112131415161718192021222324252627flowchart TD A[IntentRecognition] -->|数据分析| B[EvidenceRecall] A -->|闲聊/无关| Z[END] B --> C[QueryEnhance] C --> D[SchemaRecall] D --> E[TableRelation] E --> F[FeasibilityAssessment] F -->|数据分析| G[Planner] F -->|非数据分析| Z G --> H[PlanExecutor] H -->|SQL| I[SqlGenerate] H -->|PYTHON| M[PythonGenerate] H -->|REPORT| R[ReportGenerator] H -->|HumanReview| K[HumanFeedback] K -->|approve| ...

📑 目录 #1-项目概览 #2-核心竞争力分析 #3-技术架构深度解析 #4-性能基准测试详解 #5-jsonb-二进制格式详解 #6-jsonpath-高级用法 #7-feature-系统完全指南 #8-安全性设计与最佳实践 #9-框架集成指南 #10-实战代码示例 #11-性能优化技巧 #12-从其他库迁移指南 #13-常见问题解答 #14-与竞品对比 #15-总结与建议 项目概览 1.1 基本信息 FASTJSON 2 是阿里巴巴开源的新一代高性能 JSON 处理库，是 FASTJSON 1.x 的重大升级版本。 项目名称：FASTJSON2 当前版本：2.0.61 开发语言：Java 最低要求：JDK 8+ 许可协议：Apache License 2.0 代码规模：468 个核心文件，7.2MB 测试覆盖：3421 个测试文件 提交历史：5953 次提交 文档数量：190 份 Markdown 文档 1.2 设计目标 FASTJSON2 的设计目标是为未来十年提供极致优化的 JSON 库： 极致性能 - 相比 1.x 提升 2-3 倍，远超竞品 功能完整 - 支持 ...