该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/biny-agent-memory-system

{
  "topic": "Agent 工具系统",
  "goal": "修复工具调用超时与重复执行",
  "objects": ["ToolExecutionCoordinator", "ToolSearch"],
  "conclusions": ["超时取消逻辑需要统一"],
  "followUp": { "what": "补充集成测试", "quote": "用户要求完成后执行完整验收" }
}

brief         这个项目是什么
focus         当前正在处理什么
threads       相关的会话列表

SELECT
  memory_id,
  1 - vec_distance_cosine(embedding, ?) AS score
FROM memory_embeddings
WHERE score >= ?
ORDER BY score DESC
LIMIT ?;

14:05  VS Code     打开 memoryStorage.ts
14:16  Terminal    运行 memory 测试
14:32  浏览器      查看 SQLite 文档

这篇按术语逐项解释常见的 AI Agent 概念。先看每项的简短说明，想了解完整流程、例子和边界，再进入对应专题。

协议与工具

Skill： 可复用的任务知识、流程与资源包。它告诉 Agent 一类事情应该怎么做，通常以 SKILL.md 为核心，还可以带脚本、模板和参考资料。比如代码审查 Skill 规定先看改动目标，再查影响、验证并输出报告。真正读文件和跑测试，仍需要工具。

MCP： Model Context Protocol，模型上下文协议，统一 AI 应用接入外部工具和资料的方式。比如把 GitHub 查询能力接到 Agent 应用里。MCP Server 可以提供工具、可读取的资源和提示模板；应用负责连接、发现和路由调用。

ACP： 这里指 Agent Client Protocol，Agent 客户端协议，连接编辑器等客户端与 Agent。客户端发送用户任务，Agent 返回进度、工具操作和权限请求。比如在一个编辑器里使用不同编码 Agent。看到 ACP 时先确认全称，因为也有其他同名缩写。

A2A： Agent2Agent，让调用方与远程 Agent 服务交换任务、状态和交付物。比如把一项资料调查交给远程 Agent，再取得报告。MCP 侧重接入工具和资料，ACP 侧重客户端交互，A2A 侧重远程 Agent 的任务互操作。

LSP： Language Server Protocol，语言服务器协议，提供代码定义、引用、类型、补全和错误诊断等语言服务。文本搜索能找到同名字符串，LSP 可以帮助确定某处引用究竟指向哪个定义。

DAP： Debug Adapter Protocol，调试适配器协议，提供断点、单步、变量和调用栈等调试能力。LSP 帮助理解代码，DAP 帮助观察程序运行过程。

Tool： 工具，是 Agent 可以使用的一项具体操作能力，比如读文件、查数据库、运行命令或操作浏览器。模型通过工具取得外部信息，或让外面的程序执行真实动作。

Tool Call： 工具调用，是使用某个工具的一次具体请求。read_file 是工具，读取 /repo/login.ts 是一次 Tool Call。调用请求、工具执行结果和用户任务完成，是不同状态。

Function Calling： 函数调用机制，让模型用结构化格式表达「调用哪个函数、传什么参数」。通常由应用执行函数，再把结果交回模型；托管工具则由提供方执行相应操作。它负责表达调用，MCP 负责一种外部能力接入方式。

JSON Schema： 描述数据需要具备哪些字段、类型和约束。例如工具参数里的 path 必须是字符串。程序按 Schema 校验，可以发现格式问题，但还要另行检查路径是否存在、是否允许访问。

Structured Output： 结构化输出，让模型按照约定结构生成数据，例如把审查结果输出成一个问题数组。它方便程序处理，格式符合要求之后，事实和业务条件仍需验证。

Tool Search： 工具搜索，从较多工具中寻找当前任务需要的能力，再加载相关定义。比如当前只需要查工单，就先找到工单查询工具，减少无关工具说明进入上下文。

Progressive Disclosure： 渐进式披露，先给名称和简介，需要时再加载完整说明和附件。读 Skill 时可以先看目录，确定相关后再读正文。Lazy Loading、Deferred Loading 也涉及按需或延后加载，但要确认延迟的是文档、工具定义、连接还是进程。

Code Mode： 让模型先写程序，再由执行环境运行程序，用循环、条件、筛选和聚合组织工具调用。比如一段代码查询多个项目，只返回高优先级工单。它可能减少模型往返和中间数据，但也需要处理代码错误、权限和执行状态。

PTC： Programmatic Tool Calling，程序化工具调用，用程序组织工具操作的相关思路，也可能特指某家提供方的实现。理解时要继续看程序在哪里运行、怎样调用宿主工具、哪些结果回到模型。

Plugin / Extension： 插件或扩展，用来安装和分发附加能力。一个插件可以同时包含 Skill、工具连接配置、命令或 Hook。Hook 在特定事件触发逻辑，Command 则提供显式命令入口。

Agent 与工作流

Agent： 在本系列的 LLM 应用语境中，指围绕目标，根据任务与反馈选择行动、使用工具并推进工作的系统。比如发现测试失败后，自行查日志、定位原因、修改并重新验证。模型负责判断，外围程序负责执行和状态管理。

Workflow： 工作流，预先组织步骤与分支。比如「解析文档 → 检索 → 生成 → 校验」。Agent 更侧重根据反馈动态决定下一步；实际系统经常把工作流与 Agent 组合使用。

模型与推理

LLM： Large Language Model，大语言模型，用于理解输入和生成内容。它可以生成文字、代码和工具参数。聊天产品通常还包含工具、历史存储和执行程序，产品与模型不是同一个对象。

Token： 模型处理文本时使用的单位，不固定等于一个汉字、单词或字符。Tokenizer 负责文本与 Token 编号之间的转换，Input Tokens 和 Output Tokens 分别描述输入、输出的计量。

Context Window： 上下文窗口，一次模型调用可容纳的上下文范围。容量大不代表其中的信息都能被有效利用；输入、输出和推理预算怎样计算，应看对应接口。

Inference / Reasoning： Inference 指运行已训练的模型来计算输出；Reasoning 更强调分析和逻辑推导。两者都可能译成「推理」，但普通回答也会执行 Inference，不一定涉及复杂 Reasoning。

Prefill / Decode： Prefill 处理已有输入，Decode 逐步生成后续 Token。长输入和长输出带来的耗时可能发生在不同阶段；Streaming 则把内容或事件逐段返回，提供更早的反馈。

Temperature / Top p / Top k： 控制生成采样的参数，影响候选 Token 的分布和选择范围。低 Temperature 不保证答案正确；生成采样的 Top k 与检索返回数量 Top K，属于不同环节。

Fine-tuning： 微调，通过训练调整模型参数来适应任务或数据。SFT、偏好优化等涉及训练方法，LoRA 是参数高效适配的一种方法。读 Skill、查 RAG、保存记忆通常属于运行时信息组织，没有直接更新模型权重。

上下文与记忆

Prompt： 当前任务的指令与输入，有些语境也泛指整份模型输入。例如「只根据这份文档回答，资料没有提到的内容标为未知」。Prompt Engineering 关注怎样把目标、例子、约束和输出要求写清楚。

Context： 上下文，本次模型调用实际可用的信息，可能包括用户问题、历史、工具定义、工具结果、检索资料和记忆。信息保存在系统里，不代表这次一定交给了模型。

History： 历史交互记录，例如过去的用户消息、模型回答和工具结果。界面显示的历史可以比本次模型输入更多，系统通常需要选择、裁剪或压缩后再发送。

Memory： 记忆，为后续任务保留和使用的信息，例如用户偏好、项目约束和过去的经验。它可以存在文件或数据库里，不一定要用向量库。保存之后，还需要按作用域检索、处理冲突和检查时效。

Context Engineering： 上下文工程，管理什么信息、在什么时候、以什么形式进入模型。例如把完整日志放到文件里，先提供失败摘要和读取入口，让模型需要时再查细节。

Compaction： 上下文压缩，把较长历史整理成继续工作所需的材料。应保留目标、约束、进度、决定和验证结果。它可能丢失细节，摘要也不能替代已经变化的文件和真实业务状态。

检索与 RAG

RAG： Retrieval-Augmented Generation，检索增强生成，先获取外部依据，再结合依据回答。比如先检索公司的最新报销制度，再解释额度。完整链路包括资料准备、检索、排序、证据组织、生成与核查。

Chunking： 分块，把资料切成适合检索和放入上下文的片段。块太小可能丢掉条件，块太大可能混入无关内容。例如「500 元」应尽量保留城市、日期和适用范围。

Embedding： 嵌入，把文本、图片等内容转成数值表示，供检索等任务比较。语义向量可以帮助找到字面不同但含义接近的内容，不过向量相似不证明它能回答问题。

BM25： 常见的关键词相关性评分方法，利用词项匹配、词频和文档长度等信号。错误码、文件编号、函数名等精确术语，往往需要这类匹配能力。

Vector Database / ANN： 向量数据库提供向量存储、索引和查询等能力；ANN 是近似最近邻搜索，以一定近似换取速度和资源收益。HNSW、IVF、PQ 是相关索引与压缩方法，主要解决检索效率问题。

Hybrid Search： 混合检索，结合关键词、向量等多种检索方法。比如一边匹配制度编号，一边理解「住酒店能报多少」的含义，再合并候选。

RRF： Reciprocal Rank Fusion，倒数排名融合，利用文档在不同结果列表里的名次合并排序，避免直接比较不同尺度的原始分数。它汇总排名信号，不直接判断内容是否正确。

Reranker： 重排器，对已经召回的候选做更细的相关性判断并重新排序。Cross-Encoder 是一种常见模型形式，会联合处理问题与候选内容。正确资料没有进入候选集时，重排无法把它找回来。

Grounding / Citation： Grounding 要求具体说法由证据支持，Citation 标明来源。链接存在之后，还要确认来源支持对应说法，包含当前日期和适用条件。证据不足时可以明确无法确认，这叫 Abstention。

GraphRAG： 利用图结构辅助检索与生成的一类方法。知识图谱组织实体及其关系；微软 GraphRAG 是一个具体实现，还涉及社区报告等索引。使用图数据库，不自动等于实现了该系统。

Agentic RAG： 让 Agent 参与决定是否检索、查哪里、怎样改写问题、是否继续，以及证据是否足够。查到旧制度后继续寻找新版本，是一个简单例子。Self-RAG、Corrective RAG 则有各自的研究机制，不能仅凭名称视为同一种方法。

运行与状态

Agent Loop： Agent 的控制循环，准备上下文、调用模型、执行工具、取得观察，再决定继续、等待或结束。一次模型生成结束，不代表整个任务已经完成。

ReAct： Reasoning 与 Acting，强调判断和行动交替推进。比如原先怀疑网络故障，读日志后发现数据库权限错误，随后调整排查方向。它与前端 UI 库 React 是不同概念。

Engineering Loop： 工程闭环，从目标和验收标准出发，实施变更、获取真实反馈、根据反馈修正并交付。测试、业务状态和界面检查可以提供反馈。不断修改却从不验证，闭环就缺少重要一环。

Runtime： 运行环境。语言 Runtime 可以指 Node.js、Python 等环境；Agent Runtime 则承载 Agent 循环、工具执行、状态和生命周期。具体可以是库、服务或多个组件。

Harness： 围绕模型组织执行与反馈的外围机制，常涉及指令、工具接口、上下文、调度、权限、恢复和验收。Harness Engineering 关注怎样让这些部分配合，使任务能够持续、正确、可验证地推进。它与 Runtime 的范围有重叠。

Session / Turn / Run： Session 是带标识的交互或执行上下文，Turn 是一轮交互，Run 是一次运行实例，具体边界依系统定义。Process 是操作系统进程，一个进程可以服务多个 Session，一个 Run 也可以启动多个工具进程。

State： 状态，记录任务或系统现在处于什么阶段，例如运行中、等待输入、失败或完成。判断某类事实时，以对应的 Source of Truth，也就是权威记录为准；工单是否存在，应核对工单系统。

Persistence / Checkpoint： Persistence 是持久化，让进程退出后数据仍可读取；Checkpoint 是保存从某个边界恢复所需的状态。保存聊天历史不等于保存了完整工具进度，也不保证能从任意一行代码继续。

Resume / Reconnect： Resume 从可恢复边界继续工作，Reconnect 恢复通信连接。界面重新连接成功，不代表后台任务重新执行，也不代表恢复机制完整。

Retry / Idempotency： Retry 是重试，Idempotency 是幂等性，在约定范围内重复同一请求，其预期业务效果与执行一次相同。超时不证明操作未成功；响应丢失后可以先核对真实状态，再决定是否重试。

协作与界面

Multi-agent / Subagent： Multi-agent 是多个 Agent 协作，Subagent 是被委派子任务的 Agent。它们可以分工、独立审查或并行处理，但需要明确上下文、文件责任和结果汇总方式；数量增加也会增加协调成本。

Handoff： 把控制权交给另一个 Agent，例如客服把后续处理移交给退款 Agent。让子 Agent 返回一份报告则通常属于 Agent-as-a-Tool，主 Agent 收到结果后继续负责，交互语义不同。

Computer Use / ACI： Computer Use 是通过工具观察和操作电脑界面的能力，可利用 DOM、可访问性树、截图和鼠标键盘。ACI 是 Agent 与计算机的交互接口设计，关注观察和操作怎样帮助模型完成任务。点击保存之后，还要确认真实保存结果。

缓存与观测

Cache Hit： 缓存命中，找到满足复用条件的计算状态或结果。它可能命中输入前缀计算、完整答案、工具结果或工具目录，必须先说明缓存对象。命中率高不自动证明整个任务更快。

KV Cache： 保存注意力计算中的 Key、Value 表示，让自回归模型生成后续 Token 时复用已有计算。这里的 KV 是模型中间表示，不是保存用户偏好的长期记忆数据库。

Prompt Cache / Response Cache： Prompt Cache 通常复用符合条件的稳定输入前缀计算，模型仍生成新输出；Response Cache 复用完整回答。前缀命中缓存后，里面的信息仍计入逻辑上下文，不会扩大上下文窗口。

Trace / Logs / Metrics： Trace 关联一次过程中的多个操作，Span 描述其中一段操作；Logs 记录离散事件，Metrics 汇总数量和分布。它们帮助判断哪里慢、哪里失败，持久恢复仍需要另外的状态与执行机制。

Latency / TTFT： Latency 是从指定起点到终点的耗时，TTFT 是首 Token 延迟，端到端延迟则看任务提交到完成的总时间。首字出现得快，后面的工具和外部任务仍可能让总时间很长。

安全与评测

Sandbox / Approval： Sandbox 限制代码能接触的资源；Approval 确认这次具体动作是否获准。Authentication 确认身份，Authorization 确认可执行范围。这几层需要配合，连接工具或读到 Skill 不会自动授予额外权限。

Prompt Injection： 提示注入，用输入或外部资料中的指令诱导 Agent 偏离任务或越权。例如网页要求读取密钥，这仍是网页内容，不能自行变成用户授权。Trust Boundary，信任边界，规定不同来源的信息具有怎样的权威。

Test / Eval / Verifier： Test 检查系统行为，Eval 评估一组任务上的表现，Verifier 检查当前结果是否达到验收要求。Agent 说「创建成功」之后，应核对目标对象是否正确存在；测试通过也要说明覆盖了哪些行为。

Acceptance Criteria： 验收标准，明确什么结果才算完成。比如登录修复要求正确凭据通过、错误凭据被拒绝、旧登录方式仍兼容。Spec 描述预期行为与约束，PRD 描述用户、问题、范围和目标。

Baseline / Ablation： Baseline 是比较基线，Ablation 是消融，通过去掉或替换一个机制检查它的贡献。比如用同一查询集比较有无重排，才能判断新增 Reranker 是否带来收益。

想继续看已有文章，可以读 MCP 和 Skill，到底是什么关系？、RRF 排序融合和 怎么减少大模型幻觉？。各专题附官方规范、项目文档和原始论文。

返回总览 · 本篇讨论模型本身，工具接入见 下一篇。

让 Agent「读报错、改代码、跑测试」，其中理解报错和生成修改建议的，通常是语言模型；真正读取文件和运行测试的，是外围程序。

这一篇先把模型这一层的词讲清楚。我们用「给模型一段报错，让它分析原因」这个简单场景，贯穿输入、生成和训练。

LLM、Model、Weights，先分清模型和产品

LLM，全称 Large Language Model，是大语言模型。 常见自回归语言模型根据已有内容，逐步生成接下来的 Token。生成结果可以是解释、代码或工具参数。

Model 是训练得到的计算模型；Parameters / Weights 是模型内部的参数和权重。它们不是你在请求里填写的 temperature、输出上限等配置参数。

聊天产品还包括界面、模型请求、工具、账户、历史存储等部分。换一个聊天界面不等于换模型；同一个模型搭配不同工具和上下文，完成任务的表现也可能不同。

这个区别很实用。Agent 查不到文件时，原因可能是根本没有文件工具；补上工具不需要重新训练模型。

Token，模型怎样计算输入和输出

Token 是模型处理文本时使用的单位。Tokenizer 是文本与 Token 编号之间的转换器。 一段中文、英文、代码会怎样切分，要看具体 Tokenizer，不能统一按字符数换算。

报错只有十行，不代表输入只有十行。应用可能还带上几百条历史消息和大量工具定义。

上下文窗口足够大，也不能保证所有信息都被有效利用。相关内容被无关日志包围时，仍可能影响判断。具体怎样整理信息，见 上下文专题。

文本生成及输入编码可参考 Hugging Face 的 Text generation 文档。

Inference 和 Reasoning，为什么都译成推理

Inference 指使用已经训练好的模型计算输出。Reasoning 更强调多步分析和逻辑推导。

模型回答「你好」也做了一次 Inference，但通常不需要复杂 Reasoning。排查一个跨服务故障，则可能需要比较多个假设。

一次自回归生成常分为 Prefill，预填充 和 Decode，解码生成。前者处理已有输入，后者逐步生成后续 Token。

给模型一大份日志，可能增加输入处理开销；让模型写一份很长的报告，可能增加生成开销。两者都让人感觉「慢」，却不发生在同一阶段。

Streaming，流式输出，把内容或事件逐段返回。它改善等待时的反馈，但不自动减少整个任务的总耗时。

Temperature、Top p、Top k，控制的是采样

模型生成下一步内容时，会对候选 Token 给出概率等信号，再按照生成策略选择。

Temperature 调整分布的集中或分散程度。较低设置通常让采样更集中；较高设置可能增加变化。它不能把错误知识改成正确知识。

Top p 按累计概率保留一组候选；Top k 保留概率最高的 K 个候选。这两个 K 和检索中「取前 K 篇文档」的 K，处在不同环节。

Seed 控制部分随机过程。相同 Seed 并不保证模型版本、计算环境和所有服务行为变化后还能完全复现。

下面三个限制也要分开。

一次生成结束之后，Agent 可能还需要运行工具、再发起下一次生成。所以看到 Stop Reason，不能直接认定用户任务已完成。

多模态和 VLM，能看和能生成要分别确认

Multimodal，多模态，表示系统支持不止一种信息模态，例如文字、图片、音频。

VLM，Vision-Language Model，视觉语言模型，可以结合图像与文字理解内容。例如根据截图指出保存按钮的位置。

支持图片输入，不自动表示支持图片输出；能读截图，也不自动表示能够操作电脑。点击需要工具，点击之后的业务结果还要检查。

预训练、后训练和微调，改变模型参数

Pretraining，预训练，通常从大量数据中学习基础能力。Post-training，后训练，继续调整指令遵循、偏好或推理等能力。它是较宽的阶段称呼，不等于某一种算法。

Fine-tuning，微调，通过训练调整参数，让模型适应任务或数据。它可以发生在后训练体系中。

这些名字并不是一条必须依次走完的流水线。DPO 与某种 RLHF 流程可以是不同方案；LoRA 描述参数怎样适配，可以与不同训练目标组合。TRL 文档介绍了多个训练方法，PEFT 的 LoRA 文档解释了低秩适配。

给提示词、读 Skill、查 RAG，通常没有重新训练

如果你把「请只根据日志回答」写进输入，模型的行为可能发生变化，但通常没有更新权重。

In-context Learning，上下文学习，指模型通过当前输入的说明和示例适应任务。Zero-shot 不提供任务示例；Few-shot 给少量示例，比如先展示两组规范的报错分析。

读取 Skill、检索文档、把旧经验放进上下文，也通常属于运行时信息组织。它们能让模型拿到更好的依据，却不是微调。

要记住最新接口文档，RAG 常是资料检索这一层的方案；要让某种任务行为稳定下来，则可能涉及提示词、流程、评测，甚至训练。选择方案前，先确认缺的是知识、方法、工具还是模型能力。

蒸馏、量化、MoE，各自改变什么

Distillation，蒸馏，让学生模型学习教师模型的行为。目标可能是保留部分能力，同时减少资源需求；效果要对任务实测。

Quantization，量化，降低部分数值表示的精度，减少存储或计算资源需求。不同精度和实现对效果、速度的影响不同，不能直接说「位数减半，速度就翻倍」。

MoE，Mixture of Experts，混合专家模型，在模型内部使用多个专家模块与路由机制。这里的专家是神经网络组件。

多 Agent 里的「代码审查专家」则是一个任务角色，可能有自己的上下文和工具。MoE 和多 Agent 属于不同层次，不能从「模型有多个专家」推断应用里运行了多个 Agent。

回到那个报错任务

报错进入 Context，Tokenizer 把输入编码为 Token；模型执行 Inference，生成分析或工具请求；工具获取新证据后，应用重新组织下一次输入。

这条链路里，读取文档通常不会改变模型权重，降低 Temperature 不能代替证据，增加输出预算不能代替工具。把三件事分清楚，就知道下一步应该调整哪一层了。

下一篇：工具、Skill 和协议怎样接起来 · 返回总览

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/ai-agent-tools-protocols

{
  "id": "call_01",
  "name": "read_file",
  "arguments": { "path": "/repo/src/login.ts" }
}

const projects = await tools.listProjects();
const groups = await Promise.all(
  projects.map(p => tools.listIssues({ projectId: p.id }))
);
const result = groups.flat()
  .filter(issue => issue.priority === "high")
  .map(issue => ({ title: issue.title, url: issue.url }));

返回总览 · 上一篇 工具与协议。

用户让 Agent 修一个 Bug。它读日志、改代码、跑测试，失败后又继续改。这种过程看起来像模型一直在工作，实际上外围程序在不断组织调用、执行工具和更新状态。

这一篇沿着任务的推进与中断，把「循环」「运行」「恢复」放在一起解释。

Chatbot、Script、Workflow、Agent

Chatbot 侧重输入与答复；Script 按程序逻辑执行；Workflow 预先安排步骤与分支；Agent 根据任务和反馈动态选择行动。

「读取文档 → 提取字段 → 校验 → 入库」可以是工作流。校验节点也能使用模型，但整体路径依然预先规定。

「排查登录失败」则可能先读代码，也可能先看日志，拿到新证据后再决定。Agentic 常用来描述这种参与决策和行动的特征，自主范围可以很小。

这是一种实用划分，实际系统经常混合使用。参考 Anthropic 的工作流与 Agent 讨论。

Agent Loop，怎样转下一轮

Agent Loop 是围绕模型、行动和观察反复执行的控制过程。

准备上下文 → 调模型 → 检查输出
                      ↓ 请求行动
                 校验并执行工具
                      ↓
                保存结果与更新状态
                      ↓
                  继续下一轮

Policy 在这里指选择行动的机制；安全领域的 Policy 又常指约束规则，要看语境。Action 是行动；Observation 是得到的观察；Environment 是能观察或影响的环境；Trajectory 是行动和观察形成的轨迹。

Step 是一步，但没有统一边界。有的实现算一次模型调用，有的算工具动作，有的算状态图节点。看到 maxSteps = 10，需要继续看它限制哪一种。

结束也有多种原因，完成、失败、取消、预算耗尽，或等待用户。不能把所有「停止」都展示成「任务完成」。

ReAct，观察真的能改变下一步

ReAct 来自 Reasoning 和 Acting，强调推理与行动交替推进。 原始论文研究了二者结合的方式。

排查登录失败时，Agent 原先怀疑网络，读取日志后发现是数据库权限，再去检查连接配置。这次观察改变了原来的方向。

ReAct 不要求把完整内部思考展示给用户。用户更需要知道采取了哪些行动，得到什么证据，结论怎样形成。

前端开发中的 React 是 UI 库，与这里的 ReAct 分开理解。

CoT、Reflection、Self-consistency、ToT

CoT，Chain of Thought，思维链，关注多步推理过程。Reflection 让模型评价自己的产出或行动。Self-consistency 采样多条推理路径，再利用最终答案的一致性选择结果。Tree of Thoughts，ToT，显式探索并评估多个候选思路。

这些研究方法都有具体机制，不是给提示词加一句「认真想想」就完整实现了。可以继续读 CoT、Self-consistency 和 ToT 原始论文。

还有一个边界，模型自我评价不能代替独立验证。「这段代码应该正确」是一种判断；测试真正通过、目标业务行为真正出现，是另一种证据。

Planner 拆计划，Executor 执行，Replanner 根据新证据修订，Critic 提出问题，Verifier 检查验收条件。这些角色可以由一个模型在不同阶段承担，也可以由不同组件承担，不必都做成独立 Agent。

Engineering Loop 和 Event Loop

Engineering Loop，工程闭环，从要求出发，实施变更，取得真实反馈，根据反馈修正，再交付。

修登录 Bug 时，验收条件可以是「正确凭据能登录，错误凭据被拒绝，既有登录方式仍正常」。只改代码没有检查，反馈就不完整。

Event Loop，事件循环，是运行时调度异步事件和回调的机制，例如 Node.js 的事件循环。for、while 是语言中的循环控制结构。

Agent Loop 控制任务，Event Loop 调度异步程序，Engineering Loop 用证据修正实现。一个程序可以同时包含它们。

Runtime、Harness、Framework、SDK

Runtime 有几个常见含义。语言 Runtime 是 Node.js、Python 等运行环境；Agent Runtime 承载循环、工具执行、状态和生命周期；与 Build-time 对比时，Runtime 指运行期间。

Harness 是围绕模型建立的执行与反馈机制，可能包含指令、接口、上下文处理、权限、调度、恢复和退出条件。与 Runtime 的范围有重叠，不应把本篇分组当成强制架构标准。长任务 Harness 的官方案例讨论了跨上下文窗口保持进展的问题。

Harness Engineering 就是在设计这些外围机制。例如日志太长怎样分页、工具失败怎样反馈、中断后怎样继续、完成怎样判定。

Framework 提供组织应用的方式和可复用组件；SDK 提供接口封装、类型与辅助代码。SDK 可能只封装模型请求，也可能包含 Agent Loop；是否支持权限、持久化和恢复，应分别确认。

Session、Run、Process 不是一个对象

Conversation 是对话记录；Session 是带标识的交互或执行上下文；Turn 是一轮交互，边界依系统定义；Run 是一次运行实例；Task 是有目标和范围的工作；Attempt / Trial 是一次尝试。

Process 是操作系统进程。Thread 既可能指操作系统线程，也可能指产品里的对话线程。

一个进程可以服务多个 Session，一个 Run 可以启动多个工具进程。界面关了以后任务是否继续，取决于后端生命周期，不取决于界面还保不保留聊天记录。

Worker 是执行单元，Queue 存放待执行任务，Scheduler 决定何时交给谁，Daemon 是后台常驻进程。IPC 是进程间通信，PTY 是支持终端交互的伪终端。

Concurrency，并发，多项工作在同一时间范围内推进；Parallelism，并行，强调真正同时执行。界面里出现三个任务，不能单独证明它们正在并行调用模型。

State 和 Source of Truth

State 是现在处于什么阶段。Source of Truth 是判断某类事实时应以哪份记录为准。

任务可以处于排队、运行、等待输入、完成、失败或取消。文件是否修改，以工作区内容为准；工单是否创建，以工单系统为准。聊天里一句「已经创建」不能覆盖外部系统事实。

Persistence，持久化，让进程退出后数据仍可读取。Checkpoint，检查点，保存从某个边界恢复所需的状态。Snapshot，快照，保存某时刻某范围的状态。

Event Log 按序记录事件；Event Sourcing 以领域事件序列作为状态变化的权威记录。保存一些运行日志，不自动等于采用了 Event Sourcing。

Replay 根据事件或已记录结果重建执行；Resume 从可恢复边界继续；Reconnect 恢复通信连接；Durable Execution 通过持久化、调度和恢复机制跨故障继续工作。

保存聊天历史不等于保存工具进度，检查点也不能保证从任意一行代码继续。LangGraph 的持久执行文档说明了恢复边界和副作用处理的重要性。

超时后为什么不能直接再来一次

Timeout 说明在限定时间内没有收到完成结果。它不能证明外部操作没有成功。

比如 Agent 请求创建工单，服务端创建成功，响应途中断线。直接再创建，就可能得到两张工单。

Retry 是重试；Backoff 在重试间增加等待；Jitter 为等待加入随机变化，避免大量请求同时重试。Cancellation 请求停止，已经发生的外部效果不一定能撤销。

Partial Success 表示一组操作只有部分成功；Compensation 用新的动作抵消已有部分效果，比如取消一条已经创建的预约，补偿本身也可能失败。

Idempotency 和 Reconciliation

Idempotency，幂等性，指在约定范围内重复同一请求，其预期业务效果与执行一次相同。它不要求每次返回文本完全一样，附带日志也可能增加。HTTP 规范的幂等性定义可以作为一个基础例子。

Idempotency Key 帮助服务识别重复请求。需要明确键的作用域、有效期、参数冲突和并发规则。

