136 张图片恢复报告

这张图是Agent项目的工作流程图，呈现了四个分工明确的智能体运作逻辑，从左到右依次为预约机器人Agent、分类机器人Agent、咨询机器人Agent、用户行为分析Agent。分类机器人Agent会先对用户输入分类，仅处理按摩房相关需求，无关内容直接拒绝。预约机器人接收需求后收集信息，匹配技师及相关方案并写入数据库。咨询机器人读取数据库相关信息，从私有文档中提取答案后返回结果。用户行为分析Agent依据数据库的用户历史预约数据，生成个性化回访信息，四个Agent分工协作完成项目功能。

这是一份大模型相关的项目实战简历示范，用于说明如何围绕大模型项目制作简历。简历内容涵盖教育经历、专业技能，以及两个核心项目：其一为企业智能客服与预约Agent系统，属于Agent/LLM应用开发，涉及多轮交互、意图识别等功能，适配客户诉求、预约提醒等场景；其二为模块化企业知识检索Agent RAG系统，属于RAG/LLM应用开发，用于实现企业内部知识的高效检索问答。这份简历示例可帮助求职者展示相关技术能力与项目成果，适配大模型相关岗位的求职需求。

图片展示了一位AI应用开发工程师的简历示例，姓名为“姓名”，方向为Agent / RAG / 本地模型。教育经历显示其在某大学计算机专业就读。专业技能包括自然语言处理、LoRA/QLoRA、SFT、PTT、Response-only Loss等。项目经历中，其曾为企业智能知识检索开发Agent平台，还涉及React、RAG、BM25、LoRA等技术。此外，还介绍了其掌握的编程语言、框架、库等，以及技术栈。该图片与文档中简历示范部分内容对应，直观呈现了简历中关键信息。

图片展示了一位AI应用开发工程师的简历示例，姓名为“姓名”，方向为Agent / RAG / 本地模型。教育经历包括在某学校读本科，专业为计算机科学与技术，学制4年，起止时间为2016 - 2020。专业技能涵盖Agent、RAG等，项目经历为在某企业后端开发智能Agent系统，涉及LLM、RAG等技术，还介绍了相关技能和项目成果。该图片与文档中简历示范部分内容对应，直观呈现了简历中关键信息的展示形式。

这是一份AI应用开发工程师的简历示范，求职方向为Agent、RAG、本地模型，包含姓名、联系方式、GitHub及个人主页等基础信息，还标注了学历、专业名称、起止时间等填写提示。简历的专业技能部分列出了Spring Boot、MyBatis、Redis等后端开发相关技术，以及LangChain、OpenAI、Qwen等大模型相关技术。项目经历分为两个部分，一是“离并发服务预约与订单调度平台”，介绍了该平台的功能模块、涉及的技术栈及开发难点的解决方式；二是“企业智能客服Agent与本地知识平台”，说明了该平台的核心功能、采用的技术，还列出了版本控制、持续集成相关的技术工具，与文档中提及的项目组合、简历编写的内容相呼应，是结合了后端与大模型相关项目的简历示例。

图片展示了大语言模型生命周期，分为5个阶段：1. 预训练，对大规模语料进行下个词预测；2. SFT/监督微调，使用标注数据对模型进行微调；3. 奖励模型训练，通过人类偏好对比训练奖励模型；4. 政策更新/强化学习，采用PPO或GRPO优化；5. 部署/推理，向用户和应用提供服务。其中，RLHF（人类反馈强化学习）贯穿奖励模型训练和政策更新阶段。该图与上文大模型完整生命阶段的内容相呼应，直观呈现了大模型从出生到部署的流程。

这张图片展示了神经网络的训练过程，分为前向传播和反向传播两个阶段。第一阶段为前向传播，输入数据经过输入层、隐藏层，传递至输出层计算损失，其中各层的激活值、中间结果都需要缓存以作后续使用。第二阶段为反向传播，优化器以Adam为例更新权重，计算各层的梯度，依据梯度调整模型参数。图片还展示了GPU内存中占用的不同内容，包括模型参数、梯度、优化器状态及激活值的存储规格，还在底部标注了推理阶段仅进行前向传播，无需梯度和优化器状态，占用内存更小。

这张RAG基本工作流程图分为离线知识库构建链路与在线用户问答链路，清晰呈现RAG的核心运作流程。其中绿色标识的是离线知识库构建链路，对应“提前准备参考书”，包含从原始文档经文档解析、清理、分块、元数据生成、向量化，最终存入向量数据库知识库的7个步骤；蓝色标识的是在线用户问答链路，涵盖用户问题提出、上下文补全、意图理解、歧义判断与澄清追问、查询处理、检索与筛选、重排序/压缩、生成回答、返回用户共9个步骤，还有紫色和橙色的节点分别对应检索增强与后处理、意图澄清判断节点，完整展示RAG系统的运作逻辑。

图片为RAG与微调在成本、维护难度、响应速度、准确性、适用场景等方面的对比表格。RAG在成本上初始成本低，无需训练模型，但运行时需检索资源；维护难度上知识更新简单；响应速度上检索+生成，速度受检索影响；准确性上依赖检索质量；适用场景为多领域问答等。微调在成本上初始成本高，但推理成本低；维护难度上知识更新困难；响应速度上直接生成，延迟低；准确性上对训练数据质量敏感；适用场景为固定领域任务等。该图与上下文介绍的RAG与微调的对比内容相契合。

这张图片是一款常见向量数据库的功能信息对比表，核心包含Milvus、Weaviate、Chroma、Qdrant四个向量数据库的相关信息，涵盖名称、底层索引、优点、缺点、适用场景、量级支持六个维度。Chroma这款向量数据库的信息与上下文内容对应，它的底层索引为FAISS，优点是轻量、嵌入式、易用，缺点是不适合大规模数据，适用于本地语义搜索、原型开发，支持的量级为万-十万级，这些信息和文档中对Chroma的介绍相吻合。

这张图是RAG中意图识别环节的流程示意图。图中展示了该环节的三大步骤：步骤一为判断问题类型，通过问题类型判断将用户输入的问题分为定义类、事实类、流程类等7种不同类型；步骤二是抽取实体与槽位，具体包括实体识别和槽位抽取；步骤三是决策检索策略，针对不同情况匹配对应的策略，如问题明确直接检索、口语化时查询改写、词不匹配时查询扩展等。该图直观呈现了RAG意图识别的完整实现流程。

这张图展示了PDF文件处理为可用Markdown或结构化文本的完整流程，共包含五个核心步骤：第一步是文件基础体检，需确认PDF能否处理、完成文件去重、解密、损坏检查与页数记录；第二步是逐页判断类型，将页面归为原生文本页、扫描页、混合页、复杂布局页或异常页；第三步是按页面类型解析，不同页面需对应不同处理方式，如原生文本页直接提取、扫描页用OCR识别等；第四步是统一结果，将解析内容统一格式并按阅读顺序合并为完整文本；第五步是结果检查，确认漏页、乱码等问题后，输出可用的Markdown或结构化文本。

图片为一段英文文字，内容涉及对世界理解的重要事物，如对世界回报呈超线性增长的理解。文字以不同颜色突出显示关键部分，如“superlinear returns are a feature of the world”“the rich get richer”“exponential growth”等。文字还提到教师和教练常告知回报呈线性，但实际并非如此，超线性回报是世界特征，如财富、权力、军事胜利等。图片与上下文紧密相关，是对上下文关于世界回报超线性增长这一核心概念的视觉呈现。

图片展示了递归分块后的数据形态。原始文档被分隔符优先级（\n\n、！？、字符级强制切分）分割，分为源区域1、2、3、4。源区域1、2、3分别对应Chunk 1、2、3，源区域4因内容超长，采用字符级强制切分，对应Chunk 4、5。该图与上下文紧密相关，直观呈现了递归分块中源区域与输出分块的对应关系，帮助理解递归分块的分块逻辑。

图片为RAG文档分块选型方法论图示，展示了文档分块的5个关键步骤。1. 判断文档结构，先看文档是否清晰；2. 确定Chunk粒度，根据检索目标定位；3. 建立实验基线，结构化分析；4. 根据实际问题调整，召回不刷新、减少Overlap、减少Token成本；5. 通过评测确定方案，评估指标包括Hit Rate、MRR、重叠率、Token成本、查询延迟。底部强调没有放之四海而皆准的方案，需持续实践、数据驱动、业务场景适配。

图片是一张表格，对比了四种精排方法：Cross Encoder精排、LLM精排、规则精排和混合精排。表格从核心思路、优点、缺点和适用场景四方面进行说明。如Cross Encoder精排将问题和候选文档一起输入模型判断相关性，优点是语义匹配能力强等。该表格与上下文紧密相关，是对文档中精排方法相关内容的直观呈现，帮助读者更清晰地了解各精排方法的特点及适用场景。

这张图展示了KG-RAG中知识图谱的结构示意，左侧为知识图谱的通用模型，包含“节点”“边”和“关系”三个核心要素，节点代表实体，边体现实体间的关系。通过箭头指向右侧的具体示例，以云南、丽江、大理、洱海、小秦、小明等实体为例，呈现实际的实体关联关系，比如云南属于丽江、大理属于云南、小秦住在丽江、小明住在大理且是小秦的朋友。该图直观对应文档中提及的KG-RAG做法，即把RAG召回的文本映射为知识图谱实体，沿图中关系扩展检索，得到与问题相关的关系链。

图片展示了经典RAG和Self-RAG的流程对比。上层是经典RAG流程，用户提问后判断是否检索，若需检索则进行检索、知识检索、基于不同Chunk生成K个候选答案、候选评估、选择最高分候选、最终输出；若无需检索则模型直接回答。下层是失败诊断与修正流程，包括IsREL低生成补充检索证据、IsSUP低保留有效证据重新生成、IsUSE低调整回答要求重新生成等步骤，质量不达标时还有修正路径。该图直观呈现了Self-RAG在经典RAG基础上引入自我检查的特点。

图片展示了广义RAG与传统RAG的概念。广义RAG涵盖任何形式的检索，包括文本精确匹配、关键词检索、网页搜索、数据库查询等。传统RAG则指分块+嵌入+向量数据库的检索方式，由文档分块、文本嵌入和向量数据库组成。图片通过两个同心圆圈呈现，外圈标注“广义RAG：坚实的基础，包容所有检索方式”，内圈标注“传统RAG：被部分替代的旧范式”，直观呈现了两者关系，与上下文对RAG概念的讨论相契合。

该图片位于文档中RAG趋势探讨下“数据的结构化程度”相关内容处，用于对比关键词/grep搜索与embedding/语义搜索的差异。图中以用户搜索“四川菜”为例，左侧用红色叉号标注的关键词搜索仅依赖字面匹配，无法识别“四川菜”的真实语义，对麻婆豆腐、水煮鱼这类相关菜品的搜索结果均判定为不匹配；用绿色对号标注的语义搜索则能理解“四川菜”的真实含义，匹配到麻婆豆腐、水煮鱼这两类相关菜品。该图片直观解释了文档中“为什么代码（结构化）不用RAG”的内容，体现了语义搜索在处理非结构化需求时的优势，也清晰呈现了两种搜索方式的核心区别。

这张图对比了长上下文与RAG的差异，左侧代表长上下文模式，以AI身处满是信息碎片的灰色背景中，表现出上下过长、注意力分散、效率低下、效果不确定的问题，核心是“漫无目的地找”，存在信息淹没、难以找到关键内容的痛点；右侧代表RAG模式，以AI站在盛载检索关键片段流程的托盘旁，体现出精准聚焦、高效检索、效果更好、更可控可靠的特点，流程涵盖上下文关键词匹配、位置编码优化等环节，核心是“有方法地精准找”，能让大模型专注关键信息，输出更准确高效，是企业级知识处理的可行方案。

图片是一张流程图，标题为“如何选择合适的检索方式？”。图中以“结构化数据（例如代码）”为起点，若为非结构化数据则判断能否放入上下文窗口，若能则使用长上下文，若不能则选择传统RAG或grep/ripgrep。若为结构化数据且查询需语义/同义扩展，且数据规模不大则使用BM25，若数据规模很大则选择嵌入+向量数据库或Agentic RAG。该图与文档中RAG最佳实践清单相关，用于指导选择合适的检索方式。

这张图片是一张表格，展示了不同Agent开发框架的相关信息，表格包含框架类别、官方代表仓库、GitHub Stars、一句话特点、典型场景、主要语言/生态六列内容。其中重点用深色标注的前三名框架，分别是Dify（152.1k Stars，低代码AI应用平台，主要语言为Go）、LangChain（143.9k Stars，高层应用框架，主要语言为Python）、CrewAI（56.9k Stars，多Agent框架，主要语言为Python），与上下文中提及的排序内容完全对应，清晰呈现了各框架的核心属性。

图片展示了Agent工作流程。左侧有Agent指令、Tools工具、Output输出格式三个板块，分别定义Agent角色、可用工具及功能说明、输出结构等。右侧是Agent、大模型和输出答案三个部分，Agent先思考，再调用工具，大模型返回结果，最后输出答案。该图与上下文紧密相关，直观呈现了Agent在指令、工具、输出格式的指引下，与大模型交互完成任务并输出答案的流程。

图片展示了Agent开发框架中使用LangGraph搭建状态图的流程。用户输入State后，经Agent Node处理，若需调用工具则进入Tool Node，否则结束。Tool Node处理后返回State，再经Review Node更新State，循环往复。图中用箭头表示State在节点间的传递和更新，还标注了Node节点（执行任务单元）和Edge边（有向路径，标注State流动方向）的概念，以及State状态（图中流动数据，被节点读取和更新）。

图片展示了Agent团队协作完成撰写深度文章的流程。总任务为撰写一篇关于“人工智能发展趋势”的深度文章。研究员Agent负责信息收集与分析，产出高质量研究结果；写作者Agent进行内容创作，撰写结构清晰的文章草稿；审核员Agent进行内容审核与优化，输出准确、优质的最终文章。三者协作，最终产出高质量的最终文章。该图与上下文介绍的组织Agent团队定义Role、Task和协作关系的内容相契合，直观呈现了协作过程。

图片展示了Agent工作循环流程。长期任务由开发者提交，构建市场调研报告，包含行业分析、竞品分析、趋势洞察和建议方案。Agent收到任务后，制定计划，理解任务、拆解步骤、制定执行计划；使用工具，按需调用环境中的工具或资源；检查结果，评估输出是否符合预期，发现问题。任务清单和已保存的中间产物示例也呈现其中。该图与上下文紧密相关，直观呈现了Agent开发框架中Agent团队定义Role、Task和协作关系的工作流程。

这张图片展示的是知识管道的搭建流程，对应文档中提到的搭建知识管道的内容。该流程从左侧的数据源开始，数据源包含PDF、网页、数据库三类内容，首先将数据源中的内容进行文档切分，之后生成知识索引并存储为数据库形式。接着，用户问题会指向检索相关片段的环节，该环节会结合用户问题完成检索，得到检索结果后，将其与用户问题共同输入Agent，由Agent基于资料完成回答。这张图清晰呈现了从数据源到最终Agent输出的完整知识处理链路，与文档中介绍的方法五内容相互对应。

图片展示了Agent开发画布，分为模型、Prompt、知识库、工具四个部分，每个部分可配置。模型选择或配置大语言模型，Prompt设计提示词与指令模板，知识库连接数据源检索知识，工具集成工具扩展能力。右侧是开发流程，包括测试（运行并验证效果）、发布为API/聊天应用（一键发布上线）、运行日志（查看调用与效果）。该图与上下文介绍的Agent开发框架中知识管道的搭建相关，直观呈现了配置Agent、编排Workflow等全生命周期内容。

这张图是AI Agent框架选型指引图，配合文档中的框架选型策略内容，用于指导不同场景下的框架选择。图中通过四个步骤的框架选型逻辑，逐步明确不同需求对应的适配框架，第一步先依据团队或平台是否有微软、谷歌等对应的生态及需求，第二步结合项目核心问题如复杂状态、长任务、代码编辑等选择对应框架，第三步围绕Agent安全性、工具集成等需求匹配框架，第四步按模型或云平台是否确定来筛选，最终延伸至工作流、长任务等框架类型分类，清晰呈现了Agent框架的选型思路。

这张图片是LangChain各版本的对应说明表格，清晰呈现了该框架不同版本的信息。表格设置了版本、发布时间、主要变化三类内容，其中2025年发布的v0.3.6版本，在文档上下文里被提及是25年中项目使用的版本，该版本的核心变化为引入部分Graph概念，为后续v1.0版本做准备。该表格还记录了其他版本的发布时间与功能调整，比如2024年发布的v0.3.4版本优化了多模型支持，2025年11月的v1.0.x版本完成了架构重构，这些信息能帮助掌握不同阶段LangChain的迭代情况。

这张图片展示了Agent评测的相关内容，清晰呈现了Agent评测的逻辑：输入指令后，Agent会经历观察、调用工具、规划、再规划的流程后输出结果。由于Agent具有输出不确定的特性，相同输入会产生不同输出，图中示例了三种输出结果的不同评分：输出结果A因内容全面、逻辑清晰得4.5分，输出结果B因内容基本完整但分析不足得3分，输出结果C因内容不相关错误多得0分，印证了Agent评测无法采用传统的“输出等于期望值”的断言方式，只能通过打分评估效能的特点。

图片展示了Agent评估生命周期，涵盖上线前验证和上线后监控。上线前验证包括模型选择、成功标准、组件评估、系统评估及发布门，对应成本、效率、延迟、安全、合规等指标。上线后监控则有金丝雀测试、可观测性、漂移和异常检测、在线风险和成本监控，通过真实流量、持续告警和反馈闭环实现。该图与上下文紧密相关，直观呈现了Agent评估的全流程，是理解各阶段测什么、对应哪一节的基础。