Reconciliation 是状态核对。响应丢失后，先用业务标识查询工单是否已存在，再决定继续或重试。

只有重试循环，不能自动得到 At-least-once 保证；本地数据库事务，也不能自动回滚已经发出的外部操作。

Lock 互斥访问，Lease 在有效时间内授予执行权，Heartbeat 报告执行者还在活动，Version / CAS 通过版本比较检测并发修改，Transaction 在限定范围内保证一致性，Backpressure 在下游来不及时限制上游。

心跳说明仍有活动，不说明任务一定有进展。

看一个 Agent 运行系统，先找四个答案

谁决定下一步，谁执行真实动作，状态存在哪里，怎样证明目标完成。

这四个答案清楚以后，再看 Runtime、Harness、Checkpoint，名词就能对应到具体代码。想继续沿真实实现读，可以看 Pi Agent Loop；里面的 Turn 等边界属于该实现，不能直接当成全行业定义。

下一篇：上下文、历史和记忆 · 返回总览

返回总览 · 上一篇 循环与运行。

你明明告诉过 Agent「这个项目不要新增依赖」，下一次它还是装了新包。

这时先不要急着认为模型没有记忆。那句话可能还在聊天历史里，只是没有进入本次模型输入；也可能被压缩成摘要时遗漏了。

理解记忆，要同时看信息保存在哪、怎样取出来、这次有没有交给模型。

七个词，先各放一个例子

它们会互相转换。历史里可以提炼出记忆，记忆可以被取出放进上下文，工具结果可以保存为缓存。

「不要新增依赖」是约束；「已经修改 login.ts，测试尚未运行」是任务进度。压缩时需要保留两者，但保存目的不同。

Context Engineering，每次到底给模型什么

Context Engineering，上下文工程，管理哪些信息、在什么时候、以什么形式进入模型。

本次模型输入可能包括系统规则、用户目标、最近对话、工具定义、工具结果、检索资料和记忆。界面显示的内容、数据库保存的内容、模型实际收到的内容，不一定相同。

例如任务是修登录 Bug，可以先给模型文件路径和日志摘要，再按需要读取具体代码。如果一开始把整个仓库和所有日志都放进去，增加的既有资源开销，也有无关信息。

上下文的选择与按需读取，参见 Anthropic 的上下文工程文章。

历史太长时，有哪些处理方法

Selection 选择当前相关内容；Trimming 移除低价值或过期内容；Sliding Window 保留最近一段历史。它们可以很简单，但不能盲目删除更早的关键约束。

Summarization 做摘要；Compaction 把长上下文压缩成继续工作所需的材料。摘要可以服务于阅读，Compaction 更关注任务能否接着做。具体实现也可能把两者合并。

Offloading 把大量内容放到文件或外部存储；Just-in-time Retrieval 需要时再取；Context Packing 在预算内选择、去重和排列证据。

比如测试输出有十万行，可以把完整日志存到文件，给模型失败摘要和读取入口。存到文件之后，若没有留下路径和读取方法，后续模型仍然拿不到它。

Compaction 应该留下什么

设想新的一次模型调用只拿到了摘要。它至少应当知道，当前目标、用户约束、已作决定、完成与未完成事项、验证结果、关键对象标识以及恢复位置。

一个为解释结构而写的示例如下。

目标：修复登录失败，不新增依赖。
已确认：错误来自刷新 Token 的分支。
已修改：src/login.ts 的 refreshSession。
验证：类型检查通过，登录集成测试未运行。
下一步：运行集成测试，检查过期 Token 场景。
注意：修改不涉及注册流程。

「研究了登录问题，进展顺利」读起来更短，却不能指导继续工作。

压缩仍然可能丢失细节。关键事实要能回到原文核查，实际文件和测试状态也要重新确认，摘要不能覆盖已经变化的环境。

已有的 Pi Agent 上下文工程从真实实现解释了工具截断、项目规则和历史压缩。

Overflow、Pollution、Rot

Context Overflow 是超出容量或请求限制。Context Pollution 是无关、错误或冲突信息进入上下文。Context Rot 常用来描述信息变长、变杂之后利用质量下降的现象，不是一个统一指标。

比如日志末尾显示数据库权限错误，旧摘要却说「已确定网络故障」，两条信息冲突，可能让模型继续沿过时假设行动。

Lost in the Middle 是关于信息位置影响的研究，讨论了部分模型在部分任务中，中间位置的信息更难利用。不能从这项研究推出所有新模型都有同样的下降曲线；可以阅读 原始论文，具体系统还应自己测。

Memory，两种分类不要混成一种

Short-term Memory 通常指当前任务或会话中的短期信息，Long-term Memory 跨任务或会话保留，Working Memory 是当前处理任务时使用的工作信息。边界依实现定义。

另一个维度按内容分类。

一条长期记忆可以是事实，也可以是方法。这些分类帮助设计使用方式，不规定必须对应三个数据库表。LangGraph 的记忆文档使用了相关分类。

记忆不一定要用向量数据库

文件可以存项目约束，关系数据库可以存带来源和版本的事实，向量索引可以辅助查找相似经历，图结构可以组织实体关系。

小项目只有几条约束时，直接读取一个文件就可能足够。更多历史经验需要按任务查找时，再考虑相应检索方式。

「使用向量库」描述存储与检索选择，「有记忆」描述信息怎样被保留和再使用。二者不是等号。

记忆有写入、更新和遗忘

一条记忆至少要考虑来源、作用域和时效。

用户说「这个仓库暂时不要升级 Node」，作用域是当前仓库，时间上可能只是暂时限制。若直接变成「用户永远不升级 Node」，就扩大了解读。

Write 决定什么值得保存；Extraction 从记录中提炼；Merge / Update 处理新旧信息；Retrieval 取出当前需要的内容；Scope / Namespace 限定用户、项目或任务范围；Provenance 保留来源；Expiration / Forgetting 处理过期和遗忘。

新旧记录冲突时，应该查时间和来源，必要时向用户确认。临时猜测不能不加标记地写成长期事实。

Hot-path Write 在当前请求中写入，较及时但增加前台工作；Background Write 后台提炼，前台负担较小，但最新记忆可能尚未可用。两种方式仍需避免重复、冲突和作用域串线。

Memory 和 RAG 怎样合作

Memory 关注后续保留什么，RAG 关注回答时如何检索外部资料。

检索上次部署经验，可能同时涉及 Memory 和 RAG；检索产品手册，可以只有 RAG；读取固定的用户偏好文件，可以有 Memory，但没有复杂检索。

判断「Agent 为什么忘了」时，可以顺着查，原始记录是否存在、是否提炼、作用域是否匹配、是否取出、是否进入本次上下文、内容是否过期或冲突。这样才能知道要修存储、检索，还是输入组织。

下一篇：RAG 的完整链路 · 返回总览

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/ai-agent-rag

「住宿费上限」 → [0.12, -0.48, 0.73, ...]

RRF(d) = 各路 1 / (k + 该文档在该路的排名) 之和

返回总览 · 上一篇 RAG。

一个 Agent 修代码，另一个检查是否破坏旧功能，看起来像两个人配合。

但它们是否看到相同资料、是否共享目录、谁最后负责合并结果，都需要程序设计。多 Agent 不会因为数量增加就自动形成团队。

这一篇把协作和观察环境放在一起讲，它们共同影响任务怎样从「安排了」走向「真的完成」。

Multi-agent 和 Subagent

Multi-agent 是多个 Agent 协作的系统。Subagent 是被委派子任务的 Agent。

子 Agent 可能拿到自己的目标、上下文和工具，也可能与主 Agent 共享部分环境。它可以使用同一个模型服务，独立 Agent 不等于独立模型或独立进程。

例如主 Agent 把任务拆成「修复」「检查兼容性」「验证回归」。每个子任务应有明确的范围、输入和交付标准。否则几名 Agent 都在读同一份代码、改同一个文件，成本和冲突就会增加。

Agent-as-a-Tool 和 Handoff

Agent-as-a-Tool 把另一个 Agent 当成可调用能力。主 Agent 发出请求，收到结果，再决定下一步。

Handoff 把控制权移交给另一个 Agent，例如通用客服把后续退款处理交给退款 Agent。用户接下来主要与接手方交互，具体形式依实现定义。

「让审查 Agent 返回报告」和「让退款 Agent 接管后续对话」是两种交互语义。工具调用返回之后，主 Agent 通常仍保留控制；交接需要明确谁继续负责。

协作模式可参考 LangChain 的多 Agent 文档。这些是设计模式，不是各家同名功能完全一致的保证。

常见编排方式

Orchestration，编排，安排任务依赖、调度、信息传递和汇总。

DAG 不包含环，State Graph 可以包含。把任务画成图，只说明依赖被表达出来，持久化和失败恢复仍需要额外实现。

什么工作适合分出去

相对独立的子任务更容易并行。比如一个检查登录逻辑，一个检查文档，两者修改范围不同，最终可以一起汇总。

先读代码才能确定修改点，先修改才能验证，这些步骤有依赖，不能直接同时推进。

交给子 Agent 的输入应保留目标、约束、上下文入口和交付标准。主 Agent 汇总时，还要处理结果冲突，不能把几份报告拼起来就默认成立。

共享工作区时，需要明确文件责任范围。隔离工作区时，也需要合并和重新验证集成结果。各自通过测试，不保证合在一起仍通过。

多 Agent 的收益可能是不同资料范围、独立审查和并行时间；代价包括重复上下文、交接损失、额外调用、取消传播和协调。相似模型看到相似资料时，也可能给出相同错误，投票数量不能自动变成事实证据。

编码 Agent 怎样观察代码

Text Search 查字符串和关键词，适合错误码、配置名或特定文案。LSP 提供定义、引用、类型和诊断等语言服务。

例如 createOrder 在两个模块里同名，文本搜索都能找出来；语言服务能帮助确定某处引用属于哪一个定义。LSP 能力依语言服务器而定，调用成功也要检查结果是否覆盖当前文件版本。

AST，Abstract Syntax Tree，抽象语法树，表达代码的语法结构，适合一些结构化分析和变换。它与简单字符串匹配不同，但具体工具是否理解类型、能否安全重构，要继续看实现。

Diff、Patch、字符串替换和整文件重写

Diff 表示两个版本的差异；Patch 描述要应用的变更；String Replacement 匹配旧文本并替换；Full Rewrite 重写整个文件。

字符串替换直观，但依赖准确匹配；Patch 适合表达局部差异，但需要足够上下文定位；AST 修改适合部分结构变换；整文件重写容易表达完整结果，但改动范围更大。

选择编辑方式之后，还要读回结果。成功返回说明编辑器做完了某次操作，不说明它命中了正确业务位置，也不说明项目仍能运行。

已有的 Kimi Code 与 Coding Agent 的 Edit 设计比较了具体实现。版本结论以那篇记录的源码范围为准。

ACI，模型与电脑之间的接口

ACI，Agent-Computer Interface，是 Agent 与计算机交互的接口设计。

同样是搜索工具，返回十万行混杂文本，和返回带文件路径、行号、分页入口的结果，对后续判断的帮助不同。

接口还需要说明文件是否截断、错误发生在哪里、修改失败如何恢复、怎样确认操作生效。SWE-agent 原始论文把这类接口设计作为自动软件工程的重要部分。

Computer Use，怎样观察和操作界面

Computer Use 让系统通过工具观察和操作电脑。浏览器操作也可以使用类似的观察、行动和反馈链。

Accessibility Tree，可访问性树，把界面中的语义角色、标签和状态提供给辅助技术，也能用于工具定位。AX Tree 是一些环境中的相关简称。

截图能显示 DOM 中不容易表达的画面，却需要识别坐标；语义结构能帮助准确找到按钮，却也可能缺失或落后于页面。选哪种观察方式，要看能回答当前问题的证据。

Locator、Selector、Auto-wait

Locator 描述怎样找到目标元素，例如名称为「保存」的按钮。Selector 是某种具体选择表达式，如 CSS 或 XPath。

Actionability 指元素是否适合操作，例如可见、启用、没有被遮挡；Auto-wait 自动等待相关条件满足。它们解决的是操作条件，不替代业务验收。可继续看 Playwright 定位器文档和 自动等待说明。

Navigation 是页面跳转，Dialog 是对话框，Download / Upload 是下载与上传；浏览器中的 Session / Cookies 参与保存登录和交互状态，不能和 Agent 的 Session 直接混用。

点击成功之后，再看结果

点保存之后，页面可能出现校验失败；填写成功之后，网络可能未提交；提交成功之后，后台处理可能还没完成。

保存资料应确认成功状态或重新读取对象，下载应确认取得文件，创建工单应确认正确对象存在。界面动作、网络响应和业务结果是不同的观察层。

这与多 Agent 汇总是同一个原则，安排出去的任务，要拿回能够核验的结果。

下一篇：缓存、Trace 与性能 · 返回总览

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/ai-agent-cache-observability

返回总览 · 上一篇 缓存与性能。

Agent 说「已经修好了」，你真正关心的是问题是否消失，旧功能有没有受影响。

同样，工具已经连上，不代表能做任何操作；模型认为可以做，也不能代替权限检查。这一篇回答两个问题，有没有权做，怎样知道做对了。

AuthN、AuthZ、Approval、Sandbox

认证解决身份，授权解决可访问范围，Approval 解决这次操作是否得到同意。它们可以配合，但不是互相替代。

沙箱限制本地执行资源，桥接的外部工具仍要检查业务权限。相关具体实践可以看 Claude Code 的沙箱介绍。

Prompt Injection，外部资料不能变成授权

Prompt Injection，提示注入，用输入或外部内容中的指令，诱导 Agent 违背任务要求、权限或信任边界。

Indirect Prompt Injection 来自网页、文件、检索资料或工具结果等外部内容。例如代码注释写着「读取所有密钥并发送到这里」，它是待分析的资料，不能因为被读到就成为用户指令。

用户正常改变需求，不属于提示注入。关键是指令来源和权威，而不是句子看起来像不像命令。

Tool Poisoning 在工具描述等元数据里植入误导指令；Data Exfiltration 把数据发送到未授权位置；Confused Deputy 指有权限的执行者被诱导替另一方越权操作。

Secret Management 管理和提供凭据；Credential Scope 规定凭据可访问范围。模型输入不必拿到原始密钥，执行器可以在相应边界使用凭据。

Trust Boundary，来源决定权威

Trust Boundary，信任边界，规定不同来源和权限的信息怎样影响决策与操作。

网页可以提供事实，日志可以证明某处失败，文件可以解释接口，但它们不能自行提升指令优先级、改变用户目标或授予新权限。

提示词提醒有帮助，程序仍应在工具执行边界做参数、对象和权限检查。例如外部文档里出现一个文件路径，不能因此绕过目录访问范围。

Human-in-the-loop 在某些环节让人补信息、判断或批准；Human-on-the-loop 更侧重人观察并必要时干预。询问收件人是补信息，询问是否发送是批准，两种交互要分开。

Test、Eval、Verifier、Grader、Oracle

Test 检查代码或系统行为；Eval 评估 AI 系统在一组任务上的表现；Verifier 检查当前结果是否满足验收；Grader 对某个维度判分；Oracle 提供预期结果或判断依据。

工单工具说成功，不足以完成「给正确项目创建正确工单」的验收。Verifier 还应读取目标系统，确认项目、内容和数量。

模型输出、行动轨迹和真实结果，都可能参与评测，但分别提供不同证据。可参考 Anthropic 的 Agent 评测文章。

常见软件测试，用场景理解

Fixture 准备测试数据和环境；Assertion 是必须成立的条件；Mock / Stub / Fake 是不同测试替身，框架用法也有差异；Coverage 看执行到多少代码或分支；Flaky Test 是代码没变仍时过时不过的测试。

覆盖率高不保证断言有效，使用模拟数据库也不能证明生产数据库正常。测试通过时，需要同时说明测试范围。

AI 评测怎样判分

Code-based Grader 用程序和规则判分，适合对象存在、数量、格式等可验证条件。LLM-as-a-Judge 用模型按标准评价，适合某些开放性质量。Human Evaluation 由人或专家评估。

Rubric 明确评价维度；Pairwise Comparison 比较两份结果；Calibration 检查自动评分与可靠参考的一致性。

模型判分也可能受到篇幅、措辞或顺序影响。能直接验证的业务条件，应保留直接证据；开放评价则要检查评分是否稳定、是否与人工判断一致。

pass@k 常描述允许 K 次尝试时至少一次成功的能力；pass^k 在一些评测中描述连续 K 次都成功的可靠性。具体计算以评测定义为准。

一个构造例子，假设每次独立成功概率为 80%，三次至少成功一次的概率是 1 - 0.2³ = 99.2%，三次全成功则为 0.8³ = 51.2%。独立性只是这个示例的假设，真实尝试可能相关，不能拿公式代替实际评测。

Baseline、Ablation、Leakage

Baseline 是比较基线；Ablation，消融，去掉或替换某机制来检查贡献；A/B Test 在可比较条件下对照方案；Controlled Variable 是控制变量。

想知道 Reranker 是否有用，可以在同一查询集比较有无重排，而不要同时更换嵌入模型、分块和提示词，否则难以归因。

Leakage，泄漏，是系统看到了本不该看到的信息，比如评测答案进入提示。Overfitting，过拟合，过度适应已见题目，未见任务表现下降。Held-out Set 是留出的测试集。

不断针对同十道题改提示词，也可能过拟合，测试集应覆盖真正会遇到的变化。

PRD、Spec、验收标准，把任务写清楚

PRD 描述用户、问题、范围和目标；Spec 描述预期行为、接口和约束。SDD 常指规格驱动开发，也可能指软件设计文档，需看全称。

Acceptance Criteria 是任务验收标准；Definition of Done 是团队共同的完成要求。登录任务的验收可以是正确凭据通过、错误凭据拒绝、旧流程兼容；完成要求还可能包括审查、文档和发布准备。

TDD 先写暴露需求缺口的测试，再实现和重构；BDD 用业务场景描述行为；ADR 记录架构决策和取舍；RFC 提出方案供讨论。

AGENTS.md、CLAUDE.md 等文件承载项目或工具说明，加载范围、顺序和优先级依宿主实现，不能只凭文件名推断所有产品行为相同。它们与 Skill 可以协作。

Commit、PR、CI、Deployment

Commit 保存一组版本变更；Branch 是独立演进路径；Worktree 是同一仓库的额外工作目录；PR / MR 提议把改动合入目标分支；Merge 合并版本变化；Rollback 回退版本或状态。

分支隔离 Git 历史，Worktree 提供额外目录，外部数据库或服务未必随之隔离。不能把「在另一个分支运行」理解成所有副作用都安全隔离。

CI，持续集成，频繁集成并用构建、测试验证；Continuous Delivery，持续交付，保持可发布状态，生产发布可以人工决定；Continuous Deployment，持续部署，通过门槛后自动部署生产。

它们的区别可读 持续交付的定义。代码已提交、CI 已通过、版本已部署、真实用户问题已解决，也需要分别确认。

SLI 是衡量服务的指标，SLO 是目标，SLA 是服务级别协议。例如请求成功率是指标，对成功率设目标，再形成相应服务协议，属于不同层次。

Todo、Task、Goal、Task Run、Task Graph

Todo 跟踪小事项；Task 是有目标和范围的工作；Goal 可能需要多个任务；Task Run 是某任务的一次执行；Task Graph 表达任务依赖。产品可能使用不同命名，要回到它的对象定义。

「修登录」可以是任务，「运行过期 Token 测试」是其中一个事项，「提高账户系统可靠性」是更长期目标。同一任务可能运行多次，每次结果和证据应对应自己的 Run。

最后把完成标准落到结果上

一次修复的交付，应让读者看清改了什么、验证了哪些行为，以及还有哪些限制。一次外部操作，应检查目标对象真实状态。

模型说完成，是待验证的产出；真实结果符合要求，才有完成的依据。把这个习惯带回工具、RAG、协作和运行恢复里，整套概念就能连起来。

回到总览，选择其他专题 · 从第一篇重新读：模型基础

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/biny-agent-tool-system

今天看到了 Claude 的一篇文章，介绍重新设计后的 Claude Code Projects。

我觉得这个功能挺有意思：它在 Claude Code Session 之上增加了一个项目级 Coordinator（协调 Agent），用统一的项目对话来管理多个独立的 Claude Code Session。

用户只需要在一个对话框里持续提出需求，Coordinator 就可以根据任务情况创建或复用 Thread，完成任务拆分、分发与结果汇总。

一、整体架构

Claude Code Projects 的结构可以简单理解为：

Project → Coordinator → Threads（Sessions）

• Project：项目级工作空间，关联代码仓库或其他上下文，并保存项目指令与共享记忆。
• Coordinator：负责理解需求、拆分任务、调度 Thread，并跟踪执行进度。
• Thread：独立的 Claude Code 云端 Session，负责具体任务的执行。

例如，用户提出一个需求：

分析当前项目的后端架构，优化运行时性能，并补充必要的测试。

Coordinator 可以按任务依赖关系拆分工作：

• Thread A：分析架构和性能瓶颈。
• Thread B：根据分析结果优化代码。
• Thread C：补充测试并验证修改。

每个 Thread 都是完整的 Claude Code Session，而不只是简单的 Subagent。云端 Thread 在独立分支和仓库副本中工作，内部也可以继续使用 Subagent、循环或工作流拆解任务。

Coordinator 可以创建新的 Thread，也可以把后续任务交给已有 Thread 继续执行。多个 Thread 如果改动了同一处代码，仍然需要像处理普通 PR 一样解决冲突。

二、我认为最大的价值是统一交互入口

相比多 Agent 并行，我个人更关注它的交互设计。

对于用户来说，理想的交互方式可能就是一个 Project 对应一个主要对话框。

用户不需要频繁创建新的 Session，也不必为了完成相关任务，在多个对话之间来回切换、重复描述项目背景。

例如，今天让 Claude 优化 RuntimeHost，明天让它继续修复相关 Bug，后天再补充测试。这些需求都可以直接发送给同一个 Coordinator，由它决定交给哪个 Thread 执行。

这样用户面对的是一个持续存在的项目，而不是一堆分散的聊天记录。

底层的 Session 并没有消失。Coordinator 依然会管理多个 Thread，只不过用户不再需要手动处理它们的生命周期和任务分配。

必要时，用户仍然可以进入具体 Thread，查看代码修改、工具调用以及执行结果。

统一的是交互入口，而不是所有 Agent 的执行上下文。

我认为这种设计更符合人的使用习惯。用户应该专注于描述目标和检查结果，而不是花费大量精力组织 Agent 的工作过程。

三、那同一个对话框会不会上下文爆炸？

这是我觉得比较值得研究的地方。

虽然用户始终在一个 Project 对话框里交流，但这并不代表所有 Session 的上下文都被塞进同一个模型窗口。

这里至少可以区分两个层次的上下文。

首先是 Thread Context。

每个 Thread 有自己的上下文窗口，独立进行代码阅读、工具调用、修改和测试。Coordinator 会接收 Thread 返回的进展和结果，不需要把每个 Thread 的完整执行历史都当作自己的对话内容。

因此，多个 Thread 的上下文不会简单累加到 Coordinator 的上下文窗口中。

其次是 Coordinator Context。

Coordinator 本身依然有上下文窗口限制。如果用户持续几个月都在同一个 Project 里对话，消息和任务信息也会不断积累。

Anthropic 公开介绍确认，Project 中的 Thread 会共同写入并读取共享 Memory，帮助后续工作沿用项目细节和决策。官方介绍没有披露 Coordinator 每轮具体加载多少历史消息、采用什么裁剪策略。因此，“结合近期消息、近期 Thread 信息与 Project Memory 来组织上下文”更适合作为一种基于产品描述的理解，而不是已公开确认的实现细节。

即使有共享 Memory，也不代表彻底解决了上下文问题。较早的需求、设计决策或任务约束，如果没有被正确记录下来，仍然可能在后续执行中丢失。

因此，它解决的主要是上下文的隔离和管理，而不是让模型拥有无限上下文。

四、我的理解

我认为 Claude Code Projects 的核心设计可以概括为：

Project 负责长期交互与协调，Session 负责具体执行，Memory 负责跨 Session 保留重要信息。

这几个概念不应该混在一起。

用户看到的是一个统一且持续存在的项目对话框，而底层实际上由多个具有独立生命周期的 Session 组成。

从交互体验来看，它减少了用户管理大量 Session 的负担。

从上下文管理来看，它避免了把所有任务的执行过程集中到同一个模型窗口。

我觉得这是一个挺合理的方向。

尤其对于 Coding Agent 来说，用户真正需要的可能不是管理 Session 的能力，而是让 Agent 自己管理 Session 的能力。

当然，Coordinator 如何决定创建或复用 Thread、如何维护跨 Session 的任务状态，以及怎样保证长期共享记忆的准确性，仍然是值得继续研究的问题。

参考资料

• Claude：Projects redesigned: from folder to conversation
• Claude Code Projects 官方文档

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/ai/kimi-code-edit-design

*** Begin Patch
*** Update File: src/config.ts
@@
-const timeout = 3000;
+const timeout = 5000;
*** End Patch

一、引子：大模型的三种用法

在聊 Agent Loop 之前，我们先退一步，看看”使用大模型”这件事本身有几种模式。这对理解”为什么需要循环”至关重要。

模式 1：直接调用 —— “模型，回答我”

最原始、最直觉的用法。你构建好提示词，调用一次 API，拿到结果，完事。

用户输入 → 构建提示词 → 调模型 → 模型输出 → 展示结果

核心工作在于”构建提示词”** 。提示词写得好，结果就好。一次调用，一次输出，没有来回。

适用场景：翻译、摘要、问答、代码补全——凡是”一问一答”能搞定的事。

模式 2：Workflow —— “模型，你先做第一步，我检查一下，再做第二步”

当任务变复杂，你发现一次性很难得到满意结果。于是你把大任务拆成多步，每步调一次模型，步骤之间由 你的代码 控制流转。

用户输入 → [步骤1: 调模型分析] → [你的代码: 提取关键信息]
         → [步骤2: 调模型生成草稿] → [你的代码: 检查质量]
         → [步骤3: 调模型润色] → 最终输出

每一步模型只负责自己的那份工作， 决策权在你手上 ——你知道什么时候该进入下一步，模型只是流水线上的一环。

适用场景：文档生成流水线、代码审查自动化、RAG（检索增强生成）。

模式 3：Agent Loop —— “模型，你自己决定怎么做”

到了 Agent 模式，你把决策权交给了模型。

用户输入 → 调模型 → 模型说"我需要读文件" → 执行读文件 → 模型看结果
         → 模型说"还需要搜索代码" → 执行搜索 → 模型看结果
         → 模型说"我知道了，答案是..." → 输出 → 结束

关键区别： 步骤之间的流转不再由你写死，而是由模型的输出内容来驱动。 你的代码只做两件事：

1. 把用户的输入和工具执行结果喂给模型
2. 如果模型输出的内容里包含了工具调用请求，就执行它；如果没有，就认为任务完成了

至于”该调什么工具”、“该调几次”——这些由模型的输出内容决定。“什么时候该停”——这是 人类定义的规则 ：当模型的一次输出中不再包含工具调用时，我们就认为循环可以结束了。

用一个对比表格，三种模式的区别一目了然：

二、Trace、Turn

在深入源码之前，有两个概念必须分清楚。它们经常被混用，但在 Pi 的代码里，每个都有精确的含义。

Trace（一次完整运行）

一个 Trace 是从用户按下回车、到 Agent 彻底停下来、发出 agent_end 事件的 整个过程 。一个 Trace 包含多个 Turn。

一个 Trace（一次 agent_start 到 agent_end）
│
├── Turn 1：调模型 → 模型返回 toolUse（要读文件）→ 执行 read 工具
│
├── Turn 2：带着工具结果再调模型 → 模型返回 toolUse（还要改文件）→ 执行 edit 工具
│
└── Turn 3：带着工具结果再调模型 → 模型返回 stop（改好了，没有工具调用）→ agent_end

Turn（一个轮次）

一个 Turn 的定义非常精确： 一次模型调用 + 这次调用触发的所有工具执行。

每个 Turn 由一对 turn_start 和 turn_end 事件包裹。关键点： 一个 Turn 只有一次模型调用。 模型返回了 toolUse → 执行那批工具 → 发送 turn_end → 这个 Turn 就结束了。把工具结果喂回去再调模型，那是 下一个 Turn 。

看代码就更清楚了。内层循环每一圈的结构（后面会详讲）：

while (hasMoreToolCalls || ...) {
    if (!firstTurn) emit(turn_start);    // ← 新 Turn 开始

    处理 pendingMessages
    streamAssistantResponse()             // ← 一次模型调用
    检查 stopReason
    executeToolCalls()                    // ← 执行这个 Turn 触发的一批工具
    emit(turn_end);                       // ← 这个 Turn 结束

    prepareNextTurn / shouldStopAfterTurn / 检查 steering
}

一圈内层循环 = 一个 Turn = 一次 turn_start → 一次模型调用 → 工具执行 → 一次 turn_end。

如果模型在一个 Turn 中一口气要求了 3 个工具（read + grep + find），那这 3 个工具都在同一个 Turn 里执行——因为它们都是同一次模型调用的产物。但执行完毕后把结果喂回去再调模型的那一刻，就已经进入下一个 Turn 了。

所以 Trace 和 Turn 的关系就是