图片展示了LLM-as-a-judge的三种用法与陷阱。1. 单点打分，裁判对待评输出进行评估，给出单一分数（1 - 5分）；2. 对参考打分，裁判将待评输出与标准答案进行对比，给出是否正确或质量达标的判断；3. 两两比较，裁判比较两个输出，选择更好的一个。底部还指出裁判有三大偏见：自我偏好、首位偏差、冗长偏差。该图与上文评测中LLM-as-a-judge的自我偏好、首位偏差、冗长偏差内容相呼应，直观呈现了相关概念。

图片展示了Agent评测的流程。用户提问“明天会下雨吗？”，工具清单有check_weather和check_availability，标准答案为check_weather(date=2026 - 06 - 26)。Agent调用check_weather(date=“明天”)，判分器逐项核对函数名、必填参数、有无瞎编参数、参数值是否对，其中参数值对为失败，错在参数值未归一化。图片还提到需测试“你们几点关门？”这类不需要工具的问题，看Agent是否会克制、不乱调工具。

图片展示了Agent规划/推理评测的内容，以对照“理想步骤链”抓三类失败（步骤选错/违反约束/自以为完成）为原则。理想步骤链包括查档期、匹配技师、确认下单。Agent实际步骤链有Path A、Path B、Path C，分别出现步骤缺失、违反时间约束、匹配失败等问题。图片还强调评测要点，不仅看单步是否正确，还要检查步骤是否完整、是否满足约束、是否真实完成任务。

图片展示了轨迹评测中三种匹配宽松度的示例。标准轨迹为参考答案，包含搜索、筛选、下单、确认四个关键节点。精确匹配要求顺序数量完全一致；按序匹配允许多余步骤，关键节点顺序对即可；任意顺序匹配关键节点都出现即可，不计顺序。图片与上下文紧密相关，直观呈现了轨迹评测的三种匹配方式，帮助理解只看结果误判的问题，强调过程正确的重要性。

这张图片展示了Agent评测中多轮交互评测的相关细节，对应文档里的多轮交互评测内容。评测以固定环境、隐藏目标、Rubric为基础，动态生成多轮对话而非使用固定的标准对话。评测分为三个区域：左栏是固定的评测三件套，包含环境/后台状态、隐藏用户目标、Rubric评分表；中栏展示运行时的动态多轮对话过程，用户模拟器会模拟真实用户与被测Agent交互；右栏是终态和关键行为的Rubric评分，分为代码assert和LLM Judge两个通道，最终通过Pass/Fail判定，核心要求是同一任务重复跑4次且全部通过，才能说明Agent性能稳定。

图片展示了VitaBench三维复杂度框架，基于POMDP建模。框架以Agent任务为中心，从推理、工具、交互三个维度全面刻画任务复杂度特征。推理复杂度维度包括观测空间大小、部分可观测程度、推理点数量；工具复杂度维度有66个工具、512条依赖边、调用链长度；交互复杂度维度涵盖用户画像、行为建模、动态状态演化。该框架是VitaBench的最大学术贡献，实现了任务复杂度的可控、可量化。

图片展示了VitaBench工具依赖图（示意），以美团LongCat为例，呈现了66个真实工具及512条依赖边。图中工具节点以不同颜色标识，如“搜索餐厅”“查看菜单”“查询库存”等，部分节点用橙色突出显示，如“下单”“导航”等。箭头表示调用关系，如“查询库存”依赖“搜索餐厅”等。该图与上下文紧密相关，直观呈现了VitaBench评测中模型需推理的复杂依赖网络，强调其评测更接近真实的特点。

图片是一张表格，对比了工具函数调用与模型上下文协议（MCP）在标准化程度、功能范围、系统架构、发现机制、可复用性等方面的特性。如在标准化程度上，工具函数调用由厂商专有实现，MCP是开放的标准化协议；在功能范围上，工具函数调用是LLM直接调用执行特定预定义功能，MCP构建LLM与外部工具发现和通信的完整框架体系等。该表格与上下文紧密相关，直观呈现了MCP与工具函数调用在各方面的差异。

图片是一张表格，对比了本地MCP Server和远程MCP Server在部署位置、连接协议、安全性、性能、延迟性、扩展性及生态支持等方面的差异。本地Server部署在本地机器，连接协议通常为Stdio，安全性低，性能受本地硬件限制，延迟低，扩展性受限，生态支持好；远程Server部署在云端或远程服务器，连接协议为HTTP，安全性更高，性能不受本地限制，延迟相对更高，扩展性强，生态支持不足。该表格与上下文介绍MCP本地Server和远端Server的对比内容紧密相关。

图片展示了Langgraph中短期记忆和长期记忆的实现。左侧为短期记忆，以蓝色框呈现，包含“Human message”和“AI message”交替出现的对话信息，通过“Checkpointer”实现，与LLM（大型语言模型）相连。右侧为长期记忆，以黑色框呈现，类似键值数据库，支持语义检索，保存在自定义“命名空间”中，同样与LLM相连。该图直观呈现了上下文信息存储与检索的机制，与文档中介绍的记忆功能实现内容相呼应。

这是多智能体架构对比示意图，对应文档中Multi-Agent架构的典型Agent架构内容。图中清晰展示了5类Agent架构，分别为单智能体、独立型、中心化、去中心化与混合型。每类架构均以拟人化图标与文字标注呈现，单智能体仅含一个机器人及单任务标识，独立型对应多个独立机器人及对应任务，中心化以中心节点连接各智能体，去中心化呈多智能体网状互连，混合型则是中心节点结合多组分布式智能体的结构，直观对应了文档中提及的不同Agent架构类型。

图片是一张表格，对比了不同Agent架构类型及其最适合的任务类型和原因。单智能体适合顺序推理任务，因单Agent基线收益高，引入多Agent反而性能下降。独立型适合消除幻觉的并行任务，用集体投票对抗个体幻觉。中心化适合金融推理等边界清晰任务，由主脑协调整合。去中心化适合动态网络浏览等任务，各智能体自主调整行为。混合型适合复杂任务，需层级控制和有限对等通信。该表与上下文关于Agent架构设计原则的内容相关，为选择合适Agent架构提供参考。

图片展示了Agent 1调用Agent 2时，Agent 2看到的不同内容。左侧显示Agent 1直接将整体状态传递给Agent 2，状态包含“messages”和“artifacts”；右侧则说明Agent 1使用LLM + tools来确定Agent 2看到的内容，内容为“tool_arg1”和“tool_arg2”。该图与上下文紧密相关，直观呈现了工具调用（Tool Call）中Agent 1与Agent 2交互时，Agent 2接收到的不同信息形式，帮助理解Agent之间通信和状态管理的差异。

图片展示了Agent 1调用Agent 2时，Agent 1收到的两种不同响应情况。左侧显示Agent 1收到Agent 2的工具调用、工具调用结果及最终响应，还包含Agent 2的中间推理过程；右侧仅显示Agent 2的最终响应。该图与上下文紧密相关，上下文讨论Agent与Agent之间传递消息的两种方式，此图直观呈现了传递完整推理数据与仅传递最终响应的区别，帮助理解消息传递内容的权衡。

图片是一张表格，展示了大模型推理中常见的参数及其含义、作用机制、取值范围和使用建议。参数包括temperature（温度）、top_p（核采样）、max_tokens（最大标记数）、presence_penalty（存在惩罚）、frequency_penalty（频率惩罚）。如temperature用于控制输出的随机性，取值范围0 ~ 2.0；top_p从累积概率达到p的最小token集合中采样，取值范围0 ~ 1.0；max_tokens限制输出长度，取值范围1 ~ 模型上限；presence_penalty对已出现过的token施加固定惩罚，取值范围-2.0 ~ 2.0；frequency_penalty按token出现次数累加惩罚，取值范围-2.0 ~ 2.0。

图片为LLM推理参数详解表，展示了不同场景下参数的推荐值。场景包括分类任务、信息提取、普通对话、长文章生成、创意写作、头脑风暴等。各场景下temperature、top_p、max_tokens、presence_penalty、frequency_penalty参数均有对应数值，如分类任务temperature为0，max_tokens为50等，直观呈现了参数在不同场景下的配置情况。

图片展示了ReAct框架的Agentic Loop流程。首先接收输入，包括用户Prompt、System Prompt、工具定义及对话历史；接着进行模型推理，Claude分析上下文生成回复，回复包含文本及工具调用请求（可选）；随后判断是否调用工具，若否则返回最终结果；若调用工具，则执行工具，Harness执行工具收集结果（仅限检查→执行→返回结果），最后将工具结果追加到对话历史。该图与上下文紧密相关，直观呈现了ReAct框架的运作流程。

图片展示了Openclaw架构图。最上层是触发层，有五种独立触发维度，分别是Messages（消息）、Heartbeats（心跳）、Crons（定时任务）、Hooks（钩子）、Webhooks（Web钩子）。中间层是Gateway层，包含HTTP/WS Server、Channel Manager、Router、Plugin System、Auth、Node Registry & Config等组件。最下层是Agent层，有推理引擎、工具执行、记忆（Remember）等功能。该图与上下文紧密相关，直观呈现了Openclaw的层次结构及各层功能。

图片展示了Openclaw的五种独立触发维度及其触发方式和典型场景。维度包括Messages（人类）、Heartbeats（心跳）、Crons（定时）、Hooks（钩子）、Webhooks（Web钩子）。触发源有Humans（人类）、Time（时间）、Internal Events（内部事件）、API（API）。触发方法有User sends messages in any channel（在任何渠道发送消息）、Periodic timer（周期性定时器）、Custom cron schedule（自定义cron调度）、Gateway/Agent lifecycle events（网关/代理生命周期事件）、HTTP POST to registered endpoint（向注册端点发送HTTP POST）。典型场景涵盖Casual Chat、Alerts、Patrols、Daily 9 AM Report、Session Storage、Message Preprocessing、GitHub Alerts、3rd Party Callbacks等。

图片展示了Openclaw Gateway模块及其职责。HTTP + WS Server是统一的通道和客户端连接入口；Channel Manager管理每个通道的生命周期；Message Router基于会话键路由消息；Plugin System发现并加载插件，注册额外通道/工具/CLI命令；Auth & Security进行认证、授权、速率限制；Node Registry通过Bonjour/mDNS发现设备，管理iOS/Android配对；Config Manager读取配置文件，支持热重载及环境变量替换。该图与上文介绍Gateway作为本地长驻Node.js进程，监听端口18789，是触发层和Agent层中间件的内容相呼应，直观呈现其核心职责。

这是一条来自名为Itamar Golan的用户发布的推文内容，推文搭配手持苹果电脑主机的配图。推文中提到，用户搭建了clawdbot工具，用于每天给妻子发送早晚问候及工作日的日常问候消息，24小时后该工具就能在无需用户参与的情况下，和妻子展开完整对话，用户评价这项技术极其惊人，推文末尾用户提及自己已经很久没和妻子交流了。

该图片对应Openclaw四层记忆架构的可视化示意图，直观展示了其四层记忆机制的运行结构。第一层为Bootstrap Files，对应硬盘，内容每次会话加载且完全免疫压缩；第二层是Session Transcript，以JSONL格式存储在磁盘，提供会话转录内容；第三层为Context Window，对应RAM内存，包含系统提示、引导文件、会话历史、工具结果及当前消息，满了会触发压缩；第四层是Retrieval Index，对应搜索引擎，为独立的SQLite语义检索存储，支持按需搜索工具结果。通过该示意图，可清晰对应文档中“四层独立机制协同工作、解决Agent忘事问题”的相关说明。

图片展示了Openclaw中Session Transcript的压缩过程。压缩前，上下文使用176K/200K，接近上限；压缩中，模型将旧消息分块、逐块生成摘要、合并摘要；压缩后，上下文使用40K/200K，释放空间。压缩区旧消息被压缩，保留区原文（最近~20,000 tokens）保持不变。图片与上下文紧密相关，直观呈现了压缩过程及上下文结构变化。

图片展示了OpenClaw Agent架构图。外部世界通过消息通道接收消息，路由和调度由无智能的Gateway承担。Gateway将消息分发至会话，会话执行Agent任务，任务结果通过callGateway()告知Gateway，最终由Gateway返回最终回复。Agent执行层为递归中心化架构，Parent Agent用LLM决策任务拆解，子Agent可继续spawn孙Agent，形成Orchestrator-Worker树。

这张图片是关于Hermes记忆系统静态结构的全景表，列出了该系统的各类记忆相关组成部分，包含名称、存储位置、编写主体及进入上下文的方式。其中明确标识出多个核心内容：Context Window、Bootstrap Files、memory/笔记、Skill Library、Session Transcript、Honcho User Model、Retrieval Index这七类项目，且标注出Hermes独有Skill Library与Honcho User Model；特别突出显示的Retrieval Index说明为“X 不直接进——只是让搜索快”，可对应上下文中关于Hermes记忆系统构成及与OpenClaw差异的内容。

图片展示了Hermes记忆系统中“被‘读’的典型场景”相关内容。场景包括续会话、会话结束归档、自进化反思、TUI回滚/分叉、训练数据生成、调试/导出/迁移等，对应读取范围从.jsonl尾部加载、扫描本次session写成md、回看对话判断沉淀、按entryId定位历史消息、整段导出为trajectory、整段读取。该图与上下文紧密相关，是对文档中“被‘读’的典型场景”部分的直观呈现。

图片为一张表格，对比了USER.md和Honcho在存储、更新方式、内容来源方面的区别。存储上，USER.md为磁盘md文件，Honcho为独立服务；更新方式上，USER.md为静态手写，不改就不变，Honcho为动态模型，对话后台自动更新；内容来源上，USER.md由用户自己写，Honcho由Hermes / 自进化循环从过往对话里推断。该表与上下文内容紧密相关，直观呈现了两者在记忆系统方面的差异。

图片是一张表格，展示了Hermes记忆系统中不同子类的数据写入来源及时机。表格包含子类、写入来源、写入时机三列。Bootstrap Files子类的写入来源为用户手写、从OpenClaw迁移、首次运行生成，时机是一次性/用户编辑时；memory/笔记子类的写入来源为自进化循环自动、会话结束自动归档、用户手写，时机是自进化循环周期性触发；/new /reset时自动保存；Skill Library子类的写入来源为预置、用户、自进化循环自动，时机是任务完成且自进化循环判断“可抽象”。该表与上下文介绍的Hermes记忆系统写入策略相关。

图片是一张表格，展示了Hermes记忆系统中三个关键数据源的写入来源、时机等信息。表格包含名称、写入来源、写入时机三列。Session Transcript的写入来源是系统自动，时机是每条消息、每次tool call实时append到JSONL；Honcho User Model的写入来源是自进化循环/对话后台自动，时机是每次对话后持续更新；Retrieval Index（索引）的写入来源是文件监听器自动，时机是memory/等md文件变化后1.5秒内重索引。该表与上下文介绍的Hermes记忆系统写入策略相关，是对写入来源和时机的具体说明。

图片是一张表格，对比了OpenClaw Pre-Compaction Flush和Hermes自进化循环的触发时机、模式、更新范围及关注维度。OpenClaw仅在压缩前触发一次，模式为事后归档，更新范围只写memory/ YYYY-MM-DD.md，关注维度是“别让重要信息被压缩丢了”。Hermes每~15次tool call触发，模式为持续反思，更新范围包括memory、skill、Honcho三路，关注维度是“值不值留+失败要避免+流程能抽象”。该表与上下文紧密相关，用于说明两者机制的区别。

图片展示了Hermes记忆系统的动态更新策略与6层静态记忆的映射关系。左侧列出Bootstrap Files、Session Transcript、Context Window、Retrieval Index、Skill Library、Honcho User Model等6层静态记忆，对应其Writer和Reader操作。右侧是四种动态策略，包括Write Strategy、Read Strategy、Compact Strategy、Auto-evolve Generation等，与左侧记忆层对应。该图与上下文紧密相关，是对Hermes记忆系统动态更新策略的全景图示，帮助理解各策略在不同记忆层的应用。

图片是一张表格，对比了OpenClaw和Hermes在工具名、Runtime选项、默认深度、子Agent上限、ACP协议等方面的差异。OpenClaw的工具名是sessions_spawn，Runtime选项为subagent / acp，默认深度为maxSpawnDepth=1，子Agent上限为maxChildrenPerAgent=5，ACP协议作为harness调用Codex等。Hermes的工具名是spawn_subagent，Runtime选项为subagent / acp / modal（serverless），默认更宽松，子Agent上限可配置且在批量模式下大得多，ACP协议是原生ACP server，可被OpenClaw调用。该表与上下文介绍Hermes Agent架构中Spawn机制对比的内容相关。

图片展示了从提示词工程到循环工程的人机交互演进过程。从左至右依次为：1. 提示词工程（Prompt Engineering），人类参与度高；2. 上下文工程（Context Engineering），人类参与度降低；3. Harness工程，系统自主性增强；4. 循环工程（Loop Engineering），系统自主性最高。底部文字“人逐步从‘执行者’退到‘设计者’”总结了这一演变趋势。该图与上下文提到的行业演进脉络相呼应，直观呈现了人和AI打交道单位从“一次对话”变成“一个完整回路”的转变。

图片展示了“人在循环里”与“Agent自己循环”两种循环模式。左侧“人在循环里”中，人不断提示AI，AI生成结果后人再查看，形成循环。右侧“Agent自己循环”中，人启动任务后，Agent生成内容，再生成、自检、修正，最后人退到一旁放心喝咖啡。该图与上下文关系紧密，直观呈现了循环工程中人与Agent的不同参与方式，帮助理解循环工程的含义。