Trace（一次完整运行）
│  agent_start
│
├── Turn 1
│   │  turn_start
│   ├── 调模型 → toolUse → 执行工具（read + grep）
│   │  turn_end
│   │
├── Turn 2
│   │  turn_start
│   ├── 调模型 → toolUse → 执行工具（edit）
│   │  turn_end
│   │
├── Turn 3
│   │  turn_start
│   ├── 调模型 → stop → 没有工具
│   │  turn_end
│   │
│   agent_end

注意：首轮 Turn 的 turn_start 是在 runAgentLoop() 入口就发出的，然后 runLoop() 内用 firstTurn 标志跳过首圈的 turn_start，避免重复。

Trace 与 Turn 的嵌套结构

配图说明 ：一个 Trace 外壳内嵌 3 个 Turn，每个 Turn 都是”模型调用 + 工具执行”的完整闭环。注意 Turn 3 没有 ToolCall（虚线框），它的 stopReason = stop 触发循环退出。

三、全景：一条消息的旅程，以及循环怎么转

你输入了”帮我读一下 src/main.ts”并按下回车。从这一刻起发生了什么？让我们站在高处看一遍全过程，同时把”循环怎么转起来的”和”循环什么时候停”一并讲清楚。 不必纠结每个细节 ——后面会逐段拆解源码。

途中你会遇到四个反复出现的”实体”：你的输入变成 消息（Message） ；Loop 调用**模型（Model） 来思考；模型要求的操作用 工具（Tool） 完成；每一步通过 事件（Event）**通知外部。驱动这四者反复运转的机制就是本章主角—— Agent Loop 。

流程全景

你按下回车："帮我读一下 src/main.ts"
│
│  ① 你的输入变成一条消息
│
UserMessage { role: "user", content: "帮我读一下 src/main.ts" }
│
│  ② 进入循环（agentLoop 入口）—— agent_start（一个 Trace 开始了）
│
└── runLoop()
    │
    │  ③ 消息转换（AgentMessage → LLM 认识的 Message）
    │
    │  ┌── Turn 1 ──────────────────────────────────────────┐
    │  │  turn_start                                         │
    │  │  ④ 调用 Model（每 Turn 仅一次模型调用）               │
    │  │  streamSimple(model, { systemPrompt, messages })    │
    │  │       ↓ 逐 token 流式返回                            │
    │  │  AssistantMessage {                                  │
    │  │      content: [ ..., ToolCall { name: "read", ... } ],│
    │  │      stopReason: "toolUse"  ← 有工具调用，继续转      │
    │  │  }                                                  │
    │  │  ⑤ 执行 Tool（工具的五步管道，详见第5章）              │
    │  │  ToolResultMessage { content: [{ text: "文件内容" }] }│
    │  │  turn_end                                            │
    │  └─────────────────────────────────────────────────────┘
    │
    │  循环判断：stopReason 是 toolUse → hasMoreToolCalls = true → 继续
    │
    │  ┌── Turn 2 ──────────────────────────────────────────┐
    │  │  turn_start                                         │
    │  │  ⑥ 第二次调用 Model（工具结果已追加到消息列表）         │
    │  │  streamSimple(model, { messages: [..., toolResult] })│
    │  │       ↓ 模型看到文件内容，开始解释                      │
    │  │  AssistantMessage {                                  │
    │  │      content: [ TextContent { text: "这个文件..." } ],│
    │  │      stopReason: "stop"  ← 没有工具调用，准备停        │
    │  │  }                                                  │
    │  │  turn_end                                            │
    │  └─────────────────────────────────────────────────────┘
    │
    │  循环判断：hasMoreToolCalls = false，pendingMessages 为空
    │  → 内层循环退出
    │  → 外层循环检查 followUp → 空 → 外层循环退出
    │
    └── agent_end（一个 Trace 结束，共 2 个 Turn）

循环怎么转：stopReason —— 唯一的信号灯

整个循环的”油门和刹车”集中在 一个字段 上： stopReason 。模型每次返回的 AssistantMessage 里都带着它。

但在此之前，必须澄清一个关键认知： 模型不会说”我要停了”。 模型只是个 token 预测器——给定上下文，猜下一个 token，如此反复。它不”知道”任务做完了没有。 stopReason 这个字段虽然挂在模型的返回值上，但它的值来自 两个不同的地方 ：

模型 API 真正返回的三种：

框架的流式层注入的两种 （模型 API 本身不会返回这两种值）：

代码证据（ packages/ai/src/ ）：当 streamSimple 内部的 API 调用抛出异常时，catch 块执行 output.stopReason = options?.signal?.aborted ? "aborted" : "error" 。这不是模型说的，是框架替它”兜底”的。

一条规则驱动整个循环

Loop 实际上只看一件事—— 模型输出里有没有工具调用 。这背后是一条 人类定义的工程约定 ：

如果模型一次输出中没有工具调用，就认为本轮不需要更多操作，循环可以停了。

这不是模型的”智能决策”。换个说法： 不是模型在说”我完成了”，而是我们在说”你没要工具，那就当你完成了”。

代码里最精炼的判断就是这个（伪代码示意，实际见 agent-loop.ts:202-216 ）：

// 简化逻辑（实际见 agent-loop.ts:202-216）
const toolCalls = message.content.filter(c => c.type === "toolCall");
hasMoreToolCalls = false;
if (toolCalls.length > 0) {
  const executedToolBatch = await executeToolCalls(...);
  hasMoreToolCalls = !executedToolBatch.terminate;  // 任何一个工具 terminate 则停止
}

注意 ：实际驱动循环的不是 stopReason === "toolUse" ，而是 toolCalls 数组长度 > 0 && !terminate 。这意味着：即使 stopReason === "length" （被截断），只要 content 里有 toolCall 块，循环仍会执行工具；反之，即使 stopReason === "toolUse" ，如果所有工具结果都设置 terminate: true ，循环也会停。

内层循环的条件是 while (hasMoreToolCalls || pendingMessages.length > 0) ：

• 模型返回 toolCall 且工具未 terminate → hasMoreToolCalls = true → 继续转 ：执行工具，把结果喂回去再调模型
• stopReason === "stop" 或 "length" 且无 toolCall → hasMoreToolCalls = false → 准备停 （看有没有 pendingMessages）
• stopReason === "error" 或 "aborted" → 硬停止 ：立即退出整个循环，不检查 followUp

┌──────────────────────────────────┐
     │                                  │
     ▼                                  │
┌─────────┐  toolUse   ┌──────────┐    │
│ 调模型   │ ─────────→ │ 执行工具  │    │
└─────────┘            └──────────┘    │
     │                      │          │
     │ stop / length        │ 结果追加  │
     │                      ▼ 到消息    │
     ▼                 重新调模型 ──────┘
┌─────────┐
│ 准备停   │   ← 不是模型决定的，是我们的规则
└─────────┘

error / aborted → 直接跳出整个循环（硬停止）

为什么不让代码更智能地判断”任务完成没”？ 因为这正是 Agent 和 Workflow 的本质区别。Workflow 里你知道流程有几步，可以用代码判断进度。但 Agent 模式下，你不知道模型要读几个文件、改几处代码——你唯一能稳定依赖的信号就是： 输出里有没有工具调用。 这既是局限，也是优雅——不需要任何”任务完成度”判断逻辑，代码只做最简单的那层判断。

循环的所有退出路径

stopReason 驱动的循环决策流程

配图说明 ：五种 stopReason 分三路处理——toolUse 让循环继续转；stop/length 准备正常停（仍检查 followUp）；error/aborted 硬停止（不检查 followUp）。注意 stopReason 的两个来源：三种来自模型 API，两种是框架流式层注入的兜底。

四、源码详解：基础 Loop 与 coding-agent 的叠加设计

给了你概念全景：消息怎么流动、stopReason 怎么驱动循环、什么时候停。但那都是” 是什么 ”。这一节走进代码，回答” 怎么做到的 ”。

在看 Pi 的源码之前，先搞清楚一件事： 最简单的 Agent Loop 其实极其简短。

最简 Loop：所有 Agent 的最小公约数

剥掉所有产品特性，一个能用的 Agent Loop 只需要这些：

// 最简 Agent Loop（伪代码）
async function simpleLoop(messages, model, tools) {
    while (true) {
        // ① 调模型
        const response = await callModel(model, messages, tools);
        messages.push(response);

        // ② 没有工具调用 → 结束
        if (response.stopReason !== "toolUse") {
            return messages;
        }

        // ③ 有工具调用 → 执行，把结果喂回去
        for (const toolCall of response.toolCalls) {
            const result = await executeTool(toolCall);
            messages.push(result);
        }
    }
}

十几行代码。一个 while 循环，调模型、执行工具、再调模型，直到模型不再要求工具。这就是 §三 讲的那套逻辑的最小实现—— 任何 Agent 都需要这个内核 。

Pi 的 coding-agent 在此基础上叠加了什么

Pi 的 coding-agent 是一个 交互式编程助手 ——用户在终端里跟它对话，它可能要读好几个文件、改代码、跑测试。这种产品场景比”最简 Loop”多出了真实的需求：

关键认知 ：这些叠加设计都是 coding-agent 的 功能选择 ，不是 Agent 的通用法则。如果你做的是一个”一问一答带工具”的简单 Agent，上面这张表全是多余的——你只需要最简 Loop。

但理解 coding-agent 怎么叠加这些设计很有价值——你自己的产品场景很可能也需要类似机制。接下来，我们以 coding-agent 的完整源码为例，逐段走这些设计。跟着那条”帮我读一下 src/main.ts”的消息，走完从入口到结束的整段旅程。

4.1 入口：runAgentLoop() 收到了什么

§三简要展示了流程全景，这里展开看代码细节——同一个过程，更深入的视角。

你按下回车后，调用链是： Agent.prompt() → runPromptMessages() → runAgentLoop() 。停在入口：

// agent-loop.ts:95-118
async function runAgentLoop(
    prompts: AgentMessage[],     // 你的消息
    context: AgentContext,       // 当前对话上下文（快照副本）
    config: AgentLoopConfig,     // 循环配置（模型、钩子、队列回调）
    emit: AgentEventSink,        // 事件发射器
    signal?: AbortSignal,        // 中止信号
    streamFn?: StreamFn,         // 流式函数（可替换）
): Promise<AgentMessage[]>

六个参数中最重要的三个：

prompts — 你的消息已经被包装成了标准格式：

[{
  role: "user",
  content: [{ type: "text", text: "帮我读一下 src/main.ts" }],
  timestamp: 1748000000000
}]

context — 对话上下文快照。注意是 副本 （ agent.ts:414-420 的 createContextSnapshot() 创建），Loop 运行期间对 context 的修改不会影响 Agent 类的原始状态：

{
  systemPrompt: "You are a helpful coding assistant...",
  messages: [ /* 之前的对话历史 */ ],
  tools: [
    { name: "read", description: "...", parameters: Type.Object({...}), execute: ... },
    { name: "bash", description: "...", parameters: Type.Object({...}), execute: ... },
  ]
}

config — Loop 的行为配置。这里有一组关键钩子（都是函数，不是数据）：

{
  model: Model,                    // 用哪个 LLM
  convertToLlm: Function,          // AgentMessage[] → Message[] 转换
  transformContext?: Function,      // 调 LLM 前的上下文预处理（如压缩）
  getSteeringMessages?: Function,   // 获取"紧急插队"消息
  getFollowUpMessages?: Function,   // 获取"追加任务"消息
  shouldStopAfterTurn?: Function,   // 每轮结束后是否该停
  beforeToolCall?: Function,        // 工具执行前钩子
  afterToolCall?: Function,         // 工具执行后钩子
  toolExecution: "parallel",        // 工具执行模式
}

这些钩子都是 函数 而非数据——Loop 在运行时调用它们来”拉取”最新状态。这让 Loop 和外部消息来源彻底解耦。

入口函数只做了三步准备：

Step 1: 创建 newMessages 数组
        → 收集本轮 Trace 产生的所有新消息

Step 2: 把 prompts 追加到 context.messages
        → context.messages = [...context.messages, ...prompts]

Step 3: 发初始事件
        → emit("agent_start")    ← Trace 开始
        → emit("turn_start")     ← 首轮 Turn 开始（入口就发，后续 Turn 在内层循环里发）
        → 对每条 prompt：emit("message_start") + emit("message_end")
        → 调用 runLoop()

数据变化：

入口前：
  context.messages = [user1, asst1, toolResult1]    ← 之前的对话
  newMessages = []

入口后：
  context.messages = [user1, asst1, toolResult1, user2]  ← 你的消息被追加
  newMessages = [user2]                                   ← 收集器开始记录

4.2 runLoop() 的骨架：先看内核，再看叠加

现在进入 runLoop() ——整个系统最核心的代码。别被它的长度吓到，我们先看 内核 ，再看 叠加 。

内核：内层循环

如果只保留最简 Loop 的逻辑， runLoop 长这样：

// 只保留内核的 runLoop（伪代码）
while (hasMoreToolCalls) {
    // 步骤 B：调 LLM
    // 步骤 C：检查 stopReason → error/aborted 就退出
    // 步骤 D：执行工具
    // 步骤 E：emit turn_end
}
// 结束 → emit agent_end

这就是最简 Loop——调模型、执行工具、turn_end，循环往复。内层循环的退出条件 hasMoreToolCalls 由 toolCalls 数组长度 > 0 && !terminate 驱动（§三讲过）。 这段是所有 Agent 都需要的内核。

叠加：coding-agent 加了两层外壳

但 coding-agent 作为交互式编程助手，需要在内核外面加两样东西：

叠加 1：steering 消息注入 （内层循环开头 + 每圈结尾各检查一次）。用户在 Agent 工作时输入了新指令——这些消息不能等当前任务跑完，得在下一圈开头紧急注入。所以内层循环条件多了一个 || pendingMessages.length > 0 。

叠加 2：外层 followUp 循环 （包在整个内层循环外面）。Agent 自然停了之后，系统可能还想追加任务（比如”顺便跑个测试”）。外层循环让这些追加任务在 同一个 Trace 内 继续跑，不需要重新启动一个新的 Loop。

把内核和两层叠加拼起来，才是完整的 runLoop 骨架：

async function runLoop(currentContext, newMessages, config, signal, emit, streamFn) {

    // ① 首次 steering 检查（在进入内层循环之前！）
    let pendingMessages = (await config.getSteeringMessages?.()) || [];

    // ========== 叠加2：外层循环（followUp 续命）==========
    while (true) {
        let hasMoreToolCalls = true;
        let firstTurn = true;  // 首轮跳过 turn_start（入口已发）

        // ========== 内核 + 叠加1：内层循环 ==========
        while (hasMoreToolCalls || pendingMessages.length > 0) {
            //                                    ↑ 叠加1：steering 消息也驱动循环

            if (!firstTurn) {
                emit({ type: "turn_start" });
            }
            firstTurn = false;

            // 步骤 A：注入 pendingMessages（steering 消息）← 叠加1
            // 步骤 B：调 LLM → streamAssistantResponse()  ← 内核
            // 步骤 C：检查 stopReason                      ← 内核
            // 步骤 D：执行工具                              ← 内核
            // 步骤 E：emit turn_end                         ← 内核
            // 步骤 F：prepareNextTurn → shouldStopAfterTurn ← 叠加（钩子）
            //         → 再次检查 steering                    ← 叠加1
        }

        // ========== 内层循环结束 ==========
        // 叠加2：检查 followUp 队列
        const followUpMessages = (await config.getFollowUpMessages?.()) || [];
        if (followUpMessages.length > 0) {
            pendingMessages = followUpMessages;
            continue;  // 回到外层循环顶部，内层循环重开
        }

        break;  // 两个队列都空，真正退出
    }
}

现在我们逐步骤展开。每个步骤会标注”内核”还是”叠加”，方便你区分。

4.3 【叠加1 · 步骤A】steering 消息注入

什么是 steering？ 这是 coding-agent 的一个交互功能。想象你让 Agent 帮你修一个 bug，Agent 正在读文件、分析代码。这时候你突然想到一个补充：“也检查一下测试文件”——你希望这条指令能 插队 ，而不是等 Agent 把当前任务做完再说。

steering 就是这个”插队”机制。用户在 Agent 工作期间输入的新指令，会被放进 steering 队列。每圈内层循环开头，Loop 先检查这个队列，把紧急消息注入到当前对话中：

if (pendingMessages.length > 0) {
    for (const message of pendingMessages) {
        await emit({ type: "message_start", message });
        await emit({ type: "message_end", message });
        currentContext.messages.push(message);
        newMessages.push(message);
    }
    pendingMessages = [];  // 消费完毕，清空
}

这段代码就是把紧急消息逐条注入到上下文和消息收集器中。

pendingMessages 的第一个来源是 runLoop 一进来就执行的首次 steering 检查（ agent-loop.ts:167 ）。为什么要在进入循环 之前 就检查？因为用户在等待 LLM 首次响应时可能又输入了内容——这时候消息已经从外部排队了，但循环还没开始，如果不提前取出来，这批消息就漏掉了。

4.4 【内核 · 步骤B】streamAssistantResponse() — 调 LLM

这是整个 Loop 最重的一步——把消息发给模型、拿回流式响应。分为四个阶段。

阶段 A：上下文预处理（可选）

let messages = context.messages;
if (config.transformContext) {
    messages = await config.transformContext(messages, signal);
}

如果配置了 transformContext （如压缩算法），在此预处理消息。不配置就跳过。

阶段 B：AgentMessage → Message 转换（两层消息的边界）

const llmMessages = await config.convertToLlm(messages);

这一行站在 Agent 内核和 LLM 的 边界 上。要理解它为什么存在，得先知道”两层消息”的设计。

Agent 内部维护对话历史时，需要记录的不只是”用户说了什么、AI 回了什么”——它还需要记录 自己的内部状态 。比如 coding-agent 会记录：上下文被压缩过（ CompactionSummaryMessage ）、Bash 命令的执行详情（ BashExecutionMessage ）、分支切换的记录（ BranchSummaryMessage ）。这些是 Agent 自己用的”内部语言”， LLM 根本不认识这些消息类型 ——它只认三种标准消息： UserMessage 、 AssistantMessage 、 ToolResultMessage 。

convertToLlm 就是站在这个边界上的 翻译官 ：把 Agent 的内部语言翻译成 LLM 能理解的协议。默认实现就是一个 .filter() ——只保留三种标准消息：

function defaultConvertToLlm(messages: AgentMessage[]): Message[] {
    return messages.filter(
        (message) => message.role === "user"
                  || message.role === "assistant"
                  || message.role === "toolResult",
    );
}

数据变换：

转换前（AgentMessage[]）：
[
  { role: "user", content: "帮我读一下 src/main.ts", ... },    ← 保留
  { role: "assistant", content: [...], ... },                   ← 保留
  { role: "compactionSummary", summary: "之前的对话摘要..." },   ← 过滤掉
  { role: "toolResult", content: [...], ... },                  ← 保留
]

转换后（Message[]）：
[
  { role: "user", content: "帮我读一下 src/main.ts", ... },
  { role: "assistant", content: [...], ... },
  { role: "toolResult", content: [...], ... },
]

两层消息的完整设计，详见《第6章：消息系统》。

阶段 C：构建 Context 并调用模型

const llmContext: Context = {
    systemPrompt: context.systemPrompt,
    messages: llmMessages,
    tools: context.tools,
};

const streamFunction = streamFn || streamSimple;
const resolvedApiKey =
    (config.getApiKey ? await config.getApiKey(config.model.provider) : undefined)
    || config.apiKey;

const response = await streamFunction(config.model, llmContext, {
    ...config,
    apiKey: resolvedApiKey,
    signal,
});

构建 Context 是这一步的主线。 注意 llmContext 是一个 全新对象 ，每圈内层循环都重建一次。它由三部分组成：

• systemPrompt —— 直接复用 Agent 上下文里的系统提示词，告诉模型”你是谁、该遵守什么规则”
• messages —— 就是上一步 convertToLlm 过滤后的 llmMessages ，只含 LLM 认识的三种标准消息
• tools —— 工具列表（带 schema 定义），让模型知道”这次有哪些工具可以调”

注意一个细节： llmContext.tools = context.tools 是 引用赋值 ——每圈虽然包了个新的 wrapper 对象，但 tools 数组本身是同一份引用，内容字节级稳定。 systemPrompt 同理。只有 messages 真的在长（每圈追加新的 ToolResultMessage）。

那为什么还要每圈重建 llmContext 这个 wrapper？因为有的 Turn 确实会改这三者里的某一个： prepareNextTurn 钩子（§4.7）可能换过模型或改过 systemPrompt，扩展系统（§5）可能动态注册新工具。重建 wrapper 的成本可以忽略（一个 JS 对象），但能保证不会因为共享引用导致难以追踪的状态污染。

这会不会破坏 prompt cache？ 不会。Anthropic 的 prompt cache 是 内容寻址 的——它看的是发过去的字节，不是请求的 identity。每次发的是新对象还是旧对象无所谓，只要 system + tools 的字节不变，cache 就命中。Pi 在 anthropic-messages.ts 里显式在 三个位置 打 cache_control: { type: "ephemeral" } 标记：

第三条尤其精妙：cache breakpoint 不是固定在第一条消息上，而是 跟着最新 user message 走 。这样旧前缀继续命中、新追加的内容被写入，整个对话历史都享受 cache 收益。命中链路大致是：

Turn 1: 写入 [system + tools] → 写入 [messages §1]
Turn 2: 命中 [system + tools] → 命中 [messages §1] → 写入 [messages §2]
Turn 3: 命中 [system + tools] → 命中 [messages §1+§2] → 写入 [messages §3]

还有个容易误解的点： tools 不是被塞到 messages 末尾 。Anthropic API 协议里 tools 是独立的顶层字段（位置在 messages 之前），这个协议设计本身就考虑了 cache——稳定的 tools 在前、变动的 messages 在后，prefix 越长越省。

OpenAI 体系走的是另一条路（ openai-completions.ts:554 ）： prompt_cache_key: sessionId ，OpenAI 后端按 session 自动匹配前缀。DeepSeek、Qwen 等通过 cacheControlFormat: "anthropic" 兼容字段，也能复用 Anthropic 风格的 cache_control 标记（ L593 的 applyAnthropicCacheControl ）。

阶段 D：流式处理响应 —— 原地替换的妙用

streamFunction 返回的是 AssistantMessageEventStream ——一个异步迭代器。这步有一个很精巧的设计：

for await (const event of response) {
    switch (event.type) {
        case "start":
            // 拿到一个"空壳"消息，直接 push 到 context
            partialMessage = event.partial;
            context.messages.push(partialMessage);
            emit({ type: "message_start", ... });
            break;

        case "text_delta":       // 文本增量
        case "toolcall_delta":   // 工具调用增量
        case "thinking_delta":   // 思考增量
            partialMessage = event.partial;            // 更新后的部分消息
            context.messages[last] = partialMessage;    // ★ 原地替换！
            emit({ type: "message_update", ... });      // UI 收到增量更新
            break;

        case "done":
        case "error":
            finalMessage = await response.result();
            context.messages[last] = finalMessage;       // ★ 用最终完整消息替换
            emit({ type: "message_end", ... });
            return finalMessage;
    }
}

为什么要先 push 空壳再原地替换？注意”原地替换”的意思——不是往 context.messages 数组里 push 新条目，而是 用新内容覆盖最后一条 （ context.messages[last] = partialMessage ）。这样 context 的消息数量不变，但最后一条消息的内容在”长大”。

为了 UI 能实时展示 。如果等全部响应完成才 push 到 context，用户在 LLM 思考的几秒里盯着空白屏幕。通过”先放空壳、逐 token 替换”，UI 通过 message_update 事件拿到最新部分消息，能做到逐字渲染。

工具调用

流式响应原地替换的时间线

配图说明 ：四个时间点的 context.messages[last] 演变——start 时空壳、text_delta 时文字在长、toolcall_delta 时工具调用出现、done 时最终完整消息替换。每一步同步展示 UI 显示状态。

数据在流式响应期间， context.messages[last] 的演变：

start    → { role: "assistant", content: [] }                    ← 空壳 push
text_delta → { content: [{ type:"text", text:"好的..." }] }       ← 文字在长
toolcall   → { content: [{ text:"好的..." },                        ← 工具调用出现
                         { type:"toolCall", name:"read", arguments:{file_path:"src/main.ts"} }] }
done     → { content: [...], stopReason:"toolUse", usage:{...} } ← 最终完整消息替换

4.5 【内核 · 步骤C】检查 stopReason

§三详细讲了 stopReason 的来源和含义。这里看代码怎么处理它。拿到 AssistantMessage 后，立即做一次硬停止判断：

// agent-loop.ts:196-200
if (message.stopReason === "error" || message.stopReason === "aborted") {
    await emit({ type: "turn_end", message, toolResults: [] });
    await emit({ type: "agent_end", messages: newMessages });
    return;   // ← 直接退出整个 runLoop，不检查 followUp
}

error 和 aborted 是”硬停止”——立即发 turn_end + agent_end，直接 return。连工具都不执行，连 followUp 都不检查。这是一种 快速失败 （fail fast）策略：既然模型调用本身就失败了（网络异常或用户中止），继续跑没有任何意义。

而 stop 、 toolUse 、 length 这三种，代码继续往下走——进入工具执行逻辑。区别在于： stop 和 length 时， toolCalls 数组为空，所以工具执行步骤什么也不干。

4.6 【内核 · 步骤D】executeToolCalls() — 执行工具

模型返回的 AssistantMessage.content 里，可能有多个 type === "toolCall" 的块（模型一口气要求了多个操作）。先过滤出来：

const toolCalls = message.content.filter((c) => c.type === "toolCall");

然后决定这批工具 并行还是串行 执行：

if (config.toolExecution === "sequential" || hasSequentialToolCall) {
    return executeToolCallsSequential(...);   // 串行
}
return executeToolCallsParallel(...);         // 并行

“一票否决”策略 ：只要这批工具中有 任何一个 声明了 executionMode: "sequential" ，整批都串行。为什么这么保守？因为判断”哪些工具会冲突”很难——edit 和 edit 操作不同文件就安全吗？万一它们编辑的文件有依赖关系呢？所以 Pi 选择了”宁可多等，不可出错”。而 edit 工具内部还有第二道防线（ withFileMutationQueue ，对同一文件的编辑串行化），确保即使外层判断为并行，也不会互相覆盖。

两种执行模式的内部结构：

串行模式：
  ToolCall A: 准备 → 验证 → beforeHook → 执行 → afterHook → emit end
  ToolCall B: 准备 → 验证 → beforeHook → 执行 → afterHook → emit end
  （一个完全结束，才开始下一个）

并行模式（三阶段设计）：
  阶段1 - 准备（顺序）：  A 准备 → B 准备 → C 准备
      ↑ prepareToolCall 含验证和 beforeHook，必须顺序执行
  阶段2 - 执行（并行）：  A、B、C 同时执行（Promise.all）
      ↑ 只有 tool.execute 并行，省时间
  阶段3 - 事件（有序）：  end 按完成顺序发；result 按调用顺序发
      ↑ result 消息保持和 ToolCall 一致的顺序，LLM 收到的上下文才是正确的

注意并行模式的精妙之处： 准备阶段始终顺序 （因为验证和权限检查不能并行——万一 B 被拦截了，C 就不应该执行）， 只有实际执行并行 。

每个工具的结果被包装成 ToolResultMessage ，追加到 context 和 newMessages ：

工具执行后：
  context.messages = [..., user2, assistantMessage, {
    role: "toolResult", toolCallId: "toolu_01", toolName: "read",
    content: [{ text: "文件内容..." }], isError: false
  }]

terminate 机制 ：工具可以在返回结果中设置 terminate: true ，表示”我觉得不该继续了”。但 Loop 不会因为某一个工具喊停就停——它用的是 every 而非 some ： 必须这批工具的全部结果都设置了 terminate 才真正退出 。这是保守策略：只要有一个工具还在正常工作，Loop 就不中断。

工具执行的完整五步管道（prepareArguments → Schema 验证 → beforeToolCall → execute → afterToolCall）详见《第5章：工具系统》。

4.7 【内核+叠加 · 步骤E~F】turn_end + 钩子 + 再次检查 steering

Turn 的核心工作做完了（调模型 + 执行工具），接下来是收尾。收尾分四步，其中前两步是内核，后两步是 coding-agent 叠加的扩展点：

// ① emit turn_end —— 通知外部"这一轮结束了"（内核）
await emit({ type: "turn_end", message, toolResults });

// ② prepareNextTurn —— 给外部一个机会"改装"下一轮（叠加）
// 返回值可包含 context / model / thinkingLevel 三者之一的覆盖
const nextTurnSnapshot = await config.prepareNextTurn?.({...});
if (nextTurnSnapshot) {
    currentContext = nextTurnSnapshot.context ?? currentContext;
    config.model = nextTurnSnapshot.model ?? config.model;
    // thinkingLevel 也在此处覆盖（详见 agent-loop.ts 中 prepareNextTurn 处理逻辑）
}

// ③ shouldStopAfterTurn —— 外部判断是否该停了（叠加）
if (await config.shouldStopAfterTurn?.({...})) {
    await emit({ type: "agent_end", messages: newMessages });
    return;
}

// ④ 再次检查 steering —— 有没有新的紧急消息？（叠加1）
pendingMessages = (await config.getSteeringMessages?.()) || [];

prepareNextTurn —— 这是个容易被忽略但很强大的扩展点。它在每个 turn_end 之后、下一轮开始前被调用，允许外部 动态切换下一轮的配置 。具体例子：

场景：按任务复杂度切换模型

Turn 1: 用户问了一个简单问题 → 模型用 Haiku（快、便宜）
        turn_end → prepareNextTurn 检查到问题很简单
        → 返回 { model: haiku } → 下一轮继续用 Haiku