图片展示了Agent循环工程中一个loop的组成要素。上方定时任务Automations，下方状态文件State File（公共记忆），中间由工作目录worktree、项目说明书Skill、连接器MCP、子Agent（写/审分离）五个部分拼接而成。每个部分通过箭头与状态文件双向读写，表明每个循环都会双向读写状态。该图与上下文紧密相关，直观呈现了上下文提到的六样拼起来的完整loop结构。

图片展示了Peter Steinberger于2026年7月18日12:34 AM发布的推文。推文内容为“Are we still talking loops or did we shift to graphs yet?”（我们还在讨论循环吗，还是已经转向图了？），并用蓝色圈出“2.7M Views”（270万次浏览）。该推文获得了1.2K条评论、372次转发、7.5K个点赞和2.7K次收藏。图片与上下文紧密相关，直观呈现了该推文的浏览量，呼应了上下文提到的这条推文获得约270万次浏览，以及Hamel Husain关于Graph工程登场的推波助澜。

图片展示了Agent Engineering Stack，从Prompt Engineering到Graph Engineering。上方是Graph Engineering流程图，从Start经Plan、Retrieve Context、Decide Next Step等步骤至End。下方是Graph Engineering的细化图，包含Loop Engineering、Harness Engineering、Context Engineering、Prompt Engineering四个层次，各层次间有箭头连接，如Tool Calls指向Harness Engineering等。该图与上下文紧密相关，直观呈现了Agent工程中不同层次的概念及关系。

图片展示了Loop工程中Agent执行流程。触发任务后，Agent执行工作，如修复失败构建；运行测试、类型检查、Reviewer Agent或规格差异检查；判断目标是否验证通过。若未通过，流程进入“Hard brakes”阶段，包括迭代次数、无进展、预算/天等限制条件，如达到迭代次数、无进展或预算上限等，停止并交给人类。该图与上下文紧密相关，直观呈现了Loop工程中Agent执行的完整流程及关键环节。

图片展示了自动代码审查流程。Codex开启PR后，系统并行启动多个审计Agent，分别检查安全、逻辑与性能、代码风格与文档。多个审计结果汇聚到Verifier，确认问题交给Fixer修复。测试套件执行外部检查，若测试通过则合并发布，显示“Tests pass - the review ships. A team, simulated.”；若测试失败则回到Fixer，形成循环。该图与上下文紧密相关，直观呈现了自动代码审查的模拟团队工作流程。

这张图对应文档中Agent编排与Graph工程的相关内容，展示了三种Agent编排模式，分别为Prompt chain、Parallelization routing、LLM call router。第一种Prompt chain中，输入经依次传递LLM Call 1、Gate，Gate通过则依次经过LLM Call 2、LLM Call 3得到输出，不通过则直接退出；第二种Parallelization routing中，输入会并行发送给多个LLM Call，经聚合器组合输出后得到结果；第三种LLM call router中，输入经路由选择，将请求分配给一个或多个LLM Call处理，再路由到输出。图中用不同图形标识各组件，用箭头标注数据流向与条件流向，直观呈现了三种编排模式的流程。

图片展示了Graph执行和控制流程。上方是执行图，从触发器开始，依次经历工作、检查、输出环节；下方是控制图，从指标开始，经审计、权威性、人类否决，最终回到触发器。二者以虚线连接，共同围绕“REALITY ANCHOR”（现实锚点）。该图与文档中关于Graph工程的最佳实践和建议相关，直观呈现了Graph运行与控制的逻辑关系，帮助理解真实、重复任务的验证、状态明确、指标查看等步骤。

图片为Pi与Claude Code对比图，以表格形式呈现。对比内容包括设计哲学、默认工具数、系统提示词、权限系统、增加功能方式、会话存储格式、回退是否还原代码、长期记忆/用户画像、Agent loop等。如Pi设计极简内核，缺什么再加，而Claude Code开箱即用，常用能力默认内置；Pi默认工具数为4个，Claude Code有十几个常用工具及30+内置工具；Pi系统提示词约20行，较短，Claude Code较长，包含大量行为规则等。该图直观呈现了两者的差异，与上下文对比分析Pi与Claude Code的内容相契合。

图片展示了coding-agent及其依赖的四个核心组件。其中，coding-agent为产品本体/命令入口pi，agent是agent loop/session，ai是LLM抽象/多provider，tui是通用终端UI组件库。箭头表示依赖方向，自上而下，如coding-agent依赖agent，agent依赖ai，ai和tui是“叶子”组件，不依赖其他包。图片与上下文紧密相关，直观呈现了文档中提到的四个库的结构及依赖关系。

图片展示了PI架构全局数据流图，说明一条消息从输入到回复的旅程。用户发出指令，通过单一入口pi命令解析配置，建立session。Agent Loop中，Content、Compaction、pi - ai、Provider依次循环，最终输出回复。图中还呈现了TUI、Session、Agent Loop等关键组件，以及与外部LLM、外部服务的交互关系。该图与上下文紧密相关，直观呈现了文档中对PI架构架构总览的描述内容。

图片展示了Agentic Loop流程图。首先接收输入，包括用户Prompt、System Prompt、工具定义及对话历史。接着进行模型推理，Claude分析上下文生成回复，回复包含文本和工具调用请求（可选）。随后判断是否调用工具，若否则返回最终结果；若是则执行工具，Harness执行工具并收集结果（仅限检查→执行→返回结果），最后将工具结果追加到对话历史。该图与文档中介绍的Agent Loop流程内容相契合，直观呈现了其工作步骤。

图片展示了PI-Agent中Sessions的架构相关内容。左侧是example.jsonl文件，以append-only方式存储，包含header行及多条JSON行，如A、B、C、D、E节点，其中E的parentid指向B，不指向D。右侧是重建的树结构，显示了从当前节点到根的链，箭头指向E，标注current position = E，下方文字说明Context sent to LLM = A → B → E（只取当前节点到root的链）。该图与上下文解释了树和链在文件存储与模型输入形态上的区别。

图片展示了PI-Agent中发生压缩后对话树的变化。左侧是session.jsonl文件，包含多条记录。中间部分是重建的对话树，保留原文的节点用蓝色框标注，压缩节点用黄色框标注，关键节点K被突出显示。右侧是上下文发送给LLM（在buildSessionContext后）的流程，包含Summary、C、D、E等节点。底部文字强调核心：回退换起点、压缩换中段，但文件永远只增不改，还说明了回退换起点和压缩换中段的具体操作。

这张图是Pi Compaction（压缩）策略全流程图，完整呈现了该策略从触发到最终处理的全流程。图中清晰标注了四个核心环节：①何时触发，以每轮结束后下次prompt检测为节点，区分上下文溢出重试与预防性接近阈值两种情况，还标注了触发的判定依据参数；②压哪段留哪段，明确基于最大token保留数量选择切点，区分较早历史内容与最近要保留的内容；③怎么压，展示了输入内容的处理方式及压缩LLM的环节，还列出了摘要卡片的核心组成要素；④接回session，呈现了最终将压缩后的结果接入session tree的逻辑，以及最终输出的上下文的构成。

图片展示了Pi Agent的扩展系统架构及事件系统流程。扩展系统包括Tool Extension、Provider Extension、Renderer Extension、UI Control Extension等，通过事件订阅、注册能力等方式扩展Pi的行为。事件系统中，Agent Loop在运行过程中持续广播事件，如agent_start、message_start等，事件通过事件总线（event-bus）发布、订阅，实现错误隔离。事件系统内核负责广播事件，基础hooks一切能力通过扩展接入且无需修改内核，体现了高内聚、低耦合、强可扩展的特点。

图片展示了信用卡欺诈检测的同步实时链路流程。交易事件进入后，经网关Gateway认证、归一化等处理，再通过分级路由Router，白名单/低风险直接秒级放行，灰名单/可疑进入Orchestrator主Agent，有Think、Act、Observe循环，根据评分结果决定放行、告知OTP、拒绝、转人工等操作。还有异步事后链路，如反馈/沉淀层更新账户画像、欺诈模式库等。该图与上下文紧密相关，直观呈现了信用卡欺诈检测的实时与事后处理流程。

图片展示了Agent外部工具调用失败处理生命周期流程。流程从工具调用失败开始，先读取结构化错误并分类，确定性错误直接修正或终止，瞬时故障先受控重试，持续失败后再熔断和降级。若为确定性错误，修正参数或重新授权；若为瞬时故障，设置临时与总重试，随机抖动重试，达到失败阈值后打开熔断器，切换备用工具或使用缓存/返回部分结果。若存在安全错误，降级执行并说明能力边界；否则保存状态并明确失败。

图片展示了Agent模型服务故障处理流程。流程从模型调用开始，先判断模型服务是否正常响应，若否则根据错误类型（短暂时延、429、5xx等）及时间、Token、费用预算等限制重试，或切换主模型或备用模型。若主模型未恢复，需验证备用模型能力是否满足当前任务，满足则继续执行，部分满足降级为只读、生成草稿或人工审批，不满足则保存状态、转人工或停止自动执行。若模型服务正常响应，验证业务结果，再判断输出质量是否达到要求，不满足则记录错误并触发派单告警，满足则继续执行任务。

图片展示了DeepSeek Harness的Web UI界面。左侧有“工作台”“我的对话”等选项，右侧上方有“新对话”按钮，中间是“探索未至之境”标题及“DeepSeek发送消息”输入框，底部有“+”图标。该图与上下文紧密相关，直观呈现了DeepSeek Harness以Web UI为主要交互形式的特点，与文档中介绍其当前把Web UI作为主要入口，用户可在浏览器里与Agent对话等内容相呼应，体现了其使用门槛低、任务执行过程直观的优势。

这张图对应DeepSeek Harness的整体架构，其核心是以Cordis Runtime/Shared Context为支撑的Agent系统。架构分为四大模块：左侧是Gateway/Entry Adapters，负责接收用户（Phume / App）的请求，支持Web、ACP、SDK、CLI等接入方式；中间是主Agent Loop，遵循ReAct范式，包含LLM、工具调用、提示组装等流程，还存在可替换的组件；另有子Agent Loop作为辅助，以及Session Event Log模块，用于记录会话的各类事件、消息等数据。右侧是Output Adapters，将系统的最终响应适配为User Client支持的WebScket、Web、ACP、SDK等格式。

图片展示了Cordis插件运行时与DSH插件化原理流程图。从Profile/cordis.patch.yml等配置文件开始，经Cordis Loader读取模块，到Registry为每个插件实例创建Fiber，再到Fiber状态流转，最后各组件能力组成完整DSH。还呈现了HMR动态更新流程，包括代码或配置变化、HMR检测、定受影响插件、Fiber进入Unloading、ctx.affect等步骤。该图与上下文紧密相关，直观呈现了DSH与Cordis插件运行及DSH插件化原理。

图片展示了DeepSeek R1训练方法流程。从DeepSeek v3 base模型出发，通过向DeepSeek - R1 - Zero提问并人工精修，生成数千条思维链监督数据集，再进行有监督微调。接着，使用GRPO强化学习，结合准确性与语言一致性奖励，得到监督微调 + 强化学习后的模型。之后，通过拒绝采样得到拒绝采样DeepSeek v3，整合80万SFT数据，进行有监督微调。最后，通过奖励信号和多样化全场景强化学习，得到DeepSeek R1模型。

这张图片展示了常见大模型推理框架的相关信息，表格包含框架名称、核心特点、量化支持、硬件支持、适用场景五项内容。其中重点突出了各框架的核心特性：vLLM具备高效PagedAttention、动态批处理的特点；Llama.cpp是超轻量的CPU高效运行框架，其量化支持勾选了4-bit和8-bit；FasterTransformer、DeepSpeed-Inference、ONNX Runtime均支持INT8量化，适配不同硬件与不同规模的LLM推理场景，涵盖云端高并发API服务、本地边缘部署、企业级GPU推理加速、超大模型分布式云服务等多种应用场景。

这张图是大模型前后端生命周期的核心示意图，主题为“大模型服务：从程序、镜像、实例到分布式运行”，用于展示Agent系统的完整运行流程，内容围绕两条主线展开。图中清晰呈现了程序从开发到镜像、实例再到服务的部署流程，还有分布式大模型后端系统的架构，包含API网关、多台后端服务实例、Kubernetes调度器等核心组件，还标注了各部分的作用，如Docker打包程序、Kubernetes调度实例到对应服务器、Redis提供缓存等，是理解大模型前后端生命周期的核心内容，对应文档中提及的Agent系统压力测试相关的架构知识讲解。

图片展示了Prompt Engineering、Context Engineering、Harness Engineering三个阶段的演进脉络。2023 - 2024年是Prompt Engineering阶段，研究如何组织Prompt让模型理解真实意图，类比为导演调一句话；2025年是Context Engineering阶段，研究在合适时机放合适内容进模型Context，类比为图书管理员管一窗信息；2026年是Harness Engineering阶段，围绕大模型搭建完整可靠Agent，类比为架构师搭一套系统。三者是叠加关系，Harness内部需Context，每次Prompt需Prompt。

图片展示了不同检索工具的优缺点及何时启用（具体阈值）。包括grep、BM25倒排索引、Semantic Search（embedding）、Agentic RAG（推荐）、结构化数据库/索引等。如grep优点为久经考验、快、关键词精准，缺点是文件多了线性扫描会变慢，启用条件是代码库<5GB或文件数<10w时不用换。BM25倒排索引优点是索引化、查询很快，缺点是仍是词法匹配，无法处理同义，启用条件是代码库>5GB或文件数>10w；grep一次搜索>5s时。该图与上下文介绍检索工具从“词法”到“语义”的谱系相关，辅助说明检索工具的选择与应用。

图片展示了Claude代码重置指令“/rewind”的使用示例。在代码编辑界面输入“/rewind”后，系统提示“Restore the code and/or conversation to a previous point”，并显示了“Crumpet”标识。该图片与文档中“Harness思想的运用”部分内容相关，是对“/rewind”指令功能的直观呈现，帮助理解该指令可将代码和对话恢复到先前状态，与文档中关于Harness思想在代码重置方面的应用介绍相呼应。

图片展示了Anthropic Harness架构，包含App Spec/PRD、Initializer Agent、Coding Loop Agent、External Memory System、Sandbox/Isolated Execution等组件。其中，Initializer Agent根据App Spec/PRD和项目蓝图生成项目蓝图；Coding Loop Agent按迭代更新状态、实现功能、验证检查；External Memory System存储持久化外部状态；Sandbox/Isolated Execution为受控执行环境。该架构是一个持续运行的软件工厂，由规划、外部记忆、验证和短生命周期的代理循环构成。

图片展示了SKILL目录结构示例。其中，SKILL.md是必选的主要技能文件；scripts文件夹下有可执行代码，如process_data.py和validate.sh；references文件夹下有文档，如api-guide.md和examples/；assets文件夹下有模板等，如report-template.md。该图与上文介绍SKILL目录结构的内容相呼应，直观呈现了SKILL包含的文件及类型。

图片展示了一个新客户上板流程的工作流示例。流程包含4个步骤：Step 1创建账户，调用create_customer工具，参数为name、email、company；Step 2设置支付，调用setup_payment_method工具，等待支付方法验证；Step 3创建订阅，调用create_subscription工具，参数为plan_id、customer_id（从Step 1获取）；Step 4发送欢迎邮件，调用send_email工具，模板为welcome_email_template。此图与文档中介绍的多MCP协作等技能要点相关，直观呈现了多MCP协作时任务流中各步骤的调用情况。

图片展示了MCP（Material Change Process）的四个阶段。Phase 1为设计导出（Figma MCP），包括从Figma导出设计资产、生成设计规范、创建资产清单；Phase 2为资产存储（Drive MCP），有在Drive创建项目文件夹、上传所有资产、生成可分享链接；Phase 3为任务创建（Linear MCP），需创建开发任务、将资产链接附到任务、分配给工程团队；Phase 4为通知（Slack MCP），在#engineering发布交接总结，包含资产链接和任务参考。此图与文档中介绍MCP流程的内容紧密相关。

图片展示了迭代报告创建流程。初始草稿包括通过MCP获取数据、生成初稿报告并保存至临时文件；质量检查运行验证脚本、识别问题如缺失部分、格式不一致等；精炼循环解决每个识别问题、重新生成受影响部分、重新验证，直至质量阈值达标；最后应用最终格式、生成总结、保存最终版本。该流程与文档中迭代优化部分上下文对应，说明在迭代提升输出质量时的清晰质量标准、迭代提升、验证脚本及何时停止迭代等内容。

图片展示了智能文件存储的决策树流程。首先检查文件类型和大小，接着确定最佳存储位置，如大型文件（>10MB）使用云存储MCP，协作文档使用Notion/Docs MCP，代码文件使用GitHub MCP，临时文件使用本地存储。执行存储时，根据决策调用相应MCP工具，应用服务特定元数据，生成访问链接。最后向用户提供上下文，解释为何选择了该存储方式。此图与文档中智能文件存储技能相关，直观呈现了操作步骤。

这张图片展示的是带合规要求的支付处理流程，内容分为三大部分：处理前的合规检查、正式支付处理、审计轨迹记录。处理前的合规检查步骤包含通过MCP获取交易详情、应用合规规则（核查制裁名单、验证管辖权限、评估风险等级）、记录合规判定结果；正式处理环节依据合规是否通过，分别执行调用支付处理MCP工具等交易流程，或标记待审核、创建合规案例操作；审计轨迹部分则要求记录所有合规核查、处理决策，生成审计报告，符合文档中“领域专业智能Skill”需嵌入专业知识、保障合规的核心要点。

图片展示了Agent Skills和MCP两种技能的对比。Agent Skills侧重提示词、带目录的说明书，Token消耗低，核心主体是Markdown文件，编写难度低；MCP侧重工具调用、标准化工具箱，Token消耗高，核心主体是软件包，编写难度高。该图与上下文介绍的SKILL运行模式相关，直观呈现了两种技能在侧重点、Token消耗、核心主体及编写难度等方面的差异。