场景：中途发现任务变复杂了

Turn 1: 用户让"重构这个模块" → Haiku 开始读文件
        turn_end → prepareNextTurn 发现要改的文件很多
        → 返回 { model: opus } → 下一轮自动切到 Opus（强、贵）

除了换模型，它还能换 context （比如注入新的上下文信息）和 thinkingLevel （思考强度）。返回 undefined 表示”什么都不换，按原配置继续”。

shouldStopAfterTurn —— 外部注入的停止判断。coding-agent 层会用它来检查上下文窗口是否快满了（快满了就停下来触发压缩），或者是否达到了最大 Turn 数限制。这是产品层的”安全阀”，最简 Loop 不需要它。

④再次检查 steering —— 一圈内层循环结束，再看看 steering 队列有没有新积攒的紧急消息。如果有，下一圈继续跑。

4.8 回到循环顶部

工具执行完且收尾结束，代码回到内层 while 循环的条件判断。§三已经详细讲了 hasMoreToolCalls 由 toolCalls 数组长度 > 0 && !terminate 驱动——这里只看代码：

while (hasMoreToolCalls || pendingMessages.length > 0)

两个条件任一为 true 就继续。 hasMoreToolCalls 由模型输出里有没有 toolCall 块（且未全部 terminate）决定（内核）， pendingMessages 由 steering 队列决定（叠加1）。两个都为 false 时，内层循环退出。

4.9 【叠加2 · 步骤G】外层循环：followUp 的续命机制

内层循环退出了——没有工具要执行，也没有紧急消息。但 coding-agent 的设计是：此时检查一下 getFollowUpMessages() ，看看系统有没有追加任务：

const followUpMessages = (await config.getFollowUpMessages?.()) || [];
if (followUpMessages.length > 0) {
    pendingMessages = followUpMessages;   // 塞进 pending，触发新 Turn
    continue;                              // 回到外层循环顶部
}
break;  // 两个队列都空了，真正退出

如果有 followUp 消息，它们被塞进 pendingMessages ， continue 回到外层循环顶部，内层循环检测到 pendingMessages 不为空， 在同一个 Trace 内 继续跑。这比重新启动一个新的 runAgentLoop() 好在哪？——连续性：同一个 newMessages 数组、同一个事件序列，不需要额外合并。

§四开头已经说过：如果你做的是简单 Agent，外层循环是多余的——内层循环退出后直接 break + emit agent_end 就行了。

4.10 steering vs followUp：一张表看清两种干预

本章出现了两种”外部消息注入”机制。虽然 §四开头已经分别介绍过，但放在一起对比更能看清它们的差异：

生活类比：steering 是你正在开会，有人敲门递了张纸条——“紧急，先看这个”。followUp 是开完会翻了翻信箱——“不急，但需要处理”。

steering vs followUp 对比

配图说明 ：左红右绿对照——steering 在每圈内层循环开头+结尾检查、紧急插队；followUp 在内层循环全部结束后检查、续命重启。底部列出各自时机/来源/影响/典型场景。

五、总结：Loop 的四条核心设计

回顾从按下回车到 Agent 完成的整段旅程：

1. ReAct 循环模式

Loop 的本质是 Reason（模型思考）→ Act（执行工具）→ Observe（观察结果）→ Reason（再次思考）的循环。模型的输出内容决定”该调什么工具”——这是 Agent 区别于 Workflow 的核心。但”什么时候停”不是模型的决策，而是我们人类定义的规则： 模型不再输出工具调用时，就认为本轮结束。

2. stopReason 驱动机制

整个循环由一个字段驱动： stopReason 。但实际驱动循环的不是 stopReason 本身，而是模型输出里有没有 toolCall 块且未全部 terminate—— "有 toolCall" = 继续转；没有 toolCall 或全部 terminate = 准备停（或立即停）。 “是否继续”不靠代码的复杂判断，只靠一条简单规则：模型的输出中有没有工具调用。 这是 Agent 架构的核心设计原则——把决策外包给模型输出模式，代码只做最简单的信号判断。

3. 内核 + 叠加的架构思路

Agent Loop 的内核极其简短——十几行代码就能实现一个能用的循环。Pi 的 coding-agent 在内核上叠加了 steering（紧急插队）、followUp（任务追加）、prepareNextTurn（动态切模型）、shouldStopAfterTurn（安全阀）等设计。 内核是所有 Agent 的通用法则，叠加是产品功能的按需选择。 做自己的 Agent 时，先搭内核，再按场景加叠加。

钩子（产品功能）

Agent Loop 内核与叠加设计

配图说明 ：从里到外的四层洋葱——最内核是最简 Loop（~10 行通用法则）；外层依次叠加 steering（紧急插队）、followUp（任务追加）、钩子（切模型/安全阀）。剥掉任何一层，里层仍能运行。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/agent/Pi%20Agent%20%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B

AgentMessage[]
    ↓ transformContext()
AgentMessage[]
    ↓ convertToLlm()
LLM Message[]
    ↓
模型 API

Session Tree + 当前输入 + system prompt + tools
                         ↓
                   AgentMessage[]
                         ↓
                 transformContext()
                         ↓
                   convertToLlm()
                         ↓
                    LLM Message[]

function truncateTail(
  content: string,
  maxLines = 2000,
  maxBytes = 50 * 1024,
) {
  const lines = content.split("\n");
  const kept: string[] = [];
  let bytes = 0;

  for (let index = lines.length - 1; index >= 0; index -= 1) {
    const line = lines[index];
    const lineBytes = byteLength(line) + 1;

    if (kept.length >= maxLines || bytes + lineBytes > maxBytes) {
      break;
    }

    kept.unshift(line);
    bytes += lineBytes;
  }

  return kept.join("\n");
}

/myorg
├── AGENTS.md                         组织级规则
└── teams
    └── team-a
        ├── CLAUDE.md                 团队规则
        └── projects
            └── app-a
                ├── AGENTS.md         项目规则
                └── src/              当前工作目录

<project_context>
  <project_instructions path="/myorg/AGENTS.md">
    组织级规则
  </project_instructions>

  <project_instructions path="/myorg/teams/team-a/projects/app-a/AGENTS.md">
    项目规则
  </project_instructions>
</project_context>

SessionHeader
├── type: "message"         user / assistant / toolResult
├── type: "compaction"
└── type: "branch_summary"

contextTokens > contextWindow - reserveTokens

## Goal
## Constraints & Preferences
## Progress
## Key Decisions
## Next Steps
## Critical Context

root
├── 方案 A
│   └── 测试发现性能不行，放弃
└── 方案 B
    └── 当前正在继续

用户输入
  ↓
buildSystemPrompt
  ├── 读取全局与项目上下文文件
  ├── 拼接工具描述和 guidelines
  └── 放入 Skills 清单
  ↓
Session Tree 根到当前叶子的路径
  ↓
AgentMessage[]
  ↓ transformContext()
按扩展或运行时策略裁剪、注入
  ↓ convertToLlm()
过滤和转换为模型消息
  ↓
LLM 返回 read("auth.ts")
  ↓
执行 read 工具
  ↓ truncateHead
最多 2000 行、50KB
  ↓
toolResult 回到 AgentMessage 历史
  ↓
下一次请求前检查上下文预算
  ├── 未到阈值，继续 Agent Loop
  └── 到达阈值，追加 CompactionEntry

在 Pi Agent 的工具系统中，工具的抽象和执行机制是整个架构的核心。本文系统梳理工具定义的三层类型、调用时的五步管道、并行执行策略，以及错误处理的特殊设计。

一、三层类型：为什么”一个工具”要分三层来定义？

在 Pi Agent 里，一个完整的工具定义被拆成了三层，目的是让不同层职责清晰、扩展性强：

第一层：Tool（一张”名片”）

这是最基础的一层，只定义工具的基本信息：

• toolName
• description
• parameters（Schema）
• 其他元数据

这一层就像工具的名片，告诉 Agent 它能做什么。

export interface Tool {
  name: string;
  description: string;
  parameters: any;
  // ...
}

第二层：AgentTool（加上了”执行能力”）

在 Tool 的基础上，添加了实际执行逻辑：

• execute 方法
• 错误处理
• 资源管理等

interface AgentTool extends Tool {
  execute: (params: any) => Promise<any>;
}

这一层是真正可以调用的工具。

第三层：ToolDefinition（产品层再加东西）

在 AgentTool 之上，添加了产品层需要的额外信息：

• 包装后的执行函数
• 前置/后置钩子
• 结果统一格式

interface ToolDefinition extends AgentTool {
  // 包装后的执行函数
  wrappedExecute: (params: any) => Promise<ToolResult>;
}

桥接两层：wrapToolDefinition

为了把第二层的执行能力桥接到第三层，Pi 提供了 wrapToolDefinition 工具：

function wrapToolDefinition(tool: AgentTool): ToolDefinition {
  return {
    ...tool,
    wrappedExecute: async (params) => {
      // 执行前置钩子
      await beforeToolCall?.(params);
      
      try {
        const result = await tool.execute(params);
        return { result, isError: false };
      } catch (err) {
        return { result: err, isError: true };
      }
    }
  };
}

为什么非要分三层？

• 职责分离：第一层只管描述，第二层管执行，第三层管包装和扩展。
• 扩展性强：想加新特性（日志、限流、缓存）时，只需要在第三层修改。
• 可组合性好：可以用不同的 wrapToolDefinition 实现不同的策略。

二、五步管道

模型调用工具时，不是直接调用一个函数，而是走了一套完整的五步管道：

第 1 步：prepareArguments —— 兼容性垫片

处理不同模型返回的参数格式（比如有些模型返回 camelCase，有些 snake_case）。

第 2 步：validateToolArguments —— Schema 验证

使用 JSON Schema 对参数进行严格验证，防止无效输入。

第 3 步：beforeToolCall —— 前置钩子（可阻止执行）

允许开发者在执行前做一些操作（比如权限检查、限流），也可以通过返回 false 来阻止执行。

第 4 步：tool.execute —— 实际执行

真正调用工具的执行逻辑（通常是第二层的 execute）。

第 5 步：afterToolCall —— 后置钩子（可修改结果）

允许开发者在执行后修改结果、添加额外信息等。

管道终点：ToolResultMessage（统一格式的消息）。

这种五步管道让工具调用更加安全、可控、可扩展。

三、并行 vs 串行：一个批次的工具不是”一起跑就完了”

模型经常一次调用多个工具（比如搜索 + 总结 + 数据库查询），但并行执行不能简单用 Promise.all。

Pi 的调度策略是一票否决：

• 并行执行三阶段设计：
  1. 准备阶段（prepare）
  2. 并行执行阶段（execute in parallel）
  3. 收尾阶段（after parallel）

如果任何一个工具执行失败，会触发一票否决，整个批次被取消并返回错误。

四、永不抛出：工具出错也是一条消息

Pi Agent 工具系统永不抛出异常到 Agent Loop，而是统一返回 ToolResult：

interface ToolResult {
  result: any;
  isError: boolean;
  errorMessage?: string;
}

6 种错误类型 + 1 种产物

工具出错时，会被包装成统一的 ToolResult，而不是直接抛出错误。

关键代码在 tool.execute 的双重防护：

• 内部主动捕获异常
• 外部框架兜底包装成消息

为什么”伪装成消息”是最佳处理方式？

因为：

• 模型最擅长处理消息格式的错误
• 错误描述越具体，模型纠错能力越强
• 避免了异常穿透到 Agent Loop，保持 Loop 的稳定性

五、【进阶】Operations 抽象：工具执行不等于系统调用

问题：如果工具直接写死系统调用（如 fs.readFile），那就很难在不同环境中复用。

解法：让工具不直接调系统 API，而是通过最小接口调用。

每个工具定义自己需要的最小接口（比如 ReadOperations），然后通过依赖注入的方式传入具体实现。

这样：

• 工具代码可以跨环境复用
• Mock 测试变得容易
• 不同 Workspace 切换时行为稳定

总结

Pi Agent 的工具架构通过三层定义 + 五步管道 + 并行调度 + 统一错误消息 + Operations 抽象，实现了高度灵活、可测试、可扩展的工具系统。

这套设计真正做到了把 Agent 的手脚管住。

在 Pi Agent 的工具系统中，Operations 抽象 是核心设计之一。它把工具的执行逻辑与具体文件系统实现解耦，让 Agent 可以在本地、SSH、Docker 等不同环境中灵活切换。

本文主要分享工具架构的核心设计思路，包括抽象接口、依赖注入、闭包固定实例，以及 Workspace 切换机制。

为什么不直接使用 Node.js fs？

很多人第一反应是直接调用 fs/promises：

await fs.access(path);
const buffer = await fs.readFile(path);

这种写法存在几个明显痛点：

• 强耦合：Tool 与具体文件系统实现绑定（本地磁盘、SSH、Docker 沙箱随便一种都行）。
• 测试困难：单元测试必须创建真实文件，Mock 成本高。
• 环境切换麻烦：一旦需要切换后端，Tool 代码几乎需要全部重写。

直观上可以理解为：

Read Tool
      ↓
Node.js fs
      ↓
本地磁盘

工具和具体实现绑定死了，这不是在给 Agent 装手脚，而是把手脚绑死在本地磁盘上了。

Operations 抽象接口

为了解决这个问题，我们定义了一个抽象接口 ReadOperations：

export interface ReadOperations {
    readFile: (absolutePath: string) => Promise<Buffer>;
    access: (absolutePath: string) => Promise<void>;
}

Tool 层只知道调用这个接口，完全不关心下面用的是 fs.readFile 还是 sshClient.readFile。

调用关系变为：

Read Tool
      │
      ▼
ReadOperations（抽象接口）
      │
      ▼
Local / SSH / Docker / Mock 等具体实现

Tool 依赖的是抽象接口，而不是具体实现。

闭包固定实例行为

在创建 Tool 时，我们通常会这样写：

function createReadTool(options?: {
    operations?: ReadOperations;
}) {
    const ops = options?.operations ?? defaultReadOperations;

    return {
        execute: async (path: string) => {
            await ops.access(path);
            return ops.readFile(path);
        }
    };
}

这里用闭包把创建时的 ops 固定在 Tool 实例上，实现了行为稳定的目的。

不管后续怎么切换 Workspace，Tool 实例的行为永远是确定的。

Workspace 切换与多环境支持

本地 Agent 用本地 Operations，SSH Agent 用 SSH Operations，切换 Workspace 时不需要修改 Tool 内部代码：

const localTool = createReadTool({ operations: localOperations });
const sshTool   = createReadTool({ operations: sshOperations });

两个 Tool 可以同时存在，互不干扰。

工具系统五步管道简述

整个工具系统可大致分为五步：

1. 定义：定义 Operations 接口
2. 注册：把具体实现注册到工具系统中
3. 拦截：可选的预处理/后处理
4. 执行：调用 Operations 实例的方法
5. 回收：清理资源或重置状态

我们重点强化了第 4 步的抽象和第 5 步的稳定性。

两层错误处理机制

工具执行时推荐采用两层错误处理：

• 第一层（工具内部主动识别）：在 execute 方法中主动捕获已知错误类型（如超时、中止、非零退出码），重新包装成具体、可读的错误描述。
• 第二层（框架兜底被动处理）：工具内部抛出的错误原样透传给框架。

这种做法能给模型提供更有价值的错误反馈。

总结：工具架构的核心思想

Pi Agent 工具架构的核心在于先抽象、再注入、最后稳定。

通过 Operations 抽象 + 依赖注入 + 闭包固定实例的方式，我们实现了：

• 环境切换的灵活性
• 测试的简易性
• 行为稳定性的保证

这样的设计让 Tool 层代码可以在不同 Workspace 间复用，同时保持了清晰的职责边界。

AIO BIO NIO区别？

BIO（同步阻塞 I/O）

BIO 是传统的 I/O 模式，全称为 Block I/O，也叫同步阻塞 I/O。在 BIO 模式下，当我们执行 I/O 操作时，比如读取文件或者网络请求，程序会 阻塞，直到 I/O 操作完成后，才能继续执行后面的代码。也就是说，当一个线程在等待 I/O 完成时，它是处于阻塞状态的，不能做其他事情。

NIO（同步非阻塞 I/O）

一个线程管理多个连接

NIO 是对传统 BIO 的改进，它全称是 Non-blocking I/O（非阻塞 I/O）。在 NIO 模式下，I/O 操作不是阻塞的，可以同时处理多个 I/O 请求。与 BIO 不同的是，NIO 使用了 Channel（通道） 和 Buffer（缓冲区） 来进行数据读写，并且它支持 多路复用，这意味着多个 I/O 操作可以共享一个线程来处理，从而大大提高了并发性能。

AIO（异步非阻塞 I/O）

AIO 是 NIO 的进一步升级，叫做 Asynchronous I/O（异步非阻塞 I/O）。在 AIO 模式下，I/O 操作是完全异步的，不需要线程阻塞等待 I/O 完成。AIO 基于事件和回调机制，当 I/O 操作完成时，系统会通知应用程序，程序就能接收到结果。

Kimi K3 的技术博客里，有一个很容易被忽略、但很关键的细节：

K3 对「思考历史」极度敏感。harness 如果没有完整传回之前的 thinking 内容，生成质量会严重不稳定。

原文大致写了两个触发条件：

1. harness 没有完整回传历史 thinking 内容
2. 会话中途从别的模型切换到 K3

博客对原因也做了解释。大多数 reasoning 模型，比如 Claude 的 extended thinking、OpenAI 的 o 系列，默认假设是：thinking 是一次性草稿纸。生成完就完成使命了，下一轮不一定需要原样保留。有服务商在服务端加密保存，有的直接允许客户端丢弃。模型训练时，就没指望「未来轮次还能看到这段草稿」。

K3 不是这样训练的。

它是在「每一轮都把之前所有轮次的完整 thinking 摆在上下文里」这个条件下训练出来的。thinking 对 K3 不是草稿纸，而是这个模型认知链条里永久的一部分。它的行为模式，建立在「我永远能看到自己之前想了什么」这个假设之上。

为什么 thinking 不能像 tool result 那样裁

这里有个很有意思的对比，可以类比 agent 上下文里的 tool result 裁剪。

tool result 之所以能被相对安全地裁剪，是因为它读完之后，语义会被显式表达进下一轮的可见回复里。原文没了，但结论已经「抄」到别处留下来了。

thinking 不是这样。

thinking block 里的推理过程，大部分时候不会被完整翻译进最终的可见回复。可见回复往往只是 thinking 里那条推理链的一个结论摘要。中间的探索、排除、纠错过程，只存在于 thinking 本身。

裁掉这部分，模型下一轮拿到的不是「浓缩后的知识」，而是真的丢了一段计算过程。它自己也不知道自己之前想过什么、排除过什么、纠正过什么。

这就是为什么后果是 “quality highly unstable”，而不是「效率下降」。

这不是 KV cache miss 那种成本问题，是模型拿到的信息本身就不完整了，是正确性问题。

从别的模型切过来，也不行

第二个触发条件更有意思。

从别的模型切到 K3，即使把 thinking 内容原样传过去，质量也会不稳定。

因为 K3 训练时看到的历史 thinking，全都是它自己生成的、符合自己训练分布的推理风格。换一个模型生成的 thinking，哪怕格式一样，推理模式和措辞习惯都不同。K3 把这段陌生风格的历史当成自己的思考去续写，容易接不上。

对做 harness 的人意味着什么

对做 agent harness 的人来说，这意味着两件事。

一是不能对 K3 用和别的模型一样的上下文压缩策略。thinking 这部分几乎不能裁。

二是模型路由天然跟 K3 冲突。简单任务用便宜模型、复杂步骤再切强模型，这种常见做法在 K3 上会出问题，因为它没有「接手一个陌生会话」的能力。

模型开源了，但用好它，几乎绑死了兼容的官方 harness。

这大概也是为什么官方会特别推荐 Kimi Code，并建议不要在会话中途切到 K3。

不是模型不够强，是它把「完整可见的自我思考历史」写进了训练假设里。这个假设一旦被 harness 破坏，表现就会立刻塌掉。

做混合检索时，会碰到一个很朴素的问题。

BM25 说某篇文档得了 18.6 分，向量检索说另一篇文档的相似度是 0.83。到底谁应该排在前面？

18.6 看起来比 0.83 大得多，但这两个数字根本不在同一把尺子上。直接相加没有意义，随手归一化又会受到查询、模型和数据分布影响。

RRF 提供了一个很省心的思路。

既然各路分数不好比较，那就不比较分数，只比较排名。

为什么混合检索需要结果融合

关键词检索和向量检索擅长的事情并不一样。

BM25 根据词项出现情况计算相关性，遇到错误码、产品型号和专有名词时很有优势。查询里明确出现 ERR_CONNECTION_RESET，包含同一字符串的文档通常应该优先返回。

向量检索比较的是语义表示。用户问「服务突然连不上了怎么办」，即使文档里没有完全相同的句子，只写了「连接被远端重置」，它也有机会把内容召回。

两路结果放在一起，覆盖面通常比单一路径更好。麻烦在于，它们返回的原始分数没有统一含义。

BM25 分数会受到词频、文档长度和索引语料影响。向量检索还可能使用余弦相似度、点积或距离，不同模型生成的分数分布也不同。

给两路分数直接设置权重，看起来简单，后面却很容易陷入反复调参。数据规模变了，Embedding 模型换了，原来的权重可能就不合适了。

RRF 绕过了这道题。

这篇是 RAG 概念专题中的排序细节，完整系列见 Ai Agent概念扫盲。

RRF 怎么计算

RRF 的全称是 Reciprocal Rank Fusion，也就是倒数排名融合。

对于文档 d，它的融合分数可以写成下面这样。

$$
score(d) = \sum{i=1}^{n} \frac{1}{k + ranki(d)} $$

rank_i(d) 表示文档 d 在第 i 路结果中的排名。排名从 1 开始。某篇文档没有出现在一路结果中时，那一路就不给它加分。

k 是平滑常数，常见取值是 60。它会削弱第一名和后面名次之间过于悬殊的差距，让多路都排得靠前的文档得到更稳定的优势。这里的 k 与检索返回数量 Top K 不同；公式和具体参数可参考 Elasticsearch 的 RRF 文档。

这里最重要的变化是，原始相关性分数消失了。

无论 BM25 返回 18.6，还是向量库返回 0.83，RRF 只问一件事，这篇文档在各自列表里排第几。

手算一个小例子

假设同一个问题得到两组结果。

BM25 的排序是 文档 A、文档 B、文档 C。

向量检索的排序是 文档 B、文档 C、文档 A。

为了让数字更容易观察，这里暂时取 k = 0。真实系统通常会使用更大的平滑常数。

文档 A 在两路中分别排第 1 和第 3，它的分数是

$$
1/1 + 1/3 = 1.3333
$$

文档 B 分别排第 2 和第 1，它的分数是

$$
1/2 + 1/1 = 1.5
$$

文档 C 分别排第 3 和第 2，它的分数是

$$
1/3 + 1/2 = 0.8333
$$

融合后的顺序是 文档 B、文档 A、文档 C。

文档 B 没有在 BM25 中拿到第一，但它在两路都很靠前，所以最终超过了只在一路占据第一的文档 A。这正是 RRF 想保留的共识。

一个可以直接运行的 Python 实现

RRF 本身并不依赖 LangChain 或向量数据库。只要手里已经有多组排序结果，几十行 Python 就能完成融合。

from collections import defaultdict

def reciprocal_rank_fusion(
    rankings: list[list[str]],
    k: int = 60,
) -> list[tuple[str, float]]:
    """Fuse ranked document lists using Reciprocal Rank Fusion."""
    if k < 0:
        raise ValueError("k must be greater than or equal to 0")

    scores: dict[str, float] = defaultdict(float)

    for ranking in rankings:
        seen_in_ranking: set[str] = set()
        for rank, document_id in enumerate(ranking, start=1):
            if document_id in seen_in_ranking:
                continue
            seen_in_ranking.add(document_id)
            scores[document_id] += 1 / (k + rank)

    return sorted(scores.items(), key=lambda item: (-item[1], item[0]))

bm25_results = ["文档A", "文档B", "文档C"]
vector_results = ["文档B", "文档C", "文档A"]

fused_results = reciprocal_rank_fusion(
    [bm25_results, vector_results],
    k=0,
)

for document_id, score in fused_results:
    print(f"{document_id}: {score:.4f}")

运行后得到

文档B: 1.5000
文档A: 1.3333
文档C: 0.8333

代码里额外处理了同一文档在一路结果中重复出现的情况。正常的检索器通常不会返回重复 ID，但在合并多个分片或自行拼装结果时，去重可以避免同一路对某篇文档重复加分。

在 LangChain 里使用 EnsembleRetriever

下面保留的是旧版 LangChain API 示例，用于理解组合方式，不表示当前版本安装后可直接运行。实际项目应按所用版本核对包名和导入路径；上面的独立 Python 实现不依赖 LangChain。

如果用 LangChain 搭混合检索，RRF 也经常不是自己手写，而是通过 EnsembleRetriever 这类组件完成。

一个典型结构是：先准备一批文档，再分别创建 BM25 检索器和向量检索器，最后把两路检索器交给 EnsembleRetriever 融合。

import jieba
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings

doc_list = [
    "人工智能是计算机科学的一个分支，致力于创造能够模拟人类智能的系统。",
    "机器学习是人工智能的一个子领域，专注于开发能从数据中学习的算法。",
    "深度学习是机器学习的一种方法，使用多层神经网络处理复杂数据。",
    "自然语言处理是人工智能的一个分支，研究计算机与人类语言的交互。",
    "智能助手如小度和天猫精灵使用自然语言处理技术理解用户指令。",
    "自动驾驶汽车利用计算机视觉和深度学习技术识别道路情况。",
    "医疗诊断系统使用机器学习分析患者数据，辅助医生做出诊断决策。",
    "大型语言模型如 GPT 和文心一言能够生成类似人类的文本内容。",
    "计算机视觉技术使机器能够理解和处理视觉信息，如图像和视频。",
    "强化学习是一种机器学习方法，通过奖励和惩罚机制让 AI 学会做决策。",
    "人工智能产业在中国快速发展，成为新的经济增长点。",
    "智能手机的普及改变了人们的生活和工作方式。",
]

def chinese_tokenizer(text):
    return list(jieba.lcut(text))

bm25_retriever = BM25Retriever.from_texts(
    doc_list,
    metadatas=[{"source": f"doc_{i}"} for i in range(len(doc_list))],
    preprocess_func=chinese_tokenizer,
)
bm25_retriever.k = 3

embeddings = HuggingFaceEmbeddings(
    model_name="../bge-large-zh-v1.5",
    model_kwargs={"device": "cpu"},
)

vectorstore = Chroma.from_texts(
    texts=doc_list,
    embedding=embeddings,
    metadatas=[{"source": f"doc_{i}"} for i in range(len(doc_list))],
    persist_directory="./chroma_db_custom_3",
)
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.5, 0.5],
)

docs = ensemble_retriever.invoke("人工智能在医疗领域的应用")
for index, doc in enumerate(docs, start=1):
    print(index, doc.page_content)

这里 BM25 更擅长直接关键词匹配，比如「深度学习」这种查询。向量检索更擅长语义相关但字面不完全一致的问题，比如「智能系统如何理解人类语言」。混合检索则希望把两者的优势放在一起。

原理上，EnsembleRetriever 会把不同检索器返回的结果做融合。它关心的是文档在各路结果中的排名，再结合权重得到最终排序。上面给 BM25 和向量检索都设置了 0.5，意思是先等权看待两路结果。

如果业务里有大量专有名词、编号和错误码，可以适当提高 BM25 的权重；如果查询更偏自然语言表达，可以提高向量检索的权重。但权重最好通过测试集评估，而不是只凭直觉。

测试时可以准备几类问题。

• 直接关键词匹配：例如「深度学习」
• 语义相关但没有完全相同关键词：例如「智能系统如何理解人类语言」
• 混合查询：例如「人工智能在医疗领域的应用」
• 有歧义的查询：例如「智能产品」

分别观察 BM25、向量检索和混合检索的结果，就能更直观看到 RRF 或加权融合到底改善了什么。

k 到底影响什么

如果 k = 0，第一名得到 1 分，第二名得到 0.5 分，第十名只得到 0.1 分。头部名次之间差距很大。

如果 k = 60，第一名约为 0.01639，第二名约为 0.01613，第十名约为 0.01429。名次仍然重要，但变化平缓了很多。

较小的 k 更强调头部名次，较大的 k 更重视多路结果共同提供的信号。60 是常见默认值，不是不可修改的定律。更稳妥的做法，是在自己的查询集上用 Recall、MRR 或 NDCG 等指标评估。

多路权重怎么处理

有些场景会更信任其中一路。例如知识库中包含大量编号和术语，BM25 的精确匹配可能比向量语义更重要。

可以给每一路增加权重。

$$
score(d) = \sum{i=1}^{n} \frac{wi}{k + rank_i(d)} $$

这样仍然绕开了原始分数尺度，只调整各路排名信号的重要程度。

不过权重越多，调参成本也会回来。没有离线评估集时，先从等权 RRF 开始，通常比凭感觉设置一堆系数更稳。

RRF 的边界

RRF 简单、鲁棒，但它并不会判断一篇文档是否真的回答了问题。

如果关键词检索和向量检索都召回了错误内容，RRF 只会把这些错误结果重新排序。它也会丢掉原始分数中的置信度信息。某一路的第一名只比第二名高一点，和高出一大截，在 RRF 里没有区别。

所以它更适合做召回结果融合，而不是替代完整的相关性判断。

常见链路会是关键词召回与向量召回并行执行，用 RRF 合并候选，再把靠前的结果交给 Cross-Encoder 或大模型做精排。RRF 负责便宜、稳定地汇总多路意见，Reranker 再仔细判断查询和文档之间的相关性。

检索系统不需要一开始就追求复杂。

当两套评分体系无法直接对话时，先让它们各自投票，再根据名次寻找共识。

这就是 RRF 最实用的地方。

这篇可以接着 Ai Agent概念扫盲 阅读。想把 ACP、A2A、LSP 和 Code Mode 一起弄清楚，可以看 工具与协议专题。

最近看 Agent 相关的项目，经常会同时碰到三个词，Function Calling、MCP 和 Skill。

它们看起来都和「让模型做事」有关，于是很容易混在一起。有人把 MCP 当成更高级的 Function Calling，也有人觉得有了 Skill 就不需要 MCP。

其实它们并不在同一层。

最简短的理解是，Function Calling 负责表达调用，MCP 负责接入能力，Skill 负责组织做事的方法。

一个让模型知道怎么开口，一个把工具接进来，一个告诉 Agent 事情应该怎么完成。

Function Calling 解决的是调用格式

大语言模型只能生成内容。哪怕它说自己要查询天气，也不会真的凭空发出网络请求。

应用需要先把可用函数的名称、用途和参数结构告诉模型。模型判断需要使用工具后，再返回一个结构化调用请求。宿主程序收到请求，执行真实函数，然后把结果放回对话。

一个简化后的工具定义可能长这样。

{
  "name": "get_weather",
  "description": "查询指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}

模型并没有亲自执行 get_weather。它只是在回答里表达「我想调用这个函数，参数是某个城市」。真正执行请求的，仍然是模型外面的程序。

所以 Function Calling 更像一种模型和程序之间的调用语言。它解决的是单次调用怎么表达，却没有规定工具该如何独立部署、怎样被发现，也不负责让同一套工具跨客户端复用。

工具只有两三个时，手动维护这些定义并不麻烦。等项目里出现几十个工具，问题就来了。每个应用都要保存一份 schema、路由代码和权限逻辑，工具接口一变，所有接入方还得跟着改。

MCP 处理的正是这一层麻烦。

MCP 解决的是能力接入

MCP 是 Model Context Protocol。它把工具、数据和提示模板包装成遵循统一协议的服务，让支持 MCP 的客户端能够连接、发现并使用这些能力。

一套 MCP 架构里，通常能看到三个角色。

• Host 是承载 Agent 的应用，负责管理连接和安全边界
• Client 位于 Host 内部，负责与某个 MCP Server 通信
• Server 暴露具体能力，例如文件读取、数据库查询或 GitHub 操作

Server 不需要了解上面连接的是哪一种模型。它只按照协议公布自己能提供什么，并响应 Client 发来的请求。

MCP Server 暴露的内容也不只有工具。

• Tools 用来执行操作，例如创建文件或调用接口
• Resources 用来提供只读上下文，例如文档、日志和数据库记录
• Prompts 用来提供可复用的提示模板

它们通过 JSON-RPC 消息交互，可以运行在本地的 stdio 连接上，也可以通过 Streamable HTTP 提供远程服务。

当 Client 连接 Server 后，会先获取能力列表，再把可调用工具转换成模型能够理解的工具定义。模型仍然产生普通的工具调用，Client 负责把请求路由到对应 Server，拿到执行结果后再交还给模型。

从模型视角看，它未必知道 MCP 存在。模型只知道眼前有一批工具可以调用。自动发现、协议转换和请求路由，都是 Host 与 Client 在外面完成的。

因此 MCP 没有取代 Function Calling。很多实现里，它反而会把 MCP 工具转换成模型原生的工具调用格式。

Function Calling 是模型如何发出调用，MCP 是外部能力怎样标准化接进来。

MCP 减少的是各应用重复维护工具接入的负担。协议接通之后，仍然需要 Host、Client、Server 和模型调用机制配合，实际操作也需要对应业务权限。架构和角色可以参考 MCP 官方说明。

Skill 解决的是工作方法

工具接进来以后，Agent 就一定能把事情做好吗？

不一定。

给一个 Agent 文件系统、终端和 GitHub 工具，只能说明它有能力读文件、跑命令、访问仓库。至于代码审查应该先看哪些文件、检查哪些风险、用什么格式交付，它仍然可能每次做得不一样。

Skill 处理的是这类问题。

一份 Skill 通常会包含名称、适用场景和详细执行说明，还可以附带脚本、参考资料与输出模板。它不是新的工具协议，更接近一份能够被 Agent 主动选择和执行的操作手册。

---
name: code-review
description: 审查代码修改，识别正确性、安全和性能问题
---

# 执行流程

1. 确认修改范围和预期行为
2. 阅读相关代码与测试
3. 运行针对性的检查
4. 按严重程度输出问题和证据

这份 Skill 没有直接提供读取文件的能力。它只规定审查应该怎样展开。真正读取文件时，Agent 仍然需要使用本地工具或 MCP Server 暴露的能力。Skill 中声明要使用某工具，也不会自动授予执行权限。格式与渐进式加载可以参考 Agent Skills 规范。

所以可以把两者记成一句话。

MCP 让 Agent 有工具可用，Skill 让 Agent 知道怎样把工具组合起来完成任务。

三者怎样一起工作

用一次代码审查就能把整条链路串起来。

用户要求 Agent 审查一批代码修改。Agent 先从可用 Skill 的名称和描述中，发现 code-review 与任务匹配，于是加载它的完整说明。

Skill 要求先确认修改范围。Agent 随后选择 GitHub MCP Server 提供的变更读取工具。模型通过 Function Calling 生成工具名和参数，MCP Client 把调用转发到 Server，再把返回的 diff 送回模型。

接下来，Skill 要求检查测试。Agent 又通过文件系统工具读取相关测试文件，并调用终端运行测试命令。

等证据收集完毕，Agent 按 Skill 规定的严重程度和格式输出报告。

这一次任务里，三者各自做了不同的事。

• Function Calling 表达每一次工具调用
• MCP 负责发现、连接和路由外部能力
• Skill 决定完整任务的步骤、标准与交付形式

少一个都还能运行，但完成度会不一样。只有 Function Calling，工具接入容易散落在各个项目里。只有 MCP，Agent 有很多工具，却不一定有稳定的方法。只有 Skill，流程写得再清楚，没有真实工具也做不了事。

Skill 为什么要渐进式加载

Skill 还能携带脚本、模板和参考文档。如果 Agent 启动时把所有内容一次性塞进上下文，很快就会浪费大量 token，真正的任务信息反而被挤到角落。

更合理的方式是逐层加载。

Agent 启动时只看到每个 Skill 的名称和简介。任务到来后，它只加载匹配 Skill 的完整说明。执行到确实需要某份模板、脚本或参考资料时，再读取对应文件。

这有点像查手册。开始时只看目录，确定需要哪一章后再读正文，遇到具体表格时才翻到附录。不是知道得越多越好，而是在正确的时刻拿到正确的信息。

这个设计看起来只是节省上下文，实际上还在减少干扰。无关规则越少，Agent 越容易把注意力放在当前任务上。

Skill 真正解决的是「重复贴 prompt」的问题。

比如每次让 AI 做代码审查，都要重新说明检查安全漏洞、性能问题、边界条件和输出格式。一个人复制粘贴还勉强能忍，团队里每个人都手写一份标准时，质量就会开始漂移：有人漏掉安全检查，有人格式不统一，有人还在使用旧版规范。

Skill 把这些反复使用的指令、流程、脚本和模板放进一个可维护的文件夹里。一个成熟的 Skill 通常不只是几句提示词，而是有明确的结构。

code-review/
├── SKILL.md
├── scripts/
│   └── check_security.py
├── references/
│   └── review_standards.md
└── assets/
    └── report_template.md

SKILL.md 是核心说明，顶部用 frontmatter 写名称和描述，正文写执行步骤。scripts 可以放自动化脚本，references 放参考资料，assets 放报告模板或其他资源。

这样 Agent 不只是拿到一句「帮我审查代码」，而是拿到一整套可复用的工作方法。需要读文件时，它可以调用 MCP 或本地文件工具；需要安全扫描时，它可以运行 Skill 自带脚本；需要交付结果时，它可以套用 Skill 里的模板。

所以「MCP + Skill」经常会一起出现：MCP 让 Agent 有手，Skill 让 Agent 有操作手册。

实际接入时是什么感觉

我自己理解 MCP，最直观的一点是：它把原来散落在项目里的工具对接，变成了「配置一个 Server，然后让客户端发现它」。

比如在 Claude Desktop 里配置文件系统或 GitHub MCP Server，通常是在配置文件里加上 Server 的启动方式和参数。客户端启动后会连接这些 Server，读取它们暴露的工具列表，然后在对话中按需调用。

开发者不需要在每个对话里手写「read_file 这个函数怎么定义」「GitHub issue 这个接口怎么传参」。这些能力由 MCP Server 标准化提供，Host 负责发现和接入，模型只看到最终可用的工具。

这就是 MCP 和普通 Function Calling 最大的区别：Function Calling 更像一次调用的格式，MCP 更像工具服务的注册、发现和复用机制。

再把边界说清楚

理解这三个概念，关键不是背定义，而是看清它们分别负责哪一段链路。

Function Calling 位于模型与宿主程序之间，让调用能够被结构化表达。

MCP 位于应用与外部能力之间，让工具和数据能够被发现、连接与复用。

Skill 位于任务与执行过程之间，把经验沉淀成可以重复使用的工作方法。

它们不是三个互相争位置的方案，而是一套 Agent 系统里可以同时存在的三层能力。

模型会不会调用，工具能不能接入，任务做得是否稳定。

这三件事，终于可以分开看了。

本文侧重错误治理。完整的资料准备、分块、Embedding、BM25、重排和 GraphRAG，可以先读 RAG 概念专题；整个系列入口是 Ai Agent概念扫盲。

大模型最麻烦的时刻，不是它说不知道。

而是它给出一个语气笃定、结构完整、甚至带着出处的答案，等你真的去查，才发现内容根本不存在。

这种现象通常被叫作幻觉。

模型不是在主观撒谎。它的核心任务是根据上下文预测接下来最可能出现的内容。当可靠信息不足时，它仍然可能生成语言上非常合理的答案。读起来顺，不等于事实正确。

所以减少幻觉，不能只靠一句「请不要胡编」。更有效的思路是让模型有依据可用，在依据不足时允许拒答，并让最终结论能够被检查。

普通使用时，先缩小回答空间

问题越开放，模型自由发挥的空间越大。

直接问「介绍一下这个项目」，模型可能自行补充作者、时间线和功能。把要求改成「只根据下面提供的 README，总结项目功能，材料没有提到的信息请标为未知」，回答边界会清楚很多。

一个实用的提示可以包含三件事。

只根据我提供的资料回答。
资料没有覆盖的内容，请明确说不知道，不要补充猜测。
每个关键结论后标出对应的资料片段或编号。

它不能保证模型绝不出错，但能把「自由生成」变成「有边界的整理」。

还可以要求模型把事实、推断和建议分开。事实必须来自材料，推断要说明推理过程，建议则明确标注为建议。三类内容混在一起时，读者很容易把模型的推测当成已经发生的事实。

要求来源，但不要盲信来源

让模型给出处是个好习惯，不过这里还有一个坑。

模型可能连引用也一起编出来。一个看起来很像论文标题的字符串，一组格式规整的作者与年份，都不能自动成为可信证据。

真正有用的是可访问、可定位、能支持当前结论的来源。看到链接后，还要确认页面是否存在、原文是否真的表达了同一件事，以及信息是否已经过时。

医疗、法律、金融和生产环境操作等高风险问题，更不能只看答案写得像不像。至少应该回到官方文档、法规原文或权威机构材料核对。

语言模型很擅长生成「像答案的文本」，验证环节负责判断它是不是答案。

RAG 能降低幻觉，但不会自动消灭幻觉

在应用系统里，常见方案是 RAG，也就是检索增强生成。

用户提出问题后，系统先从知识库中检索相关内容，再把这些内容与问题一起交给模型。模型不必只靠训练阶段记住的知识回答，而是可以参考当前资料。

这对私有知识和频繁更新的信息很有帮助。产品文档更新后，只要重新建立索引，就能让后续回答使用新版本内容，不需要为了每一次文档变化重新训练模型。

可问题并没有到这里结束。

RAG 自己也会产生新的失败路径。

检索器可能没有找到真正相关的文档，也可能召回一堆表面相似但回答不了问题的内容。文档找对了，模型还可能脱离材料继续推断。材料之间互相冲突时，模型也可能悄悄选择其中一份，却不告诉用户冲突存在。

于是系统治理需要覆盖整条链路，而不只是 Prompt。

第一道防线是检索质量

如果交给模型的上下文本身就是错的，后面写再严格的指令也很难救回来。

知识库需要选择合适的切分方式。块太小，完整语义会被切断。块太大，又容易混入很多无关信息。关键词检索适合精确术语，向量检索擅长语义相似，两者可以组合召回，再通过 RRF 一类方法融合结果。

召回之后，还可以使用 Reranker 对查询和候选文档做更细的相关性判断。检索指标也应该单独评估，例如观察正确资料是否进入 TopK，而不是只看模型生成的文字是否顺畅。

这一步不够显眼，却决定了模型手里到底拿到了什么。

第二道防线是低置信度拒答

很多系统最大的错误，是无论检索结果多差，都要求模型必须回答。

如果多个结果无法覆盖问题，系统可以直接说明资料不足。经过验证的相关性阈值也可以作为信号，但相似度或重排分数不自动等于答案正确概率。拒答是在表达证据边界。

阈值也不能拍脑袋设置。太高会让系统频繁拒绝本来能回答的问题，太低又拦不住无关材料。可以准备一组包含可回答和不可回答问题的验证集，观察不同阈值下的误答率与拒答率，再选择能够接受的平衡点。

允许模型说不知道，往往比教它把每句话写得更肯定重要。

第三道防线是生成约束

检索结果合格后，Prompt 仍然需要给出清楚边界。

可以要求模型只使用提供的上下文，资料不足时返回固定状态，并让每条结论携带来源编号。结构化输出也能让程序更容易检查结果。

{
  "answer": "根据资料生成的回答",
  "citations": ["doc-3#chunk-8"],
  "supported": true
}

这里的 supported 不该完全听模型自我判断。系统仍然需要检查引用 ID 是否存在、引用片段是否进入过上下文，并在必要时验证结论与证据是否一致。

Prompt 是约束，不是安全边界。真正稳定的系统要把能用程序检查的部分留给程序。

第四道防线是引用核查

答案生成后，可以逐条检查关键声明。

最基础的检查，是确认每个引用都对应真实 chunk。再往前一步，可以把单条结论与引用片段交给一个核查模型，判断证据是否支持结论。如果证据只覆盖一半，就删除未被支持的部分，或者把答案降级成不确定表述。

核查模型也可能犯错，所以它更适合当第二道筛网，而不是绝对裁判。对特别重要的操作，还可以要求人工确认后再执行。

一个成本更低的策略，是只核查日期、数字、名称、因果关系和操作指令等高风险声明。没必要给每一句自然语言都增加一次模型调用。

如果把这些方法收束成工程实践，我会优先看四个方向。

第一是 Prompt 强约束。明确告诉模型只能根据提供的资料回答，资料里没有就说不知道，不要为了完整性补充猜测。

第二是检索质量门控。Rerank 分数或相关性分数低于阈值时，系统直接拒答，避免模型在低质量上下文上硬撑。

第三是生成后引用核查。每个关键声明都要能在 chunk 里找到来源依据，找不到就删除、降级或标为不确定。

第四是结构化输出强制溯源。比如让模型输出 JSON，每条结论附上来源编号，方便程序继续检查引用是否存在、证据是否进入过上下文。

作为一个实现起点，可以先做 Prompt 强约束和经过验证的检索质量门控。前者减少模型自由发挥，后者减少系统把低质量材料交给模型的概率。实际成本、效果和需要的核查层次，仍要通过自己的问题集验证。

评估时不要只看答案好不好读

生成质量很容易被语言流畅度迷惑。

一个更实用的测试集，应该同时包含知识库中有答案的问题、只有部分答案的问题、完全没有答案的问题，以及资料彼此冲突的问题。

然后分别观察几件事。

• 正确资料有没有被召回
• 没有证据时系统会不会拒答
• 答案中的声明能否在引用里找到
• 引用是否真的支持对应声明
• 更新知识库后，旧答案是否及时失效

只有把检索、生成和引用拆开测，才知道错误到底发生在哪里。否则看到一个错误答案，很难判断是检索没找到、排序排错了，还是模型拿到正确资料后仍然编了内容。

没有一种办法能把幻觉降到零

提示词约束有用，RAG 有用，Reranker 和引用核查也有用。但它们都不是「安装以后永不出错」的开关。

更可靠的系统，往往不是让模型显得无所不知，而是认真处理不知道的时刻。

有资料就引用资料，证据不足就降低语气，超出边界就明确拒答，高风险结论再交给人确认。

模型负责生成，系统负责约束，使用者负责判断。

把这三层责任分清楚，幻觉才会从一个模糊的模型缺陷，变成可以逐步治理的工程问题。

cookie、session、token

cookie
服务端发给客户端，交给客户端保存的数据，每次请求，客户端带上这些数据，服务端就读取这些数据，鉴别身份。
完全由客户端存储，和域名绑定，且不可跨域。
数据大小一般有限制。
容易被伪造，且客户端清除数据就丢失了

session
服务端将客户端的信息保存在服务端，然后将一个sessionId传给客户端，客户端保存起来，下次请求携带sessionId，服务端就通过id找到客户端的身份数据。
真正的数据存储在服务端，数据安全，且数据格式由服务端自定义。
sessionId一般客户端通过cookie的形式存储起来，也有可能通过URL拼接来传递（防止浏览器不支持cookie）。

token
将数据进行加密后，交给客户端存储，客户端每次请求携带这个数据，服务端解密，读出数据。
最常见的实现就是JWT令牌
客户端一般也是通过cookie存储
支持跨域，只要数据能正确解密出来就没问题

总结
可以看到，这三个东西并不是对立的，一般cookie作为底层技术支撑session和token的实现，而session和token的区别主要就在于，session是把数据存在服务端，而token是把数据加密起来交给客户端存储。

MySQL锁

全局锁：

flush tables with read lock，执行此条命令，整个数据库处于只读状态
unlock tables， 释放全局锁，会话断开时，也会自动释放全局锁

一般用来全库逻辑备份

表级锁：MySQL 里面表级别的锁有这几种：

• • 表锁：通过lock tables 语句可以对表加表锁，表锁除了会限制别的线程的读写外，也会限制本线程接下来的读写操作。
  • 元数据锁：当我们对数据库表进行操作时，会自动给这个表加上 MDL，对一张表进行 CRUD 操作时，加的是 MDL 读锁；对一张表做结构变更操作的时候，加的是 MDL 写锁；MDL 是为了保证当用户对表执行 CRUD 操作时，防止其他线程对这个表结构做了变更。
  • 意向锁：当执行插入、更新、删除操作，需要先对表加上「意向独占锁」，然后对该记录加独占锁。意向锁的目的是为了快速判断表里是否有记录被加锁。

行级锁：InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁。

记录锁(Record Lock)

• 锁住某行记录，分为读写锁，事务提交后自动释放，例如select * from table_name where id = 1 for update;就给id=1这行记录上了写锁

间隙锁(Gap Lock)

• 锁住行与行之间的间隙，防止其它事务在间隙中插入数据，产生幻读，间隙锁是不互斥的（如果涉及到记录锁或者临键锁，还是会互斥阻塞），两个事务可以拥有同一段间隙的间隙锁，但要插入数据时发现这段间隙被其它事务锁上了就插不了了。间隙锁是为了解决幻读，防止其它事务在区间内插入数据

临键锁(Next-Key Lock)

• 间隙锁 + 记录锁，加临键锁的时候是先加间隙锁，后加记录锁，这就有可能出现加间隙锁能成功，加记录锁被阻塞，然后间隙锁与其它事务发生死锁
• 前开后闭区间，锁住某行以及这一行之前的间隙，如(1, 3]，锁住3这一行和1到3行之间的间隙，因为有记录锁，会产生读写互斥，间隙锁之间不互斥

插入意向锁：

• 插入意向锁是一个间隙锁，但这个间隙锁实际上锁住的不是一个区间，而是区间中插入的那个点，所以算是一种特殊的间隙锁，插入意向锁和插入意向锁会互斥，即两个事务可以在同一个区间插入，但不能在同一个区间上相同的点插入；插入意向锁与间隙锁互斥，即插入的点所处的区间不能被其它事务的间隙锁锁住

加锁算法

抛开隔离级别谈加锁，都是耍流氓。
InnoDB 的加锁行为必须结合事务隔离级别来理解。

一、读未提交（Read Uncommitted）

• 增（INSERT）
  插入成功后，对新插入的记录加 记录锁，防止其他事务修改该记录。
• 删（DELETE）
  需要获取待删除记录的 记录锁，
  保证删除过程中其他事务无法使用该记录，且删除后不能再对其进行操作。
• 改（UPDATE）
  对需要修改的记录加 记录锁。
• 查（SELECT）
  • 普通 SELECT：不上锁，直接读取最新数据（包括未提交的数据）。
  • SELECT ... FOR UPDATE / SELECT ... LOCK IN SHARE MODE：
    仅加 记录锁，不加间隙锁。

二、读已提交（Read Committed）

• 增（INSERT）
  插入后对新记录加 记录锁。
• 删（DELETE）
  对目标记录加 记录锁，保证删除过程的安全性。
• 改（UPDATE）
  对被修改的记录加 记录锁。
• 查（SELECT）
  • 普通 SELECT：不上锁，通过 MVCC 读取已提交的数据。
  • SELECT ... FOR UPDATE / SELECT ... LOCK IN SHARE MODE：
    仅加 记录锁，不锁间隙。

三、可重复读（Repeatable Read，InnoDB 默认）

• 增（INSERT）
  • 插入时使用 插入意向锁。
  • 插入完成后，记录会被加上 记录锁（隐式锁，非立即可见）。
• 删（DELETE）
  对删除范围加 临键锁（Next-Key Lock），
  防止其他事务在该区间内插入新记录。
• 改（UPDATE）
  对目标记录加 临键锁。
• 查（SELECT）
  • 普通 SELECT：不上锁，通过 MVCC 读取快照数据。
  • SELECT ... FOR UPDATE / SELECT ... LOCK IN SHARE MODE：
    加 临键锁，同时锁记录和间隙。

四、串行化（Serializable）

• 增（INSERT）
  使用 插入意向锁，插入完成后记录被加上 记录锁。
• 删（DELETE）
  对删除区间加 临键锁，防止其他事务插入。
• 改（UPDATE）
  对修改范围加 临键锁。
• 查（SELECT）
  • 普通查询会 自动转化为
    SELECT ... LOCK IN SHARE MODE，
    对读取范围加 临键锁，锁定间隙。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8%E4%B8%8E%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6%E7%AE%97%E6%B3%95

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/%E7%B1%BB%E5%8A%A0%E8%BD%BD%E6%9C%BA%E5%88%B6%E4%B8%8E%E7%B1%BB%E5%8A%A0%E8%BD%BD%E5%99%A8

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E6%95%B0%E6%8D%AE%E5%BA%93/MySQL%E7%9A%84MVCC

SpringMVC执行流程

请求先到 DispatcherServlet（前端控制器），它负责调度 HandlerMapping → HandlerAdapter → Controller → ViewResolver → View。

Spring MVC 采用前端控制器模式，所有请求先进入 DispatcherServlet。DispatcherServlet 通过 HandlerMapping 找到对应的 Controller，再通过 HandlerAdapter 调用方法执行。Controller 返回结果后，如果是视图名则交给 ViewResolver 解析并渲染视图；如果是 @ResponseBody，则通过 HttpMessageConverter 转换为 JSON 返回给客户端。

SpringMVC是什么?

Spring MVC 是 Spring 提供的一个基于 MVC 设计模式的 Web 框架，通过 DispatcherServlet 作为前端控制器，结合 HandlerMapping、HandlerAdapter 等组件完成请求的分发和处理，支持注解方式开发，能够方便地实现请求参数绑定和响应结果返回。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E6%95%B0%E6%8D%AE%E5%BA%93/MySqL%E4%BA%8B%E5%8A%A1%E7%89%B9%E6%80%A7%EF%BC%8C%E9%9A%94%E7%A6%BB%E7%BA%A7%E5%88%AB

Redis的压缩列表ziplist到紧凑列表listpack

ziplist 的结构（老版本用的）

大概长这样：

[zlbytes][zltail][zllen][entry1][entry2]...[entryN][0xFF]
● *zlbytes*，记录整个压缩列表占用对内存字节数；
● *zltail*，记录压缩列表「尾部」节点距离起始地址由多少字节，也就是列表尾的偏移量；
● *zllen*，记录压缩列表包含的节点数量；
● *0xFF*，标记压缩列表的结束点，固定值 0xFF（十进制255）。

每个 entry 里：

[prevlen][encoding][data]

• prevlen：前一个 entry 的长度（1 或 5 字节）
• encoding：当前 entry 是字符串还是整数，长度是多少
• data：真正的数据

listpack 的结构（新版本用的）

大概长这样：

[total_bytes][count][entry1][entry2]...[entryN][0xFF]
total_bytes：整个 listpack 的总字节数
count：entry 的个数（元素数量）
● *0xFF*，标记压缩列表的结束点，固定值 0xFF（十进制255）。

每个 entry 里：

[encoding+len][data][backlen]
[encoding+len]：
1.数据类型（string/int…）
2.字符串长度（完整长度信息）
3.如果长度太长，encoding 会表示“后面几个字节继续存长度”
backlen ：当前整个 entry 的总字节数

注意两点变化：

1. 没有 prevlen 了（不再依赖“记录前一个元素长度”来反向遍历）
2. 多了 backlen（记录自己的完整长度，用来从后往前遍历）

这是 ziplist 被吐槽最多的一个点：级联更新（cascading update）。

1.ziplist 的问题

• 每个 entry 前面有个 prevlen 字段，记录 前一个 entry 的长度
• prevlen 自身可能是 1 字节 或 5 字节
  • 如果前一个 entry 变大了，从 253 → 300 字节
  • 起初 prevlen = 1 字节，现在需要 5 字节
• 那么：
  • 当前 entry 要扩展 4 字节
  • 它变长后，下一个 entry 的 prevlen 又可能从 1 → 5
  • 如此继续……导致后面一串 entry 都要重写、搬移内存

结果就是：某个元素变长，可能触发 O(N) 的连锁内存搬移，列表越大越惨，而且实现特别绕，也容易出 bug。

2.listpack 如何改进？

• listpack 不再在每个元素开头放 prevlen
• 改为在 元素末尾 放一个 backlen，记录这个元素自己的长度
• 反向遍历时：
  • 从尾开始，先读 backlen → 退回去这么多字节 → 得到前一个元素起始位置

这样改的一个好处是：

• 你修改某个元素的长度时，只需要考虑它自己的 backlen
• 不会像 ziplist 那样，影响后面每一个元素的 prevlen 字段

虽然单个元素变长还是需要移动后面的内存，但不会再产生那种“级联字段变化”的连环改动，整体逻辑简单且更可控。

3. 存储编码更紧凑，节省内存

listpack 是在 ziplist 的经验基础上重新设计的，目标就是：

“既要省内存，又要减少复杂边界情况”

主要变化：

1. 编码种类更合理
   • 对整数、短字符串等使用多种变长编码方案
   • 比 ziplist 更灵活、更紧凑
2. 去掉多余的头部字段
   • ziplist 有 zltail 等字段
   • listpack 头部只保留对操作真正有用的字段（总字节数、元素数），结构更轻量
3. 统一整数/字符串编码格式
   • 在不同模块（hash、zset、list）里都可以复用 listpack
   • 更利于代码维护和优化

总体效果：在很多实际场景中，listpack 比 ziplist 更省内存，尤其是大量小元素时。

4. 性能与安全性方面的改进

① 性能

• 减少了级联更新的问题，尤其是修改中间元素时更稳定
• 更简单的编码与解析逻辑，有利于编译器优化、CPU cache 命中

② 安全性

ziplist 曾经出过多次 整数溢出 / 越界 的安全漏洞（CVE），原因之一就是：

• 设计偏复杂，各种长度字段 + 级联更新
• 很难做到所有边界都不出错

listpack 从设计上就尽量：

• 简化字段
• 减少依赖“前一个元素长度”的逻辑
• 更好地检查长度合法性

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/HotSpot%20%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

Redis网络模型（io多路复用）

阻塞IO(Blocking IO)

假设服务端只开启一个线程处理请求，第一个请求到来，开始调用内核read函数，然后就会发生阻塞，第二个请求到来时服务端将无法处理，只能等第一个请求读取完成。这种方式的缺点很明显，每次只能处理一个请求，无法发挥cpu多核优势，性能低下。

为了解决这个问题，我们可以引入多线程，这样就可以同时处理多个请求了，但服务端可能同时有成千上万的请求需要处理，随之而来的是线程数膨胀，频繁创建、销毁线程带来的性能影响，当然我们可以使用线程池，但服务能处理的总体数量就会受限于线程池线程数量。

非阻塞IO(NON-Blocking IO)

相比阻塞IO，非阻塞IO会立即返回，调用者不会阻塞，此时可以做一些其它事情，例如处理其它请求。但是非阻塞IO需要主动轮询是否有数据需要处理，且这种轮询需要从用户态切换到内核态这，假如没有数据产生就会有很多空轮询，白白浪费cpu资源。

阻塞IO、非阻塞IO，要么需要开启更多线程去处理IO，要么需要从用户态切换到内核态轮询IO事件，那么有没有一种机制，用户程序只需要将请求提交给内核，由内核用少量的线程去监听，有事件就通知用户程序呢？这就是IO多路复用。

IO多路复用(IO Multiplexing)

IO多路复用机制是指一个线程处理多个IO流，多路是指网络连接，复用指的是同一个线程。
如果简单从图上看IO多路复用相比阻塞IO似乎并没有什么高明之处，假设服务只处理少量的连接，那么相比阻塞IO确实没有太大的提升，但如果连接数非常多，差距就会立竿见影。
首先IO多路复用会提交一批需要监听的文件句柄（socket也是一种文件句柄）到内核，由内核开启一个线程负责监听，把轮询工作交给内核，当有事件发生时，由内核通知用户程序。这不需要用户程序开启更多的线程去处理连接，也不需要用户程序切换到内核态去轮询，用一个线程就能处理大量网络IO请求。
redis底层采用的就是IO多路复用模型，实际上基本所有中间件在处理网络IO这一块都会使用到IO多路复用，如kafka,rocketmq等，所以本次学习之后对其它中间件的理解也是很有帮助的。

select/poll/epoll

linux最开始提供的是select函数，方法如下：

select(int nfds, fd_set *r, fd_set *w, fd_set *e, struct timeval *timeout)

该方法需要传递3个集合，r,e,w分别表示读、写、异常事件集合。集合类型是bitmap，通过0/1表示该位置的fd(文件描述符，socket也是其中一种)是否关心对应读、写、异常事件。例如我们对fd为1和2的读事件关心，r参数的第1,2个bit就设置为1。

用户进程调用select函数将关心的事件传递给内核系统，然后就会阻塞，直到传递的事件至少有一个发生时，方法调用会返回。内核返回时，同样把发生的事件用这3个参数返回回来，如r参数第1个bit为1表示fd为1的发生读事件，第2个bit依然为0，表示fd为2的没有发生读事件。用户进程调用时传递关心的事件，内核返回时返回发生的事件。

select存在的问题：

1. 大小有限制。为1024，由于每次select函数调用都需要在用户空间和内核空间传递这些参数，为了提升拷贝效率，linux限制最大为1024。
2. 这3个集合有相应事件触发时，会被内核修改，所以每次调用select方法都需要重新设置这3个集合的内容。
3. 当有事件触发select方法返回，需要遍历集合才能找到就绪的文件描述符，例如传1024个读事件，只有一个读事件发生，需要遍历1024个才能找到这一个。
4. 同样在内核级别，每次需要遍历集合查看有哪些事件发生，效率低下。

poll函数对select函数做了一些改进

poll(struct pollfd *fds, int nfds, int timeout)

struct pollfd {
int fd;
short events;
short revents;
}

poll函数需要传一个pollfd结构数组，其中fd表示文件描述符，events表示关心的事件，revents表示发生的事件，当有事件发生时，内核通过这个参数返回回来。

poll相比select的改进：

1. 传不固定大小的数组，没有1024的限制了（问题1）
2. 将关心的事件和实际发生的事件分开，不需要每次都重新设置参数（问题2）。例如poll数组传1024个fd和事件，实际只有一个事件发生，那么只需要重置一下这个fd的revent即可，而select需要重置1024个bit。

poll没有解决select的问题3和4。另外，虽然poll没有1024个大小的限制，但每次依然需要在用户和内核空间传输这些内容，数量大时效率依然较低。

这几个问题的根本实际很简单，核心问题是select/poll方法对于内核来说是无状态的，内核不会保存用户调用传递的数据，所以每次都是全量在用户和内核空间来回拷贝，如果调用时传给内核就保存起来，有新增文件描述符需要关注就再次调用增量添加，有事件触发时就只返回对应的文件描述符，那么问题就迎刃而解了，这就是epoll做的事情。

epoll对应3个方法

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_create负责创建一个上下文，用于存储数据，底层是用红黑树，以后的操作就都在这个上下文上进行。
epoll_ctl负责将文件描述和所关心的事件注册到上下文。
epoll_wait用于等待事件的发生，当有有事件触发，就只返回对应的文件描述符了。

select 底层是位图数组，限制就是会被数组长度限制，只有1024大小，内核轮询这个事件是否就绪，如果有的话内核态会把用户态的参数拷进内核空间然后检测每个的状态，select() 返回时，内核会把修改后的 fd_set（就绪标记）拷回用户空间，这样子的开销是比较大的，每次都需要扫描，拷贝。

poll底层的话是个链表，他的话解决了select的大小限制问题，但是还是没有解决用户态与内核态之间的问题

epoll的话他底层是个红黑树，他有三个函数，creat，ctl，wait，他的改进是用户在修改的时候，内核会把信息拷入内核数据结构，当内核返回就绪事件时候，epoll_wait会把准备好的事件批量拷贝到用户提供的缓冲区

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/ConcurrentHashMap%E5%BA%95%E5%B1%82%E5%8E%9F%E7%90%86

什么是 IoC?

IoC （Inversion of Control ）即控制反转/反转控制。它是一种思想不是一个技术实现。描述的是：Java 开发领域对象的创建以及管理的问题。

例如：现有类 A 依赖于类 B

• 传统的开发方式 ：往往是在类 A 中手动通过 new 关键字来 new 一个 B 的对象出来
• 使用 IoC 思想的开发方式 ：不通过 new 关键字来创建对象，而是通过 IoC 容器(Spring 框架) 来帮助我们实例化对象。我们需要哪个对象，直接从 IoC 容器里面去取即可。

从以上两种开发方式的对比来看：我们 “丧失了一个权力” (创建、管理对象的权力)，从而也得到了一个好处（不用再考虑对象的创建、管理等一系列的事情）

为什么叫控制反转?

• 控制 ：指的是对象创建（实例化、管理）的权力
• 反转 ：控制权交给外部环境（IoC 容器）

IoC 解决了什么问题?

IoC 的思想就是两方之间不互相依赖，由第三方容器来管理相关资源。这样有什么好处呢？

1. 对象之间的耦合度或者说依赖程度降低；
2. 资源变的容易管理；比如你用 Spring 容器提供的话很容易就可以实现一个单例

IOC和DI的区别？

IoC（控制反转, Inversion of Control） 是一种设计思想/原则：把对象的控制权（创建、生命周期、依赖获取等）从应用程序代码中“反转”到框架或容器。也就是说：不是对象去主动创建或查找依赖，而由外部容器来负责提供（控制）这些依赖。

DI（依赖注入, Dependency Injection） 是实现 IoC 的一种具体技术/方式——把依赖（对象）“注入”到目标对象中。常见注入方式：构造器注入、Setter 注入、字段注入。

IoC 是设计思想，DI 是具体的实现方式；

IoC 是理论，DI 是实践；

Bean 的生命周期

第一个阶段是实例化。Spring 容器会根据 BeanDefinition，通过反射调用 Bean 的构造方法创建对象实例。如果有多个构造方法，Spring 会根据依赖注入的规则选择合适的构造方法。

第二阶段是属性赋值。这个阶段 Spring 会给 Bean 的属性赋值，包括通过 @Autowired、@Resource 这些注解注入的依赖对象，以及通过 @Value 注入的配置值。

第三阶段是初始化。这个阶段会依次执行：

• @PostConstruct 标注的方法
• InitializingBean 接口的 afterPropertiesSet 方法
• 通过 @Bean 的 initMethod 指定的初始化方法

第四阶段是使用 Bean。比如我们的 Controller 调用 Service，Service 调用 DAO。

最后是销毁阶段。当容器关闭或者 Bean 被移除的时候，会依次执行：

• @PreDestroy 标注的方法
• DisposableBean 接口的 destroy 方法
• 通过 @Bean 的 destroyMethod 指定的销毁方法

项目启动时Spring的IoC会做什么？

第一件事是扫描和注册 Bean。IoC 容器会根据我们的配置，比如 @ComponentScan 指定的包路径，去扫描所有标注了 @Component、@Service、@Controller 这些注解的类。然后把这些类的元信息包装成 BeanDefinition 对象，注册到容器的 BeanDefinitionRegistry 中。这个阶段只是收集信息，还没有真正创建对象。

第二件事是 Bean 的实例化和注入。这是最核心的过程，IoC 容器会按照依赖关系的顺序开始创建 Bean 实例。对于单例 Bean，容器会通过反射调用构造方法创建实例，然后进行属性注入，最后执行初始化回调方法。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/HashMap

// oldCap 一定是 2 的幂，比如 16(10000b)
if ((hash & oldCap) == 0) {
    // 这位是 0：留在原来的 index
    newIndex = oldIndex;
} else {
    // 这位是 1：去到 index + oldCap
    newIndex = oldIndex + oldCap;
}

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/java/Volatile%E5%8E%9F%E7%90%86

MySQL 联合索引的最左匹配原则

执行计划基础知识

possible_keys：可能用到的索引

key：实际用到的索引

type:

1. ref：当通过普通的二级索引列与常量进行等值匹配的方式 询某个表时
2. const：当我们根据主键或者唯一得二级索引列与常数进行等值匹配时，对单表的访问方法就是 const
3. range:如果使用索引获取某些单点扫描区间的记录。
4. index：当可以使用覆盖 ，但需要扫描全部的索引记录时。

Extra:

1. Using index 索引覆盖
2. Using Where 当某个搜索条件需要在 server 层进行判断时
3. Using index for skip scan 跳跃扫描
4. Using index condtion 索引下推

最左匹配原则

最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。

比如有联合索引 [a、b、c]，where 过滤条件中哪些排列组合可以用到索引？（比如这种：where a=xxx b=xxx and c=xxx）

以下排列组合都会走索引： a、ab、ac、ba、ca、abc、acb、bac、bca、cab、cba。 必须有一个 a，排列组合中的顺序会被优化器优化，所以不用关心顺序。

以下排列组合不会走索引： b、c、bc、cb。 因为没有 a。

关于范围查询： a=xxx and b<10 and b > 5 and c =xxx，c 字段用不到索引，因为 b 是一个范围查询，遇到范围查询就停止了。

by -https://juejin.cn/post/7283832557502693413

redis做为缓存，mysql的数据如何与redis进行同步呢？（双写一致性）

在项目中，我们主要通过 Redisson 的读写锁机制 来保证数据的强一致性。

当执行读取操作时，我们会加上读锁（共享锁），这样可以做到：

• 读读不互斥；
• 读写互斥。

而在更新数据时，我们会加上写锁（排他锁），此时写写、读写都互斥。
这样可以确保在写入数据库的同时，其他线程无法读取缓存数据，从而避免出现脏读或不一致的情况。
这里需要注意的一点是：读写方法必须使用同一把锁，才能真正保证互斥关系成立。

除了使用分布式锁，我们也考虑过使用 “延迟双删”策略 来实现最终一致性。

具体做法是：

1. 先删除缓存；
2. 再更新数据库；
3. 最后延时一段时间后，再删除一次缓存。

不过，延迟的时间点很难精确把握。在延时窗口内仍可能出现脏数据问题，无法满足强一致性场景，因此我们最终没有采用这种方式。

在我最近做的项目中（例如简历中提到的 xxxx 功能），
系统对数据一致性的实时性要求没有那么高，可以接受一定的同步延时。

因此我们采用了 阿里巴巴的 Canal 组件 来实现最终一致性的数据同步。

Canal 的原理是：

• 将自己伪装成 MySQL 的从节点；
• 通过监听 binlog（数据库增删改日志） 来捕获数据变更；
• Canal 服务解析 binlog 后，将变更数据推送给客户端；
• 客户端根据变更内容更新或删除 Redis 缓存。

这种方式的优点是：

• 不需要修改业务代码；
• 同步过程自动化；
• 能在大多数业务场景下保证“最终一致性”。

Redis分布式锁方案

使用 Redis 的 SET key value NX EX实现分布式锁时，主要问题是锁过期时间不好设置：如果设置过短，业务未完成锁就过期；设置过长，会降低系统并发度。为此可以使用 Redisson 封装的分布式锁，它内部通过「看门狗机制」自动续期锁（默认锁 30 秒，每 10 秒续期一次），同时通过 Lua 脚本保证加解锁的原子性，从而确保分布式环境下的并发安全。

Redisson分布式锁自动续约机制（看门狗）

线程1尝试tryLock锁未指定锁的过期时间 获取成功后会自动启动看门狗机制

初始加锁：

​当调用 lock() 时，Redisson 会通过 Lua 脚本向 Redis 发送加锁命令，设置锁的初始过期时间为 LockWatchdogTimeout（默认 30 秒）。

​锁的数据结构为 Hash，键为锁名称，field 为线程 ID，value 为重入次数。

启动定时任务：

​加锁成功后，Redisson 会启动一个后台定时任务（通过 Netty 的 HashedWheelTimer 实现），每隔 10 秒执行一次。

续期逻辑：

​定时任务通过lua脚本检查锁是否存在并且被当前线程持有

​若条件满足，则通过 pexpire 命令将锁的过期时间重置为 LockWatchdogTimeout（30 秒）。

​续期成功后，继续等待下一个检查周期。

锁释放时终止续期：

​当调用 unlock() 释放锁时，会同时取消续期的定时任务，避免无限续期。

LeetCode 24. 两两交换链表中的节点

题目大意

给定一个单链表，需要将链表中的节点按顺序两两交换，并返回交换后新的链表头节点。禁止只交换节点的数值，必须真实地调整指针。当链表长度为奇数时，最后一个节点保持原状。

示例

• 输入：head = [1,2,3,4]
• 输出：[2,1,4,3]

当输入为 head = [1,2,3] 时，结果应为 [2,1,3]，因为第三个节点无法参与交换。

代码实现

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode() {}
 *     ListNode(int val) { this.val = val; }
 *     ListNode(int val, ListNode next) { this.val = val; this.next = next; }
 * }
 */