图片展示了Claude Code的技能使用流程。用户提出“结合材料写作”的需求，Claude Code在可用技能中选择“帮我写作”，并给出技能指令，包括结合材料撰写深度文案等内容。接着，Claude Code按需加载资源层，读取范文内容，最终给出回答。该图与上下文紧密相关，直观呈现了文档中介绍的AI选择技能、指令层按需加载、资源层按需加载及生成最终回答的流程。

这张图片展示了Claude工具中Pro与Max两个版本的订阅服务信息，Pro版本每月费用为17美元（按年计费），其包含超出免费版的使用额度、更多Claude模型访问权限、无限项目、解锁深度研究工具等多项权益，还涵盖Claude Code功能。Max版本每月费用从100美元起（按月计费），属于Pro版本的升级选项，拥有最高5倍或20倍于Pro的使用额度、所有任务的更高输出限制、高级Claude功能抢先体验、高峰时段优先访问权限，同样包含Claude Code。图片呈现的内容与Claude Code从入门到精通相关内容里的版本费用、权益信息相呼应，直观展示了两个版本的差异。

这张图是Claude Code Agent的全局工作流架构图，从上到下清晰展示了完整工作流程。流程共分为五个核心阶段，其中第四阶段Agentic Loop（核心循环）被红色虚线框重点标注，该阶段包含四个子步骤，依次为上下文治理（裁剪/压缩）、调用模型、判定是否需要调用工具（是则继续、否则退出循环）、执行工具（返回结果后回到第一步），标注了退出条件的三种情况。图中还明确各阶段对应关注的重点，分别是用量统计、Hook钩子、消息与通知，各阶段的箭头流向体现了工作流的递进逻辑。

图片展示了ClaudeCode的Agentic Loop整体架构。首先接收输入，包括用户Prompt、System Prompt、工具定义、对话历史等。接着进行模型推理，Claude分析上下文生成回复，回复包含文本和工具调用请求（可选）。若调用工具，Harness执行工具，收集结果；若不调用工具，则直接返回最终结果。最后将工具结果追加到对话历史，形成循环流程。该图与文档中介绍的生产环境ReAct设置成循环流程的内容相呼应，直观呈现了流程步骤。

图片展示了Claude Code的上下文持久化体系，分为四类Memory和Transcript。Memory包括CLAUDE.md族人写的长期规则、对话上下文、Session Memory及Memdir持久记忆，分别以文档、对话记录、笔记和数据库形式存储；Transcript为完整会话流水账，以.jsonl形式存储，包含user/assistant messages、tool_use/tool_result等。该图与上下文紧密相关，是对上下文中Claude Code记忆功能部分的详细说明，帮助理解其运作体系。

图片展示了AI Coding Assistant的记忆系统架构。上方有四层记忆，分别为指令文件、会话上下文、会话记忆和持久化记忆。指令文件包含代码、文档等；会话上下文记录用户消息等；会话记忆记录会话内容；持久化记忆存储用户、反馈和项目信息。下方有压缩功能，包括总预算、多连接、自动压缩、块、反应式等。最下方是写入功能，有提取记忆、会话更新和AutoDream等。该图与上下文紧密相关，是对文档中ClaudeCode记忆功能的详细说明。