class Solution {
    public ListNode swapPairs(ListNode head) {
        ListNode dummy = new ListNode(0, head);//初始化 0->1->2->3->4
        ListNode curr = dummy.next;
        ListNode node0 = dummy;
        ListNode node1 = curr;
      
        while (node1 != null && node1.next != null) {//至少为两个节点
            ListNode node2 = node1.next;
            ListNode node3 = node2.next;

            node0.next = node2;//0->2
            node1.next = node3;//1->3
            node2.next = node1;//2->1

            node0 = node1;//交换 在下一次的循环中1就是0
            node1 = node3;//3就是1
        }

        return dummy.next;
    }
}

Redis 的数据过期策略

Redis 采用 「惰性删除 + 定期删除」 两种策略相结合的方式，在 CPU 性能开销 与 内存占用 之间取得平衡。

一、惰性删除（Lazy Expiration）

当客户端访问或修改某个键时，Redis 会在操作前调用 expireIfNeeded() 函数检查该键是否已过期：

• 若已过期：
  Redis 会立即删除该键，然后向客户端返回 null。
  删除方式由配置项 lazyfree-lazy-expire 决定：
  • 若开启（yes），则采用 异步删除；
  • 若关闭（no），则采用 同步删除。
• 若未过期：
  直接返回该键对应的正常值，不做任何额外处理。

这种方式的优点是 删除时机精准、不会浪费 CPU 时间；
缺点是：若某些过期键一直未被访问，就无法被清除，会长期占用内存。

二、定期删除（Active Expiration Cycle）

为了解决惰性删除的不足，Redis 还会周期性地扫描部分键空间，清除已过期的数据。

1. 检查频率

Redis 默认每秒执行 10 次过期扫描，这一频率由配置文件 redis.conf 中的参数 hz 控制：

hz 10

即 Redis 每隔约 100 毫秒 触发一次过期检测。

2. 检查机制

Redis 并不会遍历所有键，而是采用「随机抽查」机制来控制 CPU 占用。
该逻辑由 expire.c 文件中的 activeExpireCycle() 函数实现，核心过程如下：

1. 从每个数据库的「过期字典」中 随机抽取 20 个 key（数量由常量 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP = 20 决定）；
2. 检查这 20 个 key 是否过期，并删除已过期的 key；
3. 如果本轮抽查中，超过 25%（即 5 个）键过期，说明系统中可能仍存在大量过期数据，Redis 会继续重复步骤 1，进行新一轮检查；
4. 若过期比例低于 25%，则认为当前负载正常，Redis 会停止本轮扫描，等待下一次周期执行。

介绍一下Redis 内存淘汰策略

在 32 位操作系统中，maxmemory 的默认值是 3G，因为 32 位的机器最大只支持 4GB 的内存，而系统本身就需要一定的内存资源来支持运行，所以 32 位操作系统限制最大 3 GB 的可用内存是非常合理的，这样可以避免因为内存不足而导致 Redis 实例崩溃。

1、不进行数据淘汰的策略：

• noeviction（Redis3.0之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，这时如果有新的数据写入，会报错通知禁止写入，不淘汰任何数据，但是如果没用数据写入的话，只是单纯的查询或者删除操作的话，还是可以正常工作。

2、进行数据淘汰的策略：

针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。

• 在设置了过期时间的数据中进行淘汰：
  • volatile-random：随机淘汰设置了过期时间的任意键值；
  • volatile-ttl：优先淘汰更早过期的键值。
  • volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
  • volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；
• 在所有数据范围内进行淘汰：
  • allkeys-random：随机淘汰任意键值;
  • allkeys-lru：淘汰整个键值中最久未使用的键值；
  • allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

缓存穿透

缓存穿透指的是：一个缓存和数据库中都不存在的数据，由于数据库无法写入缓存，导致频繁请求直接打到数据库，从而造成数据库压力过大甚至被“打穿”。

常见的解决方法包括：缓存空值 或 布隆过滤器。

布隆过滤器由一个全 0 的位图数组和 n 个哈希函数组成。当一个数据在请求缓存前，会先经过布隆过滤器。过滤器会通过 n 个哈希函数计算出 n 个哈希值，再分别对数组长度取模，并将对应的数组下标置为 1。

查询时，只需要查看位图数组中这 n 个位置是否全部为 1：

• 若存在某个位为 0，则说明该数据一定不存在于数据库中；
• 若全部为 1，则说明该数据可能存在，但不一定真的存在，因为可能出现哈希碰撞。

因此，布隆过滤器判断“存在”时并不能保证数据真的存在，但判断“不存在”时一定准确。

缓存雪崩

缓存雪崩指的是：大量的缓存 Key 在同一时间失效，或者 Redis 服务器宕机，导致所有请求同时打到数据库，造成数据库瞬时压力过大，甚至宕机的情况。

解决方法：
为缓存设置 固定过期时间 + 随机过期时间，让不同 Key 的过期时间错开，避免在同一时间集中失效。

缓存击穿

缓存击穿指的是一个热点key设置了时间了过后 时间过期了 恰好这个时候大量请求打到数据库 让数据库压力大

解决方案：

方案一：互斥锁（分布式锁）

当缓存失效时，不立即去加载数据库，而是先使用 Redis 的 SETNX 命令设置互斥锁。

• 若设置成功（即当前线程获得锁），则执行 load db 操作并回填缓存；
• 若设置失败（说明已有线程在加载数据），则稍后重试获取缓存。

优点：保证数据一致性。
缺点：性能稍差，可能存在死锁风险。

方案二：逻辑过期

设置 Key 时，不给 Redis 设置真实的过期时间，而是在 Value 中自带一个逻辑过期时间字段。
实现思路如下：

1. 设置缓存时，将过期时间作为字段与数据一起存入；
2. 查询时，先从 Redis 获取数据并判断逻辑时间是否过期；
3. 若已过期，则异步开启一个线程进行数据刷新，同时返回旧数据给用户（保证高可用）。

优点：高性能、高可用。
缺点：数据可能短时间内不一致。

总结：

• 若追求强一致性 → 使用 分布式锁方案；
• 若追求高性能、高可用性 → 使用 逻辑过期方案。

P1439 【模板】最长公共子序列（洛谷题面）

题目

题目描述：

给出 的两个排列 和 ，求它们的最长公共子序列。

输入格式：

第一行是一个数 。

接下来两行，每行为 个数，为自然数 的一个排列。

输出格式：

一个数，即最长公共子序列的长度。

数据范围与说明：

• 对于 的数据， ；
• 对于 的数据， 。

输入输出样例 #1

输入：

5 
3 2 1 4 5
1 2 3 4 5

输出：

3

题意

给定 的两个排列 、，求它们的最长公共子序列（LCS）长度。

思路

经典做法是 动态规划，但对于 的数据会超时。利用“两个序列都是排列”的性质，可以将 LCS 转化为 LIS（最长上升子序列）：