图片展示了ClaudeCode指令文件的五层记忆体系。从上至下依次为：企业级的/etc/claude-code/CLAUDE.md（全组织统一规范，由管理员设置）；用户级的~/.claude/CLAUDE.md（开发者个人偏好）；项目级的./CLAUDE.md（团队共享项目约定）；规则级的./claude/rules/*.md（模块化细粒度规则）；本地级的./claude.local.md（不提交到Git的私人笔记）。该图与文档中介绍Claude.md系列文件维护需人工维护，且采用五层记忆体系的内容相呼应。

图片展示了Claude Code四级上下文压缩策略，从成本递增、上下文压力递增方向展开。分为Snip裁剪、MicroCompact、Collapse和AutoCompact四级，每级有触发条件、同步异步执行方式、触发方式等说明。如Snip裁剪无LLM，标记痕迹工具结果，成本为0，同步执行等。AutoCompact是最终裁剪，触发后同步完成压缩，无并发断链保护。该图与上文介绍的Claude Code记忆功能内容相关，直观呈现了各层级压缩策略。

图片展示了Claude Code与Openclaw的压缩策略对比。Claude Code采用2级梯度策略，当Token count > 167K时，先进行轻量级会话内存压缩，若不足则进行全LLM压缩，需LLM调用，可恢复5文件。Openclaw采用1级精细策略，先预刷内存，将旧消息分块，每块总结，再合并，最终得到合并总结和近20K token的原始内容。图片直观呈现了两者在压缩策略上的差异，与上下文对核心差异的说明相呼应。

图片展示了AutoDream记忆整合流程。上方有三个触发条件，分别是距上次整合≥24小时、≥5个会话、获取consolidation lock。下方是执行的4个阶段：Orient（读取MEMORY.md索引、浏览主题文件）、Gather（扫描日志、会话JSONL，缩小grep范围）、Consolidate（将新信息合并到主题文件、修正矛盾、相对日期）、Prune（保留MEMORY.md < 200行、移除过时条目、修剪冗余描述）。底部有“read-only code access, write-only to memory directory”及“dreaming”字样。

图片是一张表格，对比了extractMemories、Session Memory和AutoDream三者在维度、一句话定位、写入目标、生命周期、操作性质、触发时机、频率、信息来源、写什么、下游用途、权限范围、执行方式、类比等方面的差异。如extractMemories从对话中提取记忆写入持久存储，Session Memory维护会话临时日志，AutoDream定期整理持久记忆；写入目标分别为特定文件及索引、单个笔记文件、特定文件及索引；生命周期分别为永久、仅当前会话、永久；操作性质分别为新增/更新、维护/覆盖、合并/去重/删除/精简等。该表与上下文对比三者功能，辅助理解。

图片展示了Sub-Agents与Agent Teams两种架构模式。左侧为Sub-Agents，以一个标签页呈现，包含Main Agent和三个Worker，Main Agent与Worker间有“results”箭头，Worker仅向Main Agent报告结果，强调“Report to boss only”。右侧是Agent Teams，有多个标签页，包含Main Agent、Frontend、Backend和Verifier，各组件间有“Share tasks, discuss, coordinate”箭头，体现“discuss + coordinate”。该图与文档中Agent架构内容相关，对比说明了两种架构在协作方式上的差异。

图片展示了ClaudeCode规则有6个配置层级及其说明和典型场景。层级从上至下依次为policySettings（管理员/企业策略）、userSettings（用户全局设置）、projectSettings（项目级设置）、localSettings（本地设置）、cliArg（命令行参数）、session（会话级）。如policySettings用于公司统一策略，userSettings是个人习惯设置，projectSettings是项目约定等。该图与上文规则优先级从高到低的介绍相呼应，直观呈现各层级配置内容及适用场景。

这张图片是Claude Code的模式说明表格，明确列出了各类模式的相关信息，对应文档中Claude Code权限系统与安全审查的内容。表格分为模式、类型、行为、说明四列，其中default、acceptEdits、plan、bypassPermissions、dontAsk属于用户可设置模式，auto、bubble属于内部模式。表格标注了acceptEdits与plan的行为特殊之处，acceptEdits的项目内编辑在第二层就放行，plan的写操作在第二层就拒绝，均不符合常规第三层模式兜底的逻辑，该内容正好补充了文档中关于这两种模式特殊规则的描述。

图片展示了ClaudeCode在异常场景下的处理方式及设计原则。当分类器API不可用时，采用Iron Gate机制，退回用户手动确认，设计原则为Fail Closed，宁可中断也不放过；连续多次拒绝时，自动降级为用户确认模式，防止分类器误判阻塞工作流；对话记录超出上下文时，交互模式退回手动确认，无人值守模式直接终止，确定性错误不重试。此图与上文介绍的分类器容错与降级机制内容相呼应，直观呈现了相关处理方式和设计原则。

图片展示了Claude Code等大模型一次请求的计费流程。一次请求分为输入和输出两部分，输入有缓存命中、未命中且不存入缓存、未命中但要存入缓存三种情况，分别对应缓存读取、基础输入、缓存写入，单价分别为0.1x、1x、1.25x。输出为模型生成回复，单价5x。总账单等于输入（三条之和）加上输出。此图与上下文紧密相关，直观呈现了大模型计费的复杂情况。

图片为各类Token单价（相对基础输入的倍率）柱状图，展示了缓存读取、基础输入、缓存写入5m、缓存写入1h、输出五类Token的倍率。其中，缓存读取倍率为0.1，基础输入为1，缓存写入5m为1.2，缓存写入1h为2，输出高达5。该图与文档中介绍Claude API将token分成5种、单价各不相同的内容相关，直观呈现了不同Token的倍率情况。

图片为“Opus 4.5各类Token实际单价（美元/百万token）”柱状图，展示了Opus 4.5模型中不同Token类型的价格。其中，缓存读取价格最低，为0.50美元/百万token；基础输入价格为5.00美元/百万token；缓存写入5m价格为6.25美元/百万token；缓存写入1h价格为10.00美元/百万token；输出价格最高，为25.00美元/百万token。该图与上下文紧密相关，直观呈现了大模型同一模型内各类Token的实际单价差距。

图片展示了Claude Code缓存机制的前缀匹配过程。第1轮全新开始，无缓存，全部请求处理并写入；第2轮没变前缀读缓存，新增部分写入；第3轮越往后，便宜的读取占比越高；第4轮系统提示修改，前缀失效，全部退回缓存写入。图片与上下文紧密相关，直观呈现了每轮缓存读写情况，帮助理解缓存机制如何根据前缀匹配节省Token。

这是一张显示在树背景前的代码工具用量报表界面，标题为“Coding Agent Usage Report - Daily”，记录了不同日期各AI代码智能体的使用数据，涵盖A.I.P、Claude、Codex、OpenCode、pi-agent等代理。表格列含日期、Agent、使用模型、Input输入量、Output输出量、Cache Create、Cache Read、总Token数量、美元成本等项目，还设有Total合计行汇总相关数据，该报表能直观展示Claude Code类代码工具的Token使用情况，可用于诊断Token浪费问题，是相关最佳实践里的诊断工具，帮助用户掌握各模型的资源消耗详情。

图片为AI工具对比表，分为工具、类型、上下文三列。工具包括Rork、Cursor、Windsurf、Bolt、Lovable、v0（Vercel）、Claude Code、OpenAI Codex、VibeCode（方法论）等。类型方面，如Rork是移动端应用生成平台，Cursor是AI IDE等。上下文部分，如Rork以单次需求/页面为主，对复杂跨模块长期上下文较弱等。该表与上下文内容紧密相关，直观呈现了不同AI工具的特点与适用场景。

图片为AI工具对比表，展示2/2篇，涵盖功能覆盖、适用人群、典型优劣。工具包括Bark、Cursor、Mindsurf、Bolt、Lovable、v0（Vercel）、Claude Code、OpenAI Codex、Vibe Code（方法论）。如Bark适用于独立开发者，可导出代码继续开发，典型优劣为仅、移动端、WIP 稍低、劣、深度自定义与工程化调试能力有限；Lovable适用于前端/后端/数据库/认知（聚焦集成）等，典型优劣为仅、门槛低、交付快、劣、复杂业务场景能力有限等。

这是Transformer的架构图，图中清晰展示了模型的核心结构，其每个子层后都标注了“Add & Norm”，这一内容与上下文提到的Transformer架构中残差连接的体现相呼应。图的左侧为编码器部分，输入经Input Embedding和Positional Encoding后，经过Nx重复的“Multi-Head Attention”“Add & Norm”“Feed Forward”“Add & Norm”结构；右侧为解码器部分，输出经Output Embedding和Positional Encoding后，经过Nx重复的“Masked Multi-Head Attention”“Add & Norm”“Multi-Head Attention”“Add & Norm”“Feed Forward”“Add & Norm”结构，最终经Linear和Softmax得到Output Probabilities。图中标注的“Add & Norm”正是上下文所提的残差连接的体现。

图片展示了时间维度和深度维度的对比。时间维度中，RNN通过顺序累积处理Token，Transformer则通过全位置注意力处理；深度维度中，传统残差通过层叠加法处理，注意力残差通过全层注意力处理。图片右侧箭头标注“Rotate 90°: Same Principle, Different Axis”，表明注意力机制的旋转90度概念，即将时间上的处理作为横轴，引入类似注意力机制的能力，与上下文提到的LSTM和注意力机制旋转90度的思路相呼应。

图片是大模型算法工程师学习路线图，分为三个阶段。阶段1是PyTorch入门基础，12节课，4次考试，涵盖变量、自动求导、序列模型等10个主题。阶段2是后训练理论深化，11节课，3次考试，涵盖MDP与强化学习基础等6个主题。阶段3是开源项目研读，14节课，3次考试，涵盖TBL库、Open - R1等6个主题。该图与文档中大模型算法学习路线内容相关，直观呈现学习路径。

图片为PyTorch入门课程大纲，共16课（含4次考试），分4个阶段。第一阶段基础（Lesson 1 - 4 + Exam 1）包含4课，分别介绍Tensor张量入门、自动求导Autograd、nn.Module搭建神经网络、训练循环Training Loop等内容，每课有具体学习目标和练习任务，如创建张量、使用autograd手动实现线性回归、搭建两层全连接网络识别数字等。

图片展示了不同岗位类型在刷题、项目、论文方面的推荐优先级及理想组合方式。校招/初级算法岗推荐刷题优先，理想组合为高频题+1~2个基础项目+通用模型论文理解；微调/数据工程岗推荐项目优先，理想组合为数据管线实践+微调流程+LoRA论文阅读；推理部署工程岗推荐项目优先，理想组合为服务封装经验+推理延迟优化+部署框架掌握；高级算法/研究岗推荐论文优先，理想组合为论文主导答辩+系统级项目经验+基础刷题稳定；Agent/RAG方向开发岗推荐项目优先，理想组合为LangChain项目实践+RAG结构论文+优化讲解。

图片展示的是一个API请求示例，用于模型分析用户问题并决定是否调用工具。请求发送至POST /v1/chat/completions，包含model、messages、tools等字段。messages中包含系统角色和用户角色，用户询问周杰伦演唱会时间。tools字段中定义了一个名为“ConcertSearchPlugin - search_concert”的工具，用于搜索特定艺人的演唱会信息，参数为艺人姓名。该图片与文档中模型分析用户问题，决定是否调用工具的上下文对应，直观呈现了请求结构。

图片展示的是字节跳动面试中大模型应用/算法相关问题的回答JSON格式。其中，“choices”数组下包含一个对象，其“tool_calls”字段内有唯一ID“call_897f1b”，类型为“function”，函数名为“ConcertSearchPlugin - search_concert”，参数为“{“artist_name” : “周杰伦”}”。该图片与文档中一面面试时大模型调用本地函数处理本地执行内容相关，直观呈现了大模型调用本地函数的JSON结构。

图片展示的是一个API请求示例，用于调用模型处理用户问题。请求发送至“/v1/chat/completions”端点，模型为“qwen2.5-local”。消息部分包含用户问题“周杰伦的演唱会是什么时候？”及模型上一轮请求“call_897f1b”的相关信息，还包含工具实际运行结果，显示周杰伦“嘉年华”世界巡回演唱会海口站时间为2025年3月2日。此图与文档中SK构造请求包含完整历史上下文的内容相关，直观呈现了请求结构。

图片展示的是一个HTTP 200 OK的JSON响应，包含“choices”数组，其中包含一个对象。对象中“index”为0，“message”包含“role”为“assistant”、“content”为“周杰伦的《嘉年华》世界巡回演唱会海口站将在2025年3月2日举行。”、“tool_calls”为null，“finish_reason”为“stop”。该图片与文档中字节跳动一面面试的流程相关，是模型结合工具返回的事实生成最终回答的示例。

图片展示了大前端领域AI编码智能体岗位的工作职责和任职资格。工作职责包括主导AI编码智能体核心功能、创新应用大语言模型和Agent技术、构建Agent执行与规划框架、将AI能力产品化等。任职资格要求计算机相关专业、精通主流大前端框架、对AI前端有浓厚兴趣、至少熟悉一种AI Coding工具或工作流、具备技术好奇心与自驱力、有Agent框架/工具链设计经验等。该图片与文档中岗位介绍部分内容对应，直观呈现岗位要求。

这张图片展示了常见的大模型获取工具的三种方式，分别为全量塞入、人为规则过滤、AI语义检索，每种方式对应了明确的做法、决定工具的主体、适用场景，以及对应的产品或行业实践。其中全量塞入的适用场景为工具总数≤10-20个，相关产品包括ChatGPT Plugins、GitHub Copilot Agent；人为规则过滤需开发者按业务阶段或意图分组手动挑选工具，适用于工具总数超20个或模型能力有限的情况；AI语义检索通过embedding做相似匹配自动召回相关工具，多用于工具总数达数百至数千的场景，相关实践有ToolLLM、Gorilla Function Relevance Detection等。

这张图展示了LangGraph相关的核心概念，以分层结构与对应解释的形式呈现。最上方为图结构，标注状态初始为“?“，经两个节点流转后，关联“我想要langgraph”的状态，是节点与边的控制流；下方分为Super-steps、Checkpoints、Thread、StateSnapshot四个板块，分别对应子节点共享同一步骤、每步打包状态与元数据、检查点集合、检查点类型的说明，清晰呈现了LangGraph的持久化记忆核心逻辑，与上下文提到的LangGraph持久化记忆的内容直接对应，帮助理解该技术的关键运行机制。