1. 建立哈希（或数组）mp[val] 记录值 val 在序列 中的位置；
2. 遍历 ，将 $P_2[i]在 $P_1$ 中的位置mp[P2[i]]` 依次写入新数组；
3. 问题就变成了：求该新数组的 LIS 长度，使用 lower_bound + 贪心即可达到 。

复杂度：时间 ，空间 。

代码

#include <bits/stdc++.h>
using namespace std;

const int N = 100000 + 5;
int pos[N], b[N];

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    int n;
    cin >> n;
    for (int i = 1; i <= n; ++i) {
        int v; cin >> v;
        pos[v] = i;
    }
    for (int i = 1; i <= n; ++i) cin >> b[i];

    vector<int> lis;
    lis.reserve(n);
    for (int i = 1; i <= n; ++i) {
        int mapped = pos[b[i]];
        auto it = lower_bound(lis.begin(), lis.end(), mapped);
        if (it == lis.end()) lis.push_back(mapped);
        else *it = mapped;
    }
    cout << lis.size() << '\n';
    return 0;
}

P1434 [SHOI2002] 滑雪（洛谷题面）

题目

题目描述：

Michael 喜欢滑雪。这并不奇怪，因为滑雪的确很刺激。可是为了获得速度，滑的区域必须向下倾斜，而且当你滑到坡底，你不得不再次走上坡或者等待升降机来载你。Michael 想知道在一个区域中最长的滑坡。区域由一个二维数组给出。数组的每个数字代表点的高度。下面是一个例子：

1   2   3   4   5
16  17  18  19  6
15  24  25  20  7
14  23  22  21  8
13  12  11  10  9

一个人可以从某个点滑向上下左右相邻四个点之一，当且仅当高度会减小。在上面的例子中，一条可行的滑坡为 $24-17-16-1$（从 $24$ 开始，在 $1$ 结束）。当然 $25$－$24$－$23$－$\ldots$－$3$－$2$－$1$ 更长。事实上，这是最长的一条。

输入格式：

输入的第一行为表示区域的二维数组的行数 $R$ 和列数 $C$。下面是 $R$ 行，每行有 $C$ 个数，代表高度（两个数字之间用 $1$ 个空格间隔）。

输出格式：

输出区域中最长滑坡的长度。

数据范围与说明：

对于 $100%$ 的数据，$1\leq R,C\leq 100$。

输入输出样例 #1

输入：

5 5
1 2 3 4 5
16 17 18 19 6
15 24 25 20 7
14 23 22 21 8
13 12 11 10 9

输出：

25

代码

#include <bits/stdc++.h>
using namespace std;
typedef long long ll;
int a[105][105];
int dp[105][105];
int dx[4] = {-1, 1, 0, 0};
int dy[4] = {0, 0, -1, 1};
int n, m;
bool check(int i, int j) {
    return i >= 0 && i < n && j >= 0 && j < m;
}
int dfs(int i, int j) {
    if (dp[i][j] != 0) return dp[i][j];
    dp[i][j] = 1;
    for (int z = 0; z < 4; z++) {
        int x = i + dx[z], y = j + dy[z];
        if (check(x, y) && a[x][y] < a[i][j]) {
            dp[i][j] = max(dp[i][j], 1 + dfs(x, y));
        }
    }
    return dp[i][j];
}
void solve() {
    cin >> n >> m;
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < m; j++) {
            cin >> a[i][j];
        }
    }
    int ans = 0;
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < m; j++) {
            ans = max(ans, dfs(i, j));
        }
    }
    cout << ans << "\n";
}
int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    solve();
    return 0;
}

P1923 【深基9.例4】求第 k 小的数（洛谷题面）

题目

题目描述：

输入 $n$（$1 \le n < 5000000$ 且 $n$ 为奇数）个数字 $ai$（$1 \le ai < {10}^9$），输出这些数字的第 $k$ 小的数。最小的数是第 $0$ 小。

请尽量不要使用 nth_element 来写本题，因为本题的重点在于练习分治算法。

输入格式：

第一行有两个整数，分别表示 $n$ 和 $k$。

第二行有 $n$ 个整数，第 $i$ 个数表示 $a_i$。

输出格式：

一个整数，表示第 $k$ 小的数。

数据范围与说明：

输入输出样例 #1

输入：

5 1
4 3 2 1 5

输出：

2

代码

#include <bits/stdc++.h>
using namespace std;
typedef long long ll;
typedef pair<int, int> PLL;
int a[5000005];
int n,k;
void qsort(int i,int j){
    int l=i,r=j,mid=a[(l+r)/2];
    while(l<=r){
        while(a[r]>mid){
            r--;
        }
        while(a[l]<mid){
            l++;
        }
        if(l<=r){
            swap(a[l],a[r]);
            r--;
            l++;
        }
    }
    if(k<=r){
        qsort(i,l);
    }else if(l<=k){
        qsort(r,j);
    }else{
        cout<<a[r+1];
        return ;
    }
}
void solve() {
    cin>>n>>k;
    for(int i=0;i<n;i++){
        cin>>a[i];
    }
    qsort(0,n-1);
}
int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    int t = 1;
    while (t--) {
        solve();
    }
    return 0;
}

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E7%AE%97%E6%B3%95/P2196%E9%A2%98%E8%A7%A3

5
10 8 4 7 6
1 1 1 0
0 0 0
1 1
1

1 3 4 5
27

#include<bits/stdc++.h>
using namespace std;
int n,ans,f[25][25],a[25],b[25];
vector<int> path,ans_path;
bool check(int x){
    for(int i=1;i<=n;i++){
        if(f[x][i]&&!b[i])  return false;
    }
    return true;
}
void dfs(int x,int sum){
    if(check(x)){
        if(ans<sum){
            ans=sum;
            ans_path=path;
        }
        return ;
    }
    for(int i=1;i<=n;i++){
        if(f[x][i]&&!b[i]){
            b[i]=1;
            path.push_back(i);
            dfs(i,sum+a[i]);
            path.pop_back();
            b[i]=0;
        }
    }
    return ;
}
int main(){
    cin>>n;
    for(int i=1;i<=n;i++){
        cin>>a[i];
    }
    for(int i=1;i<n;i++){
        for(int j=i+1;j<=n;j++){
            cin>>f[i][j];
        }
    }
    for(int i=1;i<=n;i++){
        b[i]=1;
        path.clear();
        path.push_back(i);
        dfs(i,a[i]);
        b[i]=0;
    }
    for(int x:ans_path){
        cout<<x<<" ";
    }
    cout<<"\n";
    cout<<ans;
    return 0;
}

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E7%AE%97%E6%B3%95/P1216%E9%A2%98%E8%A7%A3

5
7
3 8
8 1 0
2 7 4 4
4 5 2 6 5

30

#include<bits/stdc++.h>
using namespace std;
int a[1010][1010],f[1010][1010];
int main(){
int n,s=0;
cin>>n;
for(int i=1;i<=n;i++)
for(int j=1;j<=i;j++)
cin>>a[i][j];
for(int i=1;i<=n;i++)
for(int j=1;j<=i;j++)
f[i][j]=max(f[i-1][j-1],f[i-1][j])+a[i][j];
for(int j=1;j<=n;j++) s=max(s,f[n][j]);
cout<<s;
return 0;
}

P3654

题目

题目描述：

可是……这个篮球场，好像很久没有使用过的样子啊……

里面堆满了学校的各种杂物呢……

我们 Aqours 的成员要怎么在里面列队站下呢？

我们浦之星女子学院的篮球场是一个 $R$ 行 $C$ 列的矩阵，其中堆满了各种学校的杂物 (用 # 表示)，空地 (用 . 表示) 好像并不多的样子呢……

我们 Aqours 现在已经一共有 $K$ 个队员了，要歌唱舞蹈起来的话，我们得排成一条 $1\times K$ 的直线，一个接一个地站在篮球场的空地上呢 (横竖均可)。

我们想知道一共有多少种可行的站位方式呢。

Aqours 的真正的粉丝的你，能帮我们算算吗？

输入格式：

第一行三个整数 $R, C, K$。

接下来的 $R$ 行 $C$ 列，表示浦之星女子学院篮球场。

输出格式：

总共的站位方式数量。

数据范围与说明：

对于所有数据，$1 \leq R,C \leq 100$，$1 \leq k \leq \min(R,C)$。

以下是彩蛋

在 LoveLive!Sunshine!! 动画第一季第三集中，Aqours 队长高海千歌演唱“最喜欢的话就没问题！”到副歌前时，学校因为雷击停电。

输入输出样例 #1

输入：

5 5 2
.###.
##.#.
..#..
#..#.
#.###

输出：

8

代码

#include<bits/stdc++.h>
using namespace std;
char a[105][105];
int r,c,k;
long long ans;
bool check(int i,int j){
    return i>=0&&i<r&&j>=0&&j<c;
}
void dfsr(int i,int j,int cnt){
    if(cnt==k){
        ans++;
        return ;
    }
    if(!check(i,j)) return ;
    if(a[i][j+1]=='.'){
        dfsr(i,j+1,cnt+1);
    }
    return ;
}
void dfsu(int i,int j,int cnt){
    if(cnt==k){
        ans++;
        return ;
    }
    if(!check(i,j)) return ;
    if(a[i+1][j]=='.'){
        dfsu(i+1,j,cnt+1);
    }
    return ;
}
int main(){
    cin>>r>>c>>k;
    for(int i=0;i<r;i++){
        for(int j=0;j<c;j++){
            cin>>a[i][j];
        }
    }
    for(int i=0;i<r;i++){
        for(int j=0;j<c;j++){
            if(a[i][j]=='.'){
                dfsr(i,j,1);
                dfsu(i,j,1);
            }
        }
    }
    if(k==1){
        cout<<ans/2;
    }else{
        cout<<ans;
    }
    return 0;
}

P10415（洛谷题面）

题目

题目描述：

给定一个 $W\times H$ 的长方形，两边长度均为整数。小蓝想把它切割为很多个边长为整数的小正方形。假设切割没有任何损耗，正方形的边长至少为 $2$，不允许出现余料，要求所有正方形的大小相等，请问最多能切割出多少个?

输入格式：

输入一行，包含两个整数 $W, H$，用一个空格分隔。

输出格式：

输出一行包含一个整数表示答案。如果不存在满足要求的方案，输出 $0$。

数据范围与说明：

【样例解释 1】

切割成 $5\times 10=50$ 个边长为 $2$ 的正方形。

【评测用例规模与约定】

对于 $30%$ 的评测用例，$1\le W,H\le 1000$；
对于 $60%$ 的评测用例，$1\le W,H\le 10^6$；
对于所有评测用例，$1\le W,H\le 10^9$。

输入输出样例 #1

输入：

10 20

输出：

50

输入输出样例 #2

输入：

6 9

输出：

6

输入输出样例 #3

输入：

8 13

输出：

0

题意

简述：

给定一个 $W\times H$ 的长方形，两边长度均为整数。小蓝想把它切割为很多个边长为整数的小正方形。假设切割没有任何损耗，正方形的边长至少为 $2$，不允许出现余料，要求所有正方形的大小相等，请问最多能切割出多少个?

代码

C++

#include <bits/stdc++.h>
using namespace std;
const int N=1e6+10;
typedef long long ll;
typedef pair<int, int> PLL;
int gcd(int a,int b){
    return b? gcd(b,a%b):a;
}
int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    int t = 1;
    // cin >> t;
    ll n,m;
   cin>>n>>m;
    int w=gcd(n,m);//最大正方形的边长
    if(w==1){//如果两个都是质数那么不能完全分解
        cout<<0;
        return 0;
    }
    for(int i=2;i*i<=w;i++){//最大公约数便是最大正方形的面积，因此用i*i来比较 
        if(n%i==0&&m%i==0){
            cout<<n/i*m/i;
            return 0;
        }
    }
    cout<<n/w*m/w;//特判w是质数的情况
    return 0;
}

P1048 [NOIP 2005 普及组] 采药（洛谷题面）

题目

题目描述：

辰辰是个天资聪颖的孩子，他的梦想是成为世界上最伟大的医师。为此，他想拜附近最有威望的医师为师。医师为了判断他的资质，给他出了一个难题。医师把他带到一个到处都是草药的山洞里对他说：“孩子，这个山洞里有一些不同的草药，采每一株都需要一些时间，每一株也有它自身的价值。我会给你一段时间，在这段时间里，你可以采到一些草药。如果你是一个聪明的孩子，你应该可以让采到的草药的总价值最大。”

如果你是辰辰，你能完成这个任务吗？

输入格式：

第一行有 $2$ 个整数 $T$（$1 \le T \le 1000$）和 $M$（$1 \le M \le 100$），用一个空格隔开，$T$ 代表总共能够用来采药的时间，$M$ 代表山洞里的草药的数目。

接下来的 $M$ 行每行包括两个在 $1$ 到 $100$ 之间（包括 $1$ 和 $100$）的整数，分别表示采摘某株草药的时间和这株草药的价值。

输出格式：

输出在规定的时间内可以采到的草药的最大总价值。

数据范围与说明：

【数据范围】

• 对于 $30%$ 的数据，$M \le 10$；
• 对于全部的数据，$M \le 100$。

【题目来源】

NOIP 2005 普及组第三题

输入输出样例 #1

输入：

70 3
71 100
69 1
1 2

输出：

3

题意

简述：

辰辰是个天资聪颖的孩子，他的梦想是成为世界上最伟大的医师。为此，他想拜附近最有威望的医师为师。医师为了判断他的资质，给他出了一个难题。医师把他带到一个到处都是草药的山洞里对他说：“孩子，这个山洞里有一些不同的草药，采每一株都需要一些时间，每一株也有它自身的价值。我会给你一段时间，在这段时间里，你可以采到一些草药。如果你是一个聪明的孩子，你应该可以让采到的草药的总价值最大。”

如果你是辰辰，你能完成这个任务吗？

代码

C++

#include <bits/stdc++.h>
using namespace std;

typedef long long ll;
typedef pair<int, int> PLL;
int m,v[1005],w[1005];
int dp[1005][1005];
int t = 1;
void solve() {
    cin >> t>>m;
    for(int i=1;i<=m;i++){
        cin>>v[i]>>w[i];
    }
    for(int i=1;i<=m;i++){
        for(int j=t;j>0;j--){
            if(j<v[i]){
                dp[i][j]=dp[i-1][j];
            }else{
                dp[i][j]=max(dp[i-1][j],dp[i-1][j-v[i]]+w[i]);
            }
        }
    }
    cout<<dp[m][t];
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    
    
    solve();
    return 0;
}

P2347（洛谷题面）

题目

题目描述：

设有 $1\mathrm{g}$、$2\mathrm{g}$、$3\mathrm{g}$、$5\mathrm{g}$、$10\mathrm{g}$、$20\mathrm{g}$ 的砝码各若干枚（其总重 ），可以表示成多少种重量？

输入格式：

输入方式：$a1 , a2 ,a3 , a4 , a5 ,a6$

（表示 $1\mathrm{g}$ 砝码有 $a1$ 个，$2\mathrm{g}$ 砝码有 $a2$ 个，$\dots$，$20\mathrm{g}$ 砝码有 $a_6$ 个）

输出格式：

输出方式：Total=N

（$N$ 表示用这些砝码能称出的不同重量的个数，但不包括一个砝码也不用的情况）

数据范围与说明：

【题目来源】

NOIP 1996 提高组第四题

输入输出样例 #1

输入：

1 1 0 0 0 0

输出：

Total=3

代码

#include<bits/stdc++.h>
using namespace std;
int a[]={1,2,3,5,10,20};
int b[300];
int dp[1100];
int main(){
    int sum=0;
    for(int i=0;i<6;i++){
        cin>>b[i];
        sum+=a[i]*b[i];
    }
    int ans=0;
    dp[0] = 1;
    for(int i=0;i<6;i++){
        for(int j=sum;j>=0;j--){
            for (int k = 1; k <= b[i]; k++){ 
if (dp[j - a[i]*k] == 1 && j - a[i]*k >= 0 && dp[j] == 0){
                    dp[j] = 1,ans++;
                }
}
        }
    }
    cout<<"Total="<<ans;
    return 0;
}

P8195

题目

题目描述：

传智专修学院给了小智一个仅包含小写字母的字符串 $s$，他想知道，里面出现了多少次子串 chuanzhi 呢。

我们称一个字符串 $t$ 是 $s$ 的子串，当且仅当将 $s$ 的开头若干个（可以为 0 个）连续字符和结尾若干个（可以为 0 个）连续字符删去后，剩下的字符串和 $t$ 相同。例如，我们称 ab 是 abc 的子串，但 ac 不是 abc 的子串。

输入格式：

输入只有一行一个字符串，表示字符串 $s$。

输出格式：

输出一行一个整数表示答案。

数据范围与说明：

数据规模与约定

对于全部的测试点，保证 $1 \leq |s| \leq 4 \times 10^5$，$|s|$ 表示 $s$ 的长度，且 $s$ 中只有小写字母。

输入输出样例 #1

输入：

welcometochuanzhicupchuanzhi

输出：

2

代码

#include<bits/stdc++.h>
using namespace std;
int main() {
    string s;
    cin >> s;
    string target = "chuanzhi";
    int index = 0, count = 0;
    for (char c : s) {
        if (c == target[index]) {
            index++;
            if (index == 8) {
                count++;
                index = 0;
            }
        } else {
            index = (c == target[0]) ? 1 : 0;
        }
    }
    cout << count;
    return 0;
}

P8196（洛谷题面）

题目

题目描述：

给定一个长度为 $n$ 的数列 $a$，对于一个有序整数三元组 $(i, j, k)$，若其满足 $1 \leq i \leq j \leq k \leq n$ 并且 $ai +aj = a_k$，则我们称这个三元组是「传智的」。

现在请你计算，有多少有序整数三元组是传智的。

输入格式：

本题单测试点内有多组测试数据。

输入的第一行是一个整数 $T$，表示数据组数。

对于每组数据：

第一行是一个整数，表示数列的长度 $n$。
第二行有 $n$ 个整数，第 $i$ 个整数表示 $a_i$。

输出格式：

对于每组数据，输出一行一个整数表示答案。

数据范围与说明：

样例 1 解释

对于第一组数据，因为 $a1 + a1 = a2$，$a1 + a2 = a3$，故共 $(1, 1, 2)$ 和 $(1, 2, 3)$ 两个三元组。
对于第二组数据六个三元组分别是：

• $(1, 1, 2)$
• $(1, 2, 3)$
• $(1, 3, 4)$
• $(1, 4, 5)$
• $(2, 2, 4)$
• $(2, 3, 5)$

数据规模与约定

对于全部测试点，保证 $1 \leq T \leq 100$，$1 \leq n , a_i \leq 100$，且各个测试点的 $n$ 之和不超过 $100$，即 $\sum n \leq 100$。

输入输出样例 #1

输入：

2
3
1 2 3
5
1 2 3 4 5

输出：

2
6

代码

#include <bits/stdc++.h>
using namespace std;
typedef long long ll;
typedef pair<int, int> PLL;
int a[105];
void solve() {
    int n,cnt=0;
    cin>>n;
    for(int i=1;i<=n;i++){
        cin>>a[i];
    }
    for(int i=1;i<=n;i++){
        for(int j=i;j<=n;j++){
            for(int k=j;k<=n;k++){
                if(a[i]+a[j]==a[k]){
                    cnt++;
                }
            }
        }
    }
    cout<<cnt<<endl;
}
int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    int t = 1;
    cin >> t;
    while (t--) {
        solve();
    }
    return 0;
}

口算练习题（洛谷题面）

题目

题目描述：

王老师正在教简单算术运算。细心的王老师收集了 $i$ 道学生经常做错的口算题，并且想整理编写成一份练习。编排这些题目是一件繁琐的事情，为此他想用计算机程序来提高工作效率。王老师希望尽量减少输入的工作量，比如 $\texttt{5+8}$ 的算式最好只要输入 $\texttt 5$ 和 $\texttt 8$，输出的结果要尽量详细以方便后期排版的使用，比如对于上述输入进行处理后输出 $\texttt{5+8=13}$ 以及该算式的总长度 $6$。王老师把这个光荣的任务交给你，请你帮他编程实现以上功能。

输入格式：

第一行一个整数 $i$。

接着的 $i$ 行为需要输入的算式，每行可能有三个数据或两个数据。

若该行为三个数据则第一个数据表示运算类型，$\texttt a$ 表示加法运算，$\texttt b$ 表示减法运算，$\texttt c$ 表示乘法运算，接着的两个数据表示参加运算的运算数。

若该行为两个数据，则表示本题的运算类型与上一题的运算类型相同，而这两个数据为运算数。

输出格式：

输出 $2\times i$ 行。对于每个输入的算式，输出完整的运算式及结果，第二行输出该运算式的总长度。

数据范围与说明：

【数据规模与约定】

对于 $50%$ 的数据，输入的算式都有三个数据。

对于所有数据，$0<i\leq 50$，第一个算式一定有三个数据，运算数为非负整数且小于 $10000$。

输入输出样例 #1

输入：

4
a 64 46
275 125
c 11 99
b 46 64

输出：

64+46=110
9
275+125=400
11
11*99=1089
10
46-64=-18
9

代码

#include<bits/stdc++.h>
using namespace std;
int main(){
    char c;
    int n,a,b;
    cin>>n;
    string s;
    for(int i=0;i<n;i++){
        cin>>s;
        if(s[0]>='a'&&s[0]<='c'){
            c=s[0];
            cin>>a>>b;
        }else{
            a=stoi(s);
            cin>>b;
        }
       if(c=='a'){
           string ans=to_string(a)+"+"+to_string(b)+"="+to_string(a+b);
           cout<<ans<<endl;
           cout<<ans.size()<<endl;
       }else if(c=='b'){
           string ans=to_string(a)+"-"+to_string(b)+"="+to_string(a-b);
           cout<<ans<<endl;
           cout<<ans.size()<<endl;
       }else if(c=='c'){
           string ans=to_string(a)+"*"+to_string(b)+"="+to_string(a*b);
           cout<<ans<<endl;
           cout<<ans.size()<<endl;
       }
    }
    return 0;
}

P10900（洛谷题面）

题目

题目描述：

在诗人的眼中，数字是生活的韵律，也是诗意的表达。

小蓝，当代顶级诗人与数学家，被赋予了“数学诗人” 的美誉。他擅长将冰冷的数字与抽象的诗意相融合，并用优雅的文字将数学之美展现于纸上。

某日，小蓝静坐书桌前，目光所及，展现着 $n$ 个数字，它们依次为 $a1, a2, \cdots, a_n$，熠熠生辉。小蓝悟到，如果一个数能够以若干个（至少两个）连续的正整数相加表示，那么它就蕴含诗意。例如，数字 $6$ 就蕴含诗意，因为
它可以表示为 $1 + 2 + 3$。而 $8$ 则缺乏诗意，因为它无法用连续的正整数相加表示。

小蓝希望他面前的所有数字都蕴含诗意，为此，他决定从这 $n$ 个数字中删除一部分。请问，小蓝需要删除多少个数字，才能使剩下的数字全部蕴含诗意？

输入格式：

输入的第一行包含一个整数 $n$，表示展示的数字个数。

第二行包含 $n$ 个整数 $a1, a2, \cdots, a_n$，相邻整数之间使用一个空格分隔，表示展示的数字。

输出格式：

输出一行包含一个整数，表示小蓝需要删除的数字个数，以使剩下的数字全部蕴含诗意。

数据范围与说明：

【样例说明】

在样例中，数字 $3$ 可以表示为 $1 + 2$，数字 $6$ 可以表示为 $1 + 2 + 3$，数字 $8$ 无法表示为连续的正整数相加，因此，需要删除的数字个数为 $1$。

【评测用例规模与约定】

对于 $30%$ 的评测用例，$1 \le n \le 10^3$，$1 \le ai \le 10^3$。
对于所有评测用例，$1 \le n \le 2 \times 10^5$，$1 \le ai \le 10^{16}$。

输入输出样例 #1

输入：

3
3 6 8

输出：

1

题意

简述：

在诗人的眼中，数字是生活的韵律，也是诗意的表达。

小蓝，当代顶级诗人与数学家，被赋予了“数学诗人” 的美誉。他擅长将冰冷的数字与抽象的诗意相融合，并用优雅的文字将数学之美展现于纸上。

某日，小蓝静坐书桌前，目光所及，展现着 $n$ 个数字，它们依次为 $a1, a2, \cdots, a_n$，熠熠生辉。小蓝悟到，如果一个数能够以若干个（至少两个）连续的正整数相加表示，那么它就蕴含诗意。例如，数字 $6$ 就蕴含诗意，因为
它可以表示为 $1 + 2 + 3$。而 $8$ 则缺乏诗意，因为它无法用连续的正整数相加表示。

小蓝希望他面前的所有数字都蕴含诗意，为此，他决定从这 $n$ 个数字中删除一部分。请问，小蓝需要删除多少个数字，才能使剩下的数字全部蕴含诗意？

代码

C++

#include<bits/stdc++.h>
using namespace std;
typedef long long ll;
const int N=2e5+10;
ll a[N];
bool check(ll n){
    return n&(n-1);
}

int main(){
    ll n;
    cin>>n;
    for(int i=0;i<n;i++) cin>>a[i];
    ll ans=0;
    for(int i=0;i<n;i++){
        if(!check(a[i])){
            ans++;
        }
    }
    cout<<ans;
    return 0;
}

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E7%AE%97%E6%B3%95/P5638%E9%A2%98%E8%A7%A3

4 0
1 2 3

6

4 1
1 2 3

3

#include<bits/stdc++.h>
using namespace std;
typedef long long ll;
const int N=1e6+10;
ll a[N],s[N];
int main(){
    ll n,k;
    cin>>n>>k;
    if(k+1>=n){
        cout<<0;
        return 0;
    }
    for(int i=1;i<=n-1;i++){
        cin>>a[i];
        s[i]=s[i-1]+a[i];
    }
    ll ans=LLONG_MAX;
    for(int i=1;i<=n-k;i++){
        ll sum = s[i + k - 1] - s[i - 1];
        ans=min(ans,s[n-1]-sum);
    }
    cout<<ans;
    return 0;
}

P1143 进制转换（洛谷题面）

题目

题目描述：

请你编一程序实现两种不同进制之间的数据转换。

输入格式：

共三行，第一行是一个正整数，表示需要转换的数的进制 $n\ (2\le n\le 16)$，第二行是一个 $n$ 进制数，若 $n>10$ 则用大写字母 $\verb!A!\sim \verb!F!$ 表示数码 $10\sim 15$，并且该 $n$ 进制数对应的十进制的值不超过 $10^9$，第三行也是一个正整数，表示转换之后的数的进制 $m\ (2\le m\le 16)$。

输出格式：

一个正整数，表示转换之后的 $m$ 进制数。

数据范围与说明：

输入输出样例 #1

输入：

16
FF
2

输出：

11111111

代码

#include <bits/stdc++.h>
using namespace std;
int main(){
    int n,m,num=0;
    string s;
    cin>>n;
    cin>>s;
    cin>>m;
    reverse(s.begin(),s.end());
    for(int i=0;i<s.size();i++){
        if(s[i]>='A'&&s[i]<='F'){
            num+=(s[i]-55)*pow(n,i);
        }else{
            num+=(s[i]-'0')*pow(n,i);
        }
    }
    string ans;
    while(num){
        int tmp=num%m;
        if(tmp>10){
            ans.push_back(tmp+55);
        }else{
            ans.push_back(tmp+'0');
        }
        num/=m;
    }
    reverse(ans.begin(),ans.end());
    cout<<ans;
    return 0;
}

P1225

题目

题目描述：

黑白棋游戏的棋盘由 $4 \times 4$ 方格阵列构成。棋盘的每一方格中放有 $1$ 枚棋子，共有 $8$ 枚白棋子和 $8$ 枚黑棋子。这 $16$ 枚棋子的每一种放置方案都构成一个游戏状态。在棋盘上拥有 $1$ 条公共边的 $2$ 个方格称为相邻方格。一个方格最多可有 $4$ 个相邻方格。在玩黑白棋游戏时，每一步可将任何 $2$ 个相邻方格中棋子互换位置。对于给定的初始游戏状态和目标游戏状态，编程计算从初始游戏状态变化到目标游戏状态的最短着棋序列。

输入格式：

输入文件共有 $8$ 行。前四行是初始游戏状态，后四行是目标游戏状态。每行 $4$ 个数分别表示该行放置的棋子颜色。“ $0$ ”表示白棋；“ $1$ ”表示黑棋。

输出格式：

输出文件的第一行是着棋步数 $n$。接下来 $n$ 行，每行 $4$ 个数分别表示该步交换棋子的两个相邻方格的位置。例如，abcd 表示将棋盘上 $(a,b)$ 处的棋子与 $(c,d)$ 处的棋子换位。

数据范围与说明：

由 @zhouyonglong 提供 SPJ

输入输出样例 #1

输入：

1111
0000
1110
0010
1010
0101
1010
0101

输出：

4
1222
1424
3242
4344

代码

#include<bits/stdc++.h>
using namespace std;
int f[5005][5005],len=1;
void func(int x){
    for(int i=1;i<=len;i++){
        f[x][i]=f[x-1][i]+f[x-2][i];
    }
    for(int i=1;i<=len;i++){
        if(f[x][i]>=10){
            f[x][i+1]+=f[x][i]/10;
            f[x][i]%=10;
            while(f[x][len+1]){
                len++;
            }
        }
    }
}
int main(){
    int n;
    cin>>n;
    f[1][1]=1;
    f[2][1]=2;
    for(int i=3;i<=n;i++){
        func(i);
    }
    for(int i=len;i>=1;i--){
        cout<<f[n][i];
    }
    return 0;
}

P1304 哥德巴赫猜想（洛谷题面）

题目

题目描述：

输入一个偶数 $N$，验证 $4\sim N$ 所有偶数是否符合哥德巴赫猜想：任一大于 $2$ 的偶数都可写成两个质数之和。如果一个数不止一种分法，则输出第一个加数相比其他分法最小的方案。例如 $10$，$10=3+7=5+5$，则 $10=5+5$ 是错误答案。

输入格式：

第一行输入一个正偶数 $N$

输出格式：

输出 $\dfrac{N-2}{2}$ 行。对于第 $i$ 行：

首先先输出正偶数 $2i+2$，然后输出等号，再输出加和为 $2i+2$ 且第一个加数最小的两个质数，以加号隔开。

数据范围与说明：

数据保证，。

输入输出样例 #1

输入：

10

输出：

4=2+2
6=3+3
8=3+5
10=3+7

代码

#include<bits/stdc++.h>
using namespace std;
bool prime(int x){
    if(x<=1)  return false;
    for(int i=2;i<=sqrt(x);i++){
        if(x%i==0) return false;
    }
    return true;
}
int main(){
    int n;
    cin>>n;
    for(int i=4;i<=n;i+=2){
        for(int j=2;j<i;j++){
            if(prime(j)&&prime(i-j)){
                cout<<i<<"="<<j<<"+"<<i-j<<endl;
                break;
            }
        }
    }
    return 0;
}

P1217 [USACO1.5] 回文质数（洛谷题面）

题目

题目描述：

因为 $151$ 既是一个质数又是一个回文数（从左到右和从右到左是看一样的），所以 $151$ 是回文质数。

写一个程序来找出范围 $[a,b] (5 \le a < b \le 100,000,000)$（一亿）间的所有回文质数。

输入格式：

第一行输入两个正整数 $a$ 和 $b$。

输出格式：

输出一个回文质数的列表，一行一个。

数据范围与说明：

Hint 1: Generate the palindromes and see if they are prime.

提示 1: 找出所有的回文数再判断它们是不是质数（素数）.

Hint 2: Generate palindromes by combining digits properly. You might need more than one of the loops like below.

提示 2: 要产生正确的回文数，你可能需要几个像下面这样的循环。

题目翻译来自NOCOW。

USACO Training Section 1.5

产生长度为 $5$ 的回文数：

for (d1 = 1; d1 <= 9; d1+=2) {    // 只有奇数才会是素数
     for (d2 = 0; d2 <= 9; d2++) {
         for (d3 = 0; d3 <= 9; d3++) {
           palindrome = 10000*d1 + 1000*d2 +100*d3 + 10*d2 + d1;//(处理回文数...)
         }
     }
 }

输入输出样例 #1

输入：

5 500

输出：

5
7
11
101
131
151
181
191
313
353
373
383

代码

#include<bits/stdc++.h>
using namespace std;
int n,m;
bool prime(int x) {
    if (x < 2) return false;
    if (x == 2) return true;
    if (x % 2 == 0) return false;
    for (int i = 3; i * i <= x; i += 2) {
        if (x % i == 0) return false;
    }
    return true;
}
bool check(int x){
    string ans;
    int s=x;
    while(s){
        ans.push_back(s%10+'0');
        s/=10;
    }
    int l=0,r=ans.size()-1;
    while(l<r){
        if(ans[l++]!=ans[r--]){
            return false;
        }
    }
    return true;
}
int main(){
    cin>>n>>m;
    if(m>=9999999) m=9999999;
if(n%2==0)n++;
    for(int i=n;i<=m;i++){
        if(check(i)&&prime(i)){
            cout<<i<<endl;
        }
    }
    return 0;
}

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://binzi.top/posts/%E7%AE%97%E6%B3%95/P2543%E9%A2%98%E8%A7%A3

01010101010 00000011111

6

01011 010010101111111111

5

#include<bits/stdc++.h>
using namespace std;
int dp[10001][10001];
int main(){
    string s1;
    string s2;
    int cnt=0;
    cin>>s1>>s2;
    for(int i=1;i<=s1.size();i++){
        for(int j=1;j<=s2.size();j++){
            if(s1[i-1]==s2[j-1])    dp[i][j]=dp[i-1][j-1]+1;
            else    dp[i][j]=max(dp[i][j-1],dp[i-1][j]);
        }
    }
    cout<<dp[s1.size()][s2.size()];
    return 0;
}

P10898（洛谷题面）

题目

题目描述：

小蓝正在玩拼图游戏，他有 $7385137888721$ 个 $2 \times 2$ 的方块和 $10470245$ 个 $1 \times 1$ 的方块，他需要从中挑出一些来拼出一个正方形，比如用 $3$ 个 $2 \times 2$ 和 $4$ 个 $1 \times 1$ 的方块可以拼出一个 $4 \times 4$ 的正方形，用 $9$ 个 $2 \times 2$ 的方块可以拼出一个 $6 \times 6$ 的正方形，请问小蓝能拼成的最大的正方形的边长为多少。

输入格式：

这是一道结果填空的题，你只需要算出结果后提交即可。本题的结果为一个整数，在提交答案时只填写这个整数，填写多余的内容将无法得分。

输出格式：

这是一道结果填空的题，你只需要算出结果后提交即可。本题的结果为一个整数，在提交答案时只填写这个整数，填写多余的内容将无法得分。

数据范围与说明：

题意

简述：

小蓝正在玩拼图游戏，他有 $7385137888721$ 个 $2 \times 2$ 的方块和 $10470245$ 个 $1 \times 1$ 的方块，他需要从中挑出一些来拼出一个正方形，比如用 $3$ 个 $2 \times 2$ 和 $4$ 个 $1 \times 1$ 的方块可以拼出一个 $4 \times 4$ 的正方形，用 $9$ 个 $2 \times 2$ 的方块可以拼出一个 $6 \times 6$ 的正方形，请问小蓝能拼成的最大的正方形的边长为多少。

代码

C++

#include<bits/stdc++.h>
using namespace std;
int main(){
    long long t=7385137888721;
    long long o=10470245,n=0;
    for(long long i=o;i>=1;i--){
        if(i%4==0){
            n=i/4;
            break;
        }
    }
    t+=n;
    t=sqrt(t*4);
    cout<<t;
    return 0;
}

P10426（洛谷题面）

题目

题目描述：

在一个神秘的森林里，住着一个小精灵名叫小蓝。有一天，他偶然发现了一个隐藏在树洞里的宝藏，里面装满了闪烁着美丽光芒的宝石。这些宝石都有着不同的颜色和形状，但最引人注目的是它们各自独特的 “闪亮度” 属性。每颗宝石都有一个与生俱来的特殊能力，可以发出不同强度的闪光。小蓝共找到了 $n$ 枚宝石，第 $i$ 枚宝石的 “闪亮度” 属性值为 $H_i$，小蓝将会从这 $n$ 枚宝石中选出三枚进行组合，组合之后的精美程度 $S$ 可以用以下公式来衡量：

$$S = Ha Hb Hc \cdot \frac{\operatorname{LCM}(Ha, Hb, Hc)}{\operatorname{LCM}(Ha, Hb) \cdot\operatorname{LCM}(Ha, Hc) \operatorname{LCM}(Hb, Hc)}$$

其中 $\operatorname{LCM}$ 表示的是最小公倍数函数。

小蓝想要使得三枚宝石组合后的精美程度 $S$ 尽可能的高，请你帮他找出精美程度最高的方案。如果存在多个方案 $S$ 值相同，优先选择按照 $H$ 值升序排列后字典序最小的方案。

输入格式：

第一行一个整数 $n$ 表示宝石个数。
第二行有 $n$ 个整数 $H1, H2, \dots H_n$ 表示每个宝石的闪亮度。

输出格式：

输出一行包含三个整数表示满足条件的三枚宝石的 “闪亮度”。

数据范围与说明：

数据规模与约定

• 对 $30%$ 的数据，$n \leq 100$，$H_i \leq 10^3$。
• 对 $60%$ 的数据，$n \leq 2 \times 10^3$。
• 对全部的测试数据，保证 $3 \leq n \leq 10^5$，$1 \leq H_i \leq 10^5$。

输入输出样例 #1

输入：

5
1 2 3 4 9

输出：

1 2 3

题意

简述：

在一个神秘的森林里，住着一个小精灵名叫小蓝。有一天，他偶然发现了一个隐藏在树洞里的宝藏，里面装满了闪烁着美丽光芒的宝石。这些宝石都有着不同的颜色和形状，但最引人注目的是它们各自独特的 “闪亮度” 属性。每颗宝石都有一个与生俱来的特殊能力，可以发出不同强度的闪光。小蓝共找到了 $n$ 枚宝石，第 $i$ 枚宝石的 “闪亮度” 属性值为 $H_i$，小蓝将会从这 $n$ 枚宝石中选出三枚进行组合，组合之后的精美程度 $S$ 可以用以下公式来衡量：

$$S = Ha Hb Hc \cdot \frac{\operatorname{LCM}(Ha, Hb, Hc)}{\operatorname{LCM}(Ha, Hb) \cdot\operatorname{LCM}(Ha, Hc) \operatorname{LCM}(Hb, Hc)}$$

其中 $\operatorname{LCM}$ 表示的是最小公倍数函数。

小蓝想要使得三枚宝石组合后的精美程度 $S$ 尽可能的高，请你帮他找出精美程度最高的方案。如果存在多个方案 $S$ 值相同，优先选择按照 $H$ 值升序排列后字典序最小的方案。

代码

C++

#include<bits/stdc++.h>
using namespace std;
const int N=1e5+10;
int a[N],cnt[N];

int gcd(int a,int b){
    return b?gcd(b,a%b):a;
}

int lcm(int a,int b){
    return a*b/gcd(a,b);
}

int main(){
    int n;
    cin>>n;
    for(int i=1;i<=n;i++){
        cin>>a[i];
        for(int j=1;j<=sqrt(a[i]);j++){
            if(a[i]%j==0){
                cnt[j]++;
                if(j!=sqrt(a[i]))   cnt[a[i]/j]++;
            }
        }
    }
    int x=1;
    for(int i=N-10;i>=1;i--){
        if(cnt[i]>=3){
            x=i;
            break;
        }
    }
    sort(a+1,a+n+1);
    
    int c=0;
    for(int i=1;i<=n;i++){
        if(a[i]%x==0){
            cout<<a[i]<<" ";
            c++;
            if(c==3)    return 0;
        }
    }
    return 0;
}

P10425（洛谷题面）

题目

题目描述：

小蓝最近在研究一种浮点数的表示方法：$R$ 格式。对于一个大于 $0$ 的浮点数 $d$，可以用 $R$ 格式的整数来表示。给定一个转换参数 $n$，将浮点数转换为 $R$ 格式整数的做法是：

1. 将浮点数乘以 $2^n$。
2. 四舍五入到最接近的整数。

输入格式：

一行一个整数 $n$ 和一个浮点数 $d$。

输出格式：

一行一个整数表示 $d$ 用 $R$ 格式表示出的值。

数据范围与说明：

样例 1 解释

$3.14 \times 2^2 = 12.56$，四舍五入后为 $13$。

数据规模与约定

用 $t$ 表示将 $d$ 视为字符串时的长度。

• 对于 $50%$ 的数据，保证 $n \le 10$，$t \le 15$。
• 对于全部的测试数据，保证 $1 \le n \le 1000$，$1 \le t \le 1024$，保证 $d$ 是小数，即包含小数点。

输入输出样例 #1

输入：

2 3.14

输出：

13

题意

简述：

小蓝最近在研究一种浮点数的表示方法：$R$ 格式。对于一个大于 $0$ 的浮点数 $d$，可以用 $R$ 格式的整数来表示。给定一个转换参数 $n$，将浮点数转换为 $R$ 格式整数的做法是：

1. 将浮点数乘以 $2^n$。
2. 四舍五入到最接近的整数。

代码

C++

#include<bits/stdc++.h>
using namespace std;
int n,l;
string d;
int a[1000000];
void func(){
    for(int i=1;i<=l;i++){
        a[i]*=2;
    }
    for(int i=1;i<=l;i++){
        a[i+1]+=a[i]/10;
        a[i]%=10;
    }
    if(a[l+1]){
        l++;
    }
}
int main(){
    cin>>n>>d;
    reverse(d.begin(),d.end());
    int index=d.find(".");
    d.erase(index,1);
    l=d.size();
    for(int i=0;i<l;i++) a[i+1]=d[i]-'0';
    for(int i=1;i<=n;i++){
        func();
    }
    if(a[index]>=5){
a[index+1]++;
    }
    for(int i=index+1;i<=l;i++)
{
a[i+1]+=a[i]/10;
a[i]%=10;
}
if(a[l+1])  l++;
for(int i=l;i>index;i--)
cout<<a[i];
    return 0;
}

P10902（洛谷题面）

题目

题目描述：

小蓝在无聊时随机生成了一个长度为 $n$ 的整数数组，数组中的第 $i$ 个数为 $ai$，他觉得随机生成的数组不太美观，想把它变成回文数组，也是就对于任意 $i\in [1,n]$ 满足 $ai=a_{n-i+1}$。小蓝一次操作可以指定相邻的两个数，将它们一起加 $1$ 或减 $1$；也可以只指定一个数加 $1$ 或减 $1$，请问他最少需要操作多少次能把这个数组变成回文数组？

输入格式：

输入的第一行包含一个正整数 $n$。

第二行包含 $n$ 个整数 $a1, a2,\cdots, a_n$，相邻整数之间使用一个空格分隔。

输出格式：

输出一行包含一个整数表示答案。

数据范围与说明：

【样例说明】

第一次操作将 $a1, a2$ 加 $1$，变为 $2, 3, 3, 4$；

后面两次操作将 $a_1$ 加 $1$，变为 $4,3,3,4$。

【评测用例规模与约定】

对于 $20%$ 的评测用例，$1 \le n \le 10$；
对于所有评测用例，$1 \le n \le 10^5$，$-10^6 \le a_i \le 10^6$。

输入输出样例 #1

输入：

4
1 2 3 4

输出：

3

题意

简述：

小蓝在无聊时随机生成了一个长度为 $n$ 的整数数组，数组中的第 $i$ 个数为 $ai$，他觉得随机生成的数组不太美观，想把它变成回文数组，也是就对于任意 $i\in [1,n]$ 满足 $ai=a_{n-i+1}$。小蓝一次操作可以指定相邻的两个数，将它们一起加 $1$ 或减 $1$；也可以只指定一个数加 $1$ 或减 $1$，请问他最少需要操作多少次能把这个数组变成回文数组？

代码

C

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
const int N=1e5+10;
long long a[N],b[N],ans=0;
int main(){
    ios_sync_stdio(false);
    cin.tie(0);
    cout.tie(0);
    int n;
    cin>>n;
    for(int i=0;i<n;i++)    cin>>a[i];
    for(int i=0;i<(n+1)/2;i++){
        if(a[i]>a[n-i+1]){
            b[i]=a[n-i+1]-a[i];
        }else{
            b[n-i+1]=a[i]-a[n-i+1];
        }
    }
    for(int i=0;i<n;i++){
        long long m=min(b[i],b[i+1]);
        b[i]-=m;
        b[i+1]-=m;
        ans+=m;
        ans+=b[i];
    }
    cout<<ans<<endl;
    return 0;
}

C++

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
const int N=1e5+10;
long long a[N],b[N],ans=0;
int main(){
    ios::sync_with_stdio(false);
    cin.tie(0);
    cout.tie(0);
    int n;
    cin>>n;
    for(int i=1;i<=n;i++)    cin>>a[i];
    for(int i=1;i<=(n+1)/2;i++){
        if(a[i]<a[n-i+1]){
            b[i]=a[n-i+1]-a[i];
        }else{
            b[n-i+1]=a[i]-a[n-i+1];
        }
    }
    for(int i=1;i<=n;i++){
        long long m=min(b[i],b[i+1]);
        b[i]-=m;
        b[i+1]-=m;
        ans+=m;
        ans+=b[i];
    }
    cout<<ans<<endl;
    return 0;
}

P11041（洛谷题面）

题目

题目描述：

小蓝和朋友们在玩一个报数游戏。由于今年是 $2024$ 年，他们决定要从小到大轮流报出是 $20$ 或 $24$ 倍数的正整数。前 $10$ 个被报出的数是：$20,24,40,48,60,72,80,96,100,120$。请问第 $202420242024$ 个被报出的数是多少？

这是一道结果填空的题，你只需要算出结果后提交即可。本题的结果为一个整数，在提交答案时只输出这个整数，填写多余的内容将无法得分。

输入格式：

本题无输入。

输出格式：

一行一个整数，表示你算出的答案。

数据范围与说明：

代码

#include<bits/stdc++.h>
using namespace std;
typedef long long ll;
int main(){
    printf("2429042904288");
    return 0;
}

蓝桥杯 2023 岛屿个数

题目描述

给定 组测试数据，每组数据是一张 的二值地图，字符 1 表示陆地，字符 0 表示海洋，地图之外视为海水。两个相邻的 1（上、下、左、右四个方向）属于同一个岛屿。若某个岛屿完全被另一个岛屿包围，则称其为子岛屿；统计时只需统计最外层岛屿的数量，子岛屿不计入答案。

输入格式

第一行一个整数 。
接下来每组数据：

• 第一行两个整数 ；
• 接下来 行，每行一个长度为 的字符串。

输出格式

对每组数据输出一个整数，表示非子岛屿的数量。

思路

1. 先从地图边界出发，使用 BFS/DFS 遍历海洋，标记所有与外海相连的海水；
2. 在外海遍历过程中，如果遇到未访问的陆地，就说明发现了一个新的最外层岛屿，对其进行 BFS/DFS 并标记整座岛；
3. 如果地图中没有与外海相连的海水，说明整张图都是陆地——此时答案为 1。

代码

#include <bits/stdc++.h>
using namespace std;

const int N = 55;
int grid[N][N];
bool visSea[N][N], visLand[N][N];
int dx4[4] = {-1, 0, 1, 0};
int dy4[4] = {0, -1, 0, 1};
int dx8[8] = {-1,-1,-1,0,0,1,1,1};
int dy8[8] = {-1,0,1,-1,1,-1,0,1};
int n, m;

inline bool inside(int x, int y) {
    return x >= 0 && x < n && y >= 0 && y < m;
}

void bfsLand(int sx, int sy) {
    queue<pair<int,int>> q;
    q.push({sx, sy});
    visLand[sx][sy] = true;
    while (!q.empty()) {
        auto [x, y] = q.front();
        q.pop();
        for (int d = 0; d < 4; ++d) {
            int nx = x + dx4[d], ny = y + dy4[d];
            if (inside(nx, ny) && grid[nx][ny] && !visLand[nx][ny]) {
                visLand[nx][ny] = true;
                q.push({nx, ny});
            }
        }
    }
}

int bfsSea(int sx, int sy) {
    queue<pair<int,int>> q;
    q.push({sx, sy});
    visSea[sx][sy] = true;
    int islands = 0;
    while (!q.empty()) {
        auto [x, y] = q.front();
        q.pop();
        for (int d = 0; d < 8; ++d) {
            int nx = x + dx8[d], ny = y + dy8[d];
            if (!inside(nx, ny)) continue;
            if (!grid[nx][ny] && !visSea[nx][ny]) {
                visSea[nx][ny] = true;
                q.push({nx, ny});
            } else if (grid[nx][ny] && !visLand[nx][ny]) {
                ++islands;
                bfsLand(nx, ny);
            }
        }
    }
    return islands;
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    int T; cin >> T;
    while (T--) {
        cin >> n >> m;
        for (int i = 0; i < n; ++i) {
            string s; cin >> s;
            for (int j = 0; j < m; ++j) grid[i][j] = s[j] - '0';
        }
        memset(visSea, 0, sizeof(visSea));
        memset(visLand, 0, sizeof(visLand));

        int ans = 0;
        bool touched = false;
        for (int i = 0; i < n; ++i) {
            for (int j = 0; j < m; ++j) {
                if (i == 0 || i == n - 1 || j == 0 || j == m - 1) {
                    if (!grid[i][j] && !visSea[i][j]) {
                        touched = true;
                        ans += bfsSea(i, j);
                    }
                }
            }
        }
        if (!touched) ans = 1;
        cout << ans << '\n';
    }
    return 0;
}

P1706

题目

题目描述：

按照字典序输出自然数 $1$ 到 $n$ 所有不重复的排列，即 $n$ 的全排列，要求所产生的任一数字序列中不允许出现重复的数字。

输入格式：

一个整数 $n$。

输出格式：

由 $1 \sim n$ 组成的所有不重复的数字序列，每行一个序列。

每个数字保留 $5$ 个场宽。

数据范围与说明：

$1 \leq n \leq 9$。

输入输出样例 #1

输入：

3

输出：

1    2    3
1    3    2
2    1    3
2    3    1
3    1    2
3    2    1

代码

#include<bits/stdc++.h>
using namespace std;
bool a[100];
int n;
void dfs(int pos,vector<int>&arr){
    if(pos==n){
        for(int &x:arr) cout<<setw(5)<<x;
        cout<<endl;
        return ;
    }
    for(int i=1;i<=n;i++){
        if(!a[i]){
            a[i]=true;
            arr.push_back(i);
            dfs(pos+1,arr);
            arr.pop_back();
            a[i]=false;
        }
    }
}
int main(){
    ios::sync_with_stdio(false);
    cin.tie(0);
    cout.tie(0);
    vector<int>arr;
    cin>>n;
    dfs(0,arr);
    return 0;
}

P1157

题目

题目描述：

排列与组合是常用的数学方法，其中组合就是从 $n$ 个元素中抽出 $r$ 个元素（不分顺序且 $r \le n$），我们可以简单地将 $n$ 个元素理解为自然数 $1,2,\dots,n$，从中任取 $r$ 个数。

现要求你输出所有组合。

例如 $n=5,r=3$，所有组合为：

$123,124,125,134,135,145,234,235,245,345$。

输入格式：

一行两个自然数 $n,r(1<n<21,0 \le r \le n)$。

输出格式：

所有的组合，每一个组合占一行且其中的元素按由小到大的顺序排列，每个元素占三个字符的位置，所有的组合也按字典顺序。

注意哦！输出时，每个数字需要 $3$ 个场宽。以 C++ 为例，你可以使用下列代码：

cout << setw(3) << x;

输出占 $3$ 个场宽的数 $x$。注意你需要头文件 iomanip。

数据范围与说明：

输入输出样例 #1

输入：

5 3

输出：

1  2  3
1  2  4
1  2  5
1  3  4
1  3  5
1  4  5
2  3  4
2  3  5
2  4  5
3  4  5

代码

#include<bits/stdc++.h>
using namespace std;
int n,r;
void dfs(int pos,int start,vector<int> &tmp){
    if(pos==r){
        for(int &x:tmp){
            cout<<setw(3)<<x;
        }
        cout<<endl;
        return;
    }
    for(int i=start;i<=n;i++){
        tmp.push_back(i);
        dfs(pos+1,i+1,tmp);
        tmp.pop_back();
    }
}
int main(){
    vector<int>a;
    cin>>n>>r;
    dfs(0,1,a);
    return 0;
}

P1036 [NOIP 2002 普及组] 选数（洛谷题面）

题目

题目描述：

已知 $n$ 个整数 $x1,x2,\cdots,x_n$，以及 $1$ 个整数 $k$（$k<n$）。从 $n$ 个整数中任选 $k$ 个整数相加，可分别得到一系列的和。例如当 $n=4$，$k=3$，$4$ 个整数分别为 $3,7,12,19$ 时，可得全部的组合与它们的和为：

$3+7+12=22$

$3+7+19=29$

$7+12+19=38$

$3+12+19=34$

现在，要求你计算出和为素数共有多少种。

例如上例，只有一种的和为素数：$3+7+19=29$。

输入格式：

第一行两个空格隔开的整数 $n,k$（$1 \le n \le 20$，$k<n$）。

第二行 $n$ 个整数，分别为 $x1,x2,\cdots,xn$（$1 \le xi \le 5\times 10^6$）。

输出格式：

输出一个整数，表示种类数。

数据范围与说明：

【题目来源】

NOIP 2002 普及组第二题

输入输出样例 #1

输入：

4 3
3 7 12 19

输出：

1

题意

简述：

已知 $n$ 个整数 $x1,x2,\cdots,x_n$，以及 $1$ 个整数 $k$（$k<n$）。从 $n$ 个整数中任选 $k$ 个整数相加，可分别得到一系列的和。例如当 $n=4$，$k=3$，$4$ 个整数分别为 $3,7,12,19$ 时，可得全部的组合与它们的和为：

$3+7+12=22$

$3+7+19=29$

$7+12+19=38$

$3+12+19=34$

现在，要求你计算出和为素数共有多少种。

例如上例，只有一种的和为素数：$3+7+19=29$。

代码

C++

#include<bits/stdc++.h>
using namespace std;
typedef long long ll;
ll n,a[25],k,ans=0,sum[25];
bool check(ll x){
    if(x==1)    return false;
    for(ll i=2;i<x;i++){
        if(x%i==0)  return false;
    }
    return true;
}

void solve(ll total,ll pos,ll start){
    if(pos==k){
        if(check(total)){
            ans++;
        }
        return ;
    }
    
    for(int i=start;i<n;i++){
        solve(total+a[i],pos+1,i+1);
    }
    return ;
}

int main(){
    cin>>n>>k;
    for(int i=0;i<n;i++){
        cin>>a[i];
    }
    solve(0,0,0);
    cout<<ans;
    return 0;
}

P1618 三连击（升级版）（洛谷题面）

题目

题目描述：

将 $1, 2,\ldots, 9$ 共 $9$ 个数分成三组，分别组成三个三位数，且使这三个三位数的比例是 $A:B:C$，试求出所有满足条件的三个三位数，若无解，输出 No!!!。

//感谢黄小U饮品完善题意

输入格式：

三个数，$A,B,C$。

输出格式：

若干行，每行 $3$ 个数字。按照每行第一个数字升序排列。

数据范围与说明：

保证 $0 \le A<B<C \le 999$。

$\text{upd 2022.8.3}$：新增加二组 Hack 数据。

输入输出样例 #1

输入：

1 2 3

输出：

192 384 576
219 438 657
273 546 819
327 654 981

代码

#include<bits/stdc++.h>
using namespace std;
int a,b,c,x[10];
bool used[10]={0},ans=false;
int func(int s){
    int sum=0;
    for(int i=3*s-2;i<=3*s;i++){
        sum*=10;
        sum+=x[i];
    }
    return sum;
}
void solve(int n){
    if(n==10&&(func(1)*b==func(2)*a)&&(func(3)*a==func(1)*c)){
        cout<<func(1)<<" "<<func(2)<<" "<<func(3)<<endl;
        ans=true;
        return ;
    }
    for(int i=1;i<=9;i++){
        if(!used[i]){
            x[n]=i;
            used[i]=true;
            solve(n+1);
            used[i]=false;
        }
    }
    return ;
}
int main(){
    cin>>a>>b>>c;
    solve(1);
    if(!ans)    cout<<"No!!!";
    return 0;
}

烤鸡（洛谷题面）

题目

题目描述：

猪猪 Hanke 特别喜欢吃烤鸡（本是同畜牲，相煎何太急！）Hanke 吃鸡很特别，为什么特别呢？因为他有 $10$ 种配料（芥末、孜然等），每种配料可以放 $1$ 到 $3$ 克，任意烤鸡的美味程度为所有配料质量之和。

现在， Hanke 想要知道，如果给你一个美味程度 $n$ ，请输出这 $10$ 种配料的所有搭配方案。

输入格式：

一个正整数 $n$，表示美味程度。

输出格式：

第一行，方案总数。

第二行至结束，$10$ 个数，表示每种配料所放的质量，按字典序排列。

如果没有符合要求的方法，就只要在第一行输出一个 $0$。

数据范围与说明：

对于 $100%$ 的数据，$n \leq 10000$。

输入输出样例 #1

输入：

11

输出：

10
1 1 1 1 1 1 1 1 1 2 
1 1 1 1 1 1 1 1 2 1 
1 1 1 1 1 1 1 2 1 1 
1 1 1 1 1 1 2 1 1 1 
1 1 1 1 1 2 1 1 1 1 
1 1 1 1 2 1 1 1 1 1 
1 1 1 2 1 1 1 1 1 1 
1 1 2 1 1 1 1 1 1 1 
1 2 1 1 1 1 1 1 1 1 
2 1 1 1 1 1 1 1 1 1

代码

#include<bits/stdc++.h>
using namespace std;
int n,kind,m1[10000][10],m2[10];
void func(int total,int a){
    if(a==10){
        if(total==n){
            for (int j = 0; j < 10; j++) {
                m1[kind][j] = m2[j];
            }   
            kind++;
        }
        return ;
    }
    if(total>=n)    return;
    for(int i=1;i<=3;i++){
        m2[a]=i;
        func(total+i,a+1);
    }     
}
int main(){
    cin>>n;
    if (n < 10 || n > 30) {
        cout <<"0"<< endl;
        return 0;
    }
    func(0,0);
    cout<<kind<<endl;
    for(int i=0;i<kind;i++){
        for(int j=0;j<10;j++){
            cout<<m1[i][j]<<" ";
        }
        cout<<endl;
    }
    return 0;
}

P2241

题目

题目描述：

有一个 $n \times m$ 方格的棋盘，求其方格包含多少正方形、长方形（不包含正方形）。

输入格式：

一行，两个正整数 $n,m$（$n \leq 5000,m \leq 5000$）。

输出格式：

一行，两个正整数，分别表示方格包含多少正方形、长方形（不包含正方形）。

数据范围与说明：

输入输出样例 #1

输入：

2 3

输出：

8 10

代码

#include<bits/stdc++.h>
using namespace std;
long long n,m,sqr,rec;
int main(){
    cin>>n>>m;
    for(int i=0;i<n;i++){
        for(int j=0;j<m;j++){
            if(i==j)    sqr+=(n-i)*(m-j);
            else    rec+=(n-i)*(m-j);
        }
    }
    cout<<sqr<<" "<<rec<<endl;
    return 0;
}

P1601 高精度加法（洛谷题面）

题目

题目描述：

给定两个非负整数 $a,b$，求它们的和。不用考虑负数。

输入格式：

输入共两行，每行一个非负整数，分别为 $a,b$。

输出格式：

输出一行一个非负整数，表示 $a+b$ 的值。

数据范围与说明：

对于 $20%$ 的测试数据，$a,b \le 10^9$；
对于 $40%$ 的测试数据，$a,b \le 10^{18}$；
对于 $100%$ 的测试数据，$0\le a,b \le 10^{500}$。

输入输出样例 #1

输入：

1
1

输出：

2

输入输出样例 #2

输入：

1001
9099

输出：

10100

代码

#include<bits/stdc++.h>
using namespace std;
string a,b,result="";
string add(string a,string b){
    if(a.size()<b.size()){
        swap(a,b);
    }
    int len_a=a.size();
    int len_b=b.size();
    int diff=len_a-len_b;
    int carry=0;
    for(int i=a.size()-1;i>=0;i--){
        int digit1=a[i]-'0';    
        int digit2=(i>=diff)?(b[i-diff]-'0'):0;
        int sum=digit1+digit2+carry;
        carry=sum/10;
        result.push_back(sum%10+'0');
    }
    if(carry){
        result.push_back(carry+'0');
    }
    reverse(result.begin(),result.end());
    return result;
}
int main(){
    cin>>a;
    cin>>b;
    string num=add(a,b);
    cout<<num;
    return 0;
}

P1307

题目

题目描述：

给定一个整数 $N$，请将该数各个位上数字反转得到一个新数。新数也应满足整数的常见形式，即除非给定的原数为零，否则反转后得到的新数的最高位数字不应为零（参见样例 2）。

输入格式：

一个整数 $N$。

输出格式：

一个整数，表示反转后的新数。

数据范围与说明：

【数据范围】

。

noip2011 普及组第一题

输入输出样例 #1

输入：

123

输出：

321

输入输出样例 #2

输入：

-380

输出：

-83

代码

#include<bits/stdc++.h>
using namespace std;
int main(){
    string s;
    cin>>s;
    if(s[0]=='0')   cout<<0;
    while(s.back()=='0'&&!s.empty()){
        s.erase(s.size()-1);
    }
    reverse(s.begin(),s.end());
    if(s.back()=='-'){
        s.erase(s.size()-1);
        cout<<"-"<<s;
    }else{
        cout<<s;
    }
    return 0;
}

【深基2.习6】Apples Prologue / 苹果和虫子（洛谷题面）

题目

题目描述：

小 B 喜欢吃苹果。她现在有 $m$（$1 \le m \le 100$）个苹果，吃完一个苹果需要花费 $t$（$0 \le t \le 100$）分钟，吃完一个后立刻开始吃下一个。现在时间过去了 $s$（$1 \le s \le 10000$）分钟，请问她还有几个完整的苹果？

输入格式：

输入三个非负整数表示 $m, t, s$。

输出格式：

输出一个整数表示答案。

数据范围与说明：

如果你出现了 RE，不如检查一下被零除？

输入输出样例 #1

输入：

50 10 200

输出：

30

代码

#include<bits/stdc++.h>
using namespace std;
int main(){
    int m,t,s;
    cin>>m>>t>>s;
    if(t==0)
    {
        cout<<0;
        return 0;
    }
    if(s%t==0){
        cout<<max(m-s/t,0);
    }else{
        cout<<max(m-s/t-1,0);
    }
    return 0;
}

P1567

题目

题目描述：

炎热的夏日，KC 非常的不爽。他宁可忍受北极的寒冷，也不愿忍受厦门的夏天。最近，他开始研究天气的变化。他希望用研究的结果预测未来的天气。

经历千辛万苦，他收集了连续 $N(1 \leq N \leq 10^6)$ 天的最高气温数据。

现在，他想知道最高气温一直上升的最长连续天数。

输入格式：

第 1 行：一个整数 $N$ 。$1 \leq N \leq 10^6$

第 2 行：$N$个空格隔开的整数，表示连续 $N$ 天的最高气温。$0 \leq$ 最高气温 $\leq 10^9$ 。

输出格式：

1 行：一个整数，表示最高气温一直上升的最长连续天数。

数据范围与说明：

输入输出样例 #1

输入：

10
1 2 3 2 4 5 6 8 5 9

输出：

5

代码

#include<bits/stdc++.h>
using namespace std;
int a[1000005];
int main(){
    int n,ans=1;
    cin>>n;
    for(int i=1;i<=n;i++){
        cin>>a[i];
    }
    int count=1;
    for(int i=2;i<=n;i++){
        if(a[i]>a[i-1]){
            count++;
            ans=max(ans,count);
        }else{
            count=1;
        }
    }
    cout<<ans;
    return 0;
}

P1506

题目

题目描述：

oibh 被突来的洪水淹没了，还好 oibh 总部有在某些重要的地方起一些围墙。用 * 号表示，而一个四面被围墙围住的区域洪水是进不去的。

oibh 总部内部也有许多重要区域，每个重要区域在图中用一个 0 表示。

现在给出 oibh 的围墙建设图，问有多少个没被洪水淹到的重要区域。

输入格式：

第一行为两个正整数 $x,y$。

接下来 $x$ 行，每行 $y$ 个字符，由 * 和 0 组成，表示 oibh 总部的建设图。

输出格式：

输出没被水淹没的 oibh 总部的 0 的数量。

数据范围与说明：

对于 $100%$ 的数据，$1 \le x,y \le 500$。

输入输出样例 #1

输入：

4 5
00000
00*00
0*0*0
00*00

输出：

1

输入输出样例 #2

输入：

5 5
*****
*0*0*
**0**
*0*0*
*****

输出：

5

代码

#include <bits/stdc++.h>
using namespace std;
int n,m;
int a[501][501];
int kx[5]={0,1,-1,0,0}; 
int ky[5]={0,0,0,1,-1};
void dfs(int x,int y){
    a[x][y]=1;
    for(int i=1;i<=4;i++){
        int x0=x+kx[i];
        int y0=y+ky[i];
        if(x0>0&&x0<=n&&y0>0&&y0<=m&&a[x0][y0]==0)  dfs(x0,y0);
    }
}
int main(){
    char e;
    cin>>n>>m;
    for(int i=1;i<=n;i++){
        for(int j=1;j<=m;j++){
            cin>>e;
            if(e=='*')  a[i][j]=1;
            else    a[i][j]=0;
        }
    }
    for(int i=1;i<=n;i++){
        if(a[i][1]==0) dfs(i,1);
        if(a[i][m]==0) dfs(i,m); 
    }
    for(int i=1;i<=m;i++){
        if(a[1][i]==0) dfs(1,i);
        if(a[n][i]==0) dfs(n,i); 
    }
    int s=0;
    for(int i=1;i<=n;i++){
        for(int j=1;j<=m;j++){
            if(a[i][j]==0)s++;
        }
    }
    cout<<s;
    return 0;
}

P10442（洛谷题面）

题目

题目描述：

给定字符串 $s,t$。

现在你要在 $s,t$ 中删除一些字符并将它们重新排列使 $s=t$。

问操作后的 $|s|$（即字符串 $s$ 的长度）最大是多少？

输入格式：

第一行一个字符串 $s$。

第二行一个字符串 $t$。

输出格式：

一行一个整数，表示操作后的 $|s|$ 的最大值。

数据范围与说明：

在第一个样例中，将 a 删除，留下 bc。

此时 $|s|=2$，可以证明这是最优解。

在第二个样例中，将 aaaaa 删除，留下空串。
将 bbbbb 删除，留下空串。

此时 $|s|=0$，可以证明这是最优解。

本题采用捆绑测试。

记 $n=\max(|s|,|t|)$。

对于 $100%$ 的数据，$1 \le |s|,|t| \le 10^5$，字符串均由小写字母组成。

特殊性质 $\text{A}$：$s$ 是一个 $\text{a}\sim\text{z}$ 的排列。

特殊性质 $\text{B}$：保证 $si,ti\in{\text{a},\text{b} }$。

输入输出样例 #1

输入：

abc
bc

输出：

2

输入输出样例 #2