大语言模型概念速览¶
大语言模型不仅是一个聊天框。围绕模型,还有分词器、上下文、检索、工具、Agent运行循环、安全边界和评测系统。很多新名词描述的其实是不同层次:有些属于模型内部,有些属于训练方法,有些只是模型之外的工程系统。
可以先用下面这条链路建立整体认识:
---
config:
block:
padding: 14
---
block
columns 3
A("训练数据") space B("Token序列")
space:3
space:3
D("Instruction Model") space C("Base Model")
space:3
space:3
E("LLM应用 / Agent") space F("可实际完成任务的AI系统")
A -- "Tokenizer" --> B
B -- "预训练" --> C
C -- "指令微调与<br/>偏好对齐" --> D
D -- "Prompt + Context + Tools" --> E
E -- "Harness负责运行、权限、<br/>状态与评测" --> F
先区分三个层次
模型负责根据输入预测输出,Agent让模型在循环中选择工具和下一步行动,Harness负责把模型、上下文、工具、权限、状态和运行环境组织起来。模型能力很重要,但最终系统的可靠性并不只由模型决定。
1 LLM¶
LLM是Large Language Model,即大语言模型。它通过大规模文本和代码学习语言中的统计规律,并根据已有Token预测后续Token。
从数学上看,模型每一步输出的不是一句完整答案,而是“下一个Token可能是什么”的概率分布。生成一个Token后,模型把它加入已有序列,再预测下一个,直到遇到停止标记或达到长度限制。
这种机制能够产生连贯文本、代码和推理过程,但也意味着模型首先在学习“什么文本最可能接在后面”,而不是直接查询一个绝对可靠的事实数据库。
1.1 Base Model与Instruction Model¶
| 类型 | 说明 |
|---|---|
| Base Model | 只经过大规模预训练,擅长文本续写,但未必会稳定遵循用户指令 |
| Instruction Model | 在Base Model基础上进行指令微调和偏好对齐,更适合问答、聊天和工具调用 |
| Reasoning Model | 在训练或推理阶段强化多步问题求解,通常会投入更多计算和生成Token完成复杂任务 |
模型名称中的Base、Instruct、Chat通常反映这种区别,但各厂商的具体命名并不完全一致。
1.2 Foundation Model¶
Foundation Model,即基础模型,是能够适配多种下游任务的大规模预训练模型。LLM属于基础模型的一类;能同时处理文本、图像、音频或视频的模型通常称为多模态模型。
多模态模型并不是简单地把图片“转成一句话”。常见做法是先用对应的编码器将图像、音频等内容转换为模型能够处理的表示,再与文本Token一起参与计算。
2 Token与Tokenizer¶
Token是模型处理信息的基本单位。它可能是一个汉字、一个单词、单词的一部分、标点、空格或者代码片段。
Tokenizer是分词器,负责在文本和Token ID之间转换。常见算法包括BPE、WordPiece和SentencePiece。子词分词能够用有限词表组合出大量词语,也能处理生僻词和新词。2
Token不等于字数
同一句话在不同模型中可能得到不同Token数量。中文字符有时接近一个Token,有时会被拆分;英文常见词可能是一个Token,生僻词可能被拆成多个Token。空格、换行和标点同样会占用Token。
Token数量会直接影响:
- 能放入上下文的信息量;
- API调用费用;
- 推理延迟和显存占用;
- 模型能够生成的最大长度。
2.1 Vocabulary¶
Vocabulary即词表,是Tokenizer能够直接识别的Token集合。词表越大,常见文本可能需要的Token越少,但模型的输入输出层也会更大。不同Tokenizer之间的Token ID没有通用对应关系。
2.2 Special Token¶
Special Token用于表示文本之外的控制信息,例如:
真实名称由模型的Chat Template决定,不能随意假设所有模型都使用相同格式。
3 Parameter、Weight与Checkpoint¶
Parameter即参数,是模型训练中学习到的数值;Weight通常泛指其中的权重矩阵。参数数量常用B表示十亿,例如7B约为70亿参数。
参数更多通常意味着更大的容量,但不保证模型一定更好。训练数据质量、数据量、训练计算、模型结构和后训练方法同样重要。计算最优训练研究也表明,模型大小和训练Token数量需要合理匹配,单纯增大参数但不给足训练数据并不经济。34
Checkpoint是某一训练阶段保存的模型状态,通常包含权重,有时还包括优化器状态和训练进度。日常所说的“下载模型”,多数是在下载一个可用于推理的权重Checkpoint及其配置、Tokenizer等文件。
Note
参数不是可以逐条查询的知识库。知识以分布式方式编码在大量权重中,因此很难像修改数据库记录一样精确添加、删除某个事实。
4 Transformer与Attention¶
Transformer是现代LLM最常见的基础架构。它用Attention机制建模序列中不同Token之间的关系,并能高效并行训练。1
4.1 Self-Attention¶
Self-Attention让每个Token根据当前任务关注序列中的其他Token。简化来看,每个Token会生成Query、Key和Value:
Query与Key计算相关性,再对Value加权汇总。多个Attention Head可以学习不同类型的关系,例如语法、指代、位置或代码依赖。
4.2 Causal Attention¶
多数生成式LLM使用Causal Attention。生成当前位置的Token时,只能关注它之前的Token,不能偷看未来内容。这与“逐个预测下一个Token”的训练目标一致。
4.3 Embedding¶
Embedding是向量表示。模型首先将Token ID映射为高维向量,使语义或用法相近的内容在向量空间中呈现一定结构。
Embedding也可以由专门的嵌入模型生成,用于语义搜索、文本聚类、去重和RAG。用于检索的Embedding模型与负责生成答案的LLM可以是两个独立模型。
4.4 Position Encoding¶
Attention本身不知道Token顺序,因此模型还需要位置编码。常见方案包括绝对位置编码、相对位置编码和RoPE。位置编码方案会影响模型处理长文本的方式,但标称上下文越长并不等于模型在任意长文本上都能同样准确地利用信息。
4.5 Dense Model与MoE¶
Dense Model每次推理通常都会使用大部分参数。MoE,即Mixture of Experts,会通过路由器只激活部分“专家”网络,因此总参数量可以很大,但每个Token实际使用的参数较少。MoE能够提高计算效率,也会引入路由、负载均衡和跨设备通信等复杂度。15
5 Context Window¶
Context Window是单次推理中模型能够接收和处理的Token范围,通常包括:
上下文窗口是有限资源。输入太长时,系统必须截断、压缩或丢弃部分内容。
上下文窗口不等于长期记忆
模型不会因为“聊过一次”就永久记住信息。对话历史能被记住,通常是因为应用再次将其发送进上下文;跨会话记忆则需要数据库、文件或其他外部存储。
5.1 Lost in the Middle¶
信息位于上下文中,并不代表模型一定能同等利用它。长上下文中的关键信息可能被忽略,尤其当它被大量低相关内容包围时。因此,盲目把所有资料塞进Prompt,往往不如筛选少量高质量内容。
5.2 Context Engineering¶
Prompt Engineering主要关注“指令怎么写”,Context Engineering则关注“本轮推理究竟给模型哪些Token”。它包括:
- 系统指令和示例;
- 对话历史的取舍与压缩;
- RAG检索结果;
- 工具说明和工具返回值;
- 当前任务状态、计划与外部记忆。
上下文工程的目标不是填满窗口,而是用尽可能少、信号尽可能高的Token帮助模型做出正确行为。11
6 模型是怎样训练出来的¶
6.1 Pre-training¶
Pre-training即预训练。模型在大规模文本、代码和其他数据上学习预测后续Token:
通过海量类似样本,模型学习语言、事实、代码模式和部分问题求解能力。完成预训练后得到Base Model。
6.2 SFT与Instruction Tuning¶
SFT即Supervised Fine-Tuning,监督微调。训练数据通常由“指令—理想回答”组成,让Base Model学会按照人类期望的形式完成任务。
Instruction Tuning是以指令数据进行微调的常见形式。它主要教模型“如何回答”,并不等于重新训练全部知识。
6.3 Alignment¶
Alignment即对齐,让模型行为更符合人类意图、价值和安全要求。常见方法包括:
| 方法 | 说明 |
|---|---|
| RLHF | 收集人类偏好,训练奖励模型,再通过强化学习优化语言模型 |
| RLAIF | 使用AI反馈替代或辅助部分人类反馈 |
| DPO | 直接用偏好对训练模型,避免单独训练奖励模型和复杂的强化学习流程 |
InstructGPT展示了“SFT + 人类偏好 + RLHF”的经典流程。5 DPO则将偏好学习转化为更直接的优化目标。6
对齐能够改善帮助性和安全性,但不能彻底消除错误、偏见或越狱风险。
6.4 Fine-tuning、PEFT与LoRA¶
Fine-tuning是在已有模型上使用特定数据继续训练,使其适应某个领域、任务或表达风格。
完整微调需要更新大量参数,成本较高。PEFT,即Parameter-Efficient Fine-Tuning,只训练少量新增或选定参数。LoRA是常用PEFT方法,它冻结原始权重,并在部分层加入可训练的低秩矩阵。7
RAG还是Fine-tuning?
需要及时更新、可以引用来源的外部事实,通常优先使用RAG;需要改变输出风格、格式习惯或稳定的任务行为,才更适合Fine-tuning。二者也可以组合使用。
6.5 Distillation¶
Distillation即知识蒸馏,让较小的Student Model学习较大Teacher Model的输出或行为。目标是在保留尽可能多能力的同时降低推理成本,但Student Model通常仍会损失部分能力。
7 Inference与Sampling¶
Inference即推理,是训练完成后使用模型生成结果的过程。
7.1 Prompt与Message Role¶
Prompt泛指提供给模型的输入。聊天接口通常将上下文分为不同角色:
| 角色 | 作用 |
|---|---|
| System / Developer | 定义总体行为、约束和任务边界 |
| User | 用户提出的需求和补充信息 |
| Assistant | 模型此前的回答 |
| Tool | 外部工具返回的结果 |
角色优先级和具体格式由模型API与Harness决定。模型最终看到的通常仍是一串经过Chat Template组织的Token。
7.2 Zero-shot、One-shot与Few-shot¶
| 方式 | 说明 |
|---|---|
| Zero-shot | 只给任务说明,不给示例 |
| One-shot | 给一个输入输出示例 |
| Few-shot | 在上下文中给少量示例 |
Few-shot属于In-context Learning:模型权重没有改变,只是在当前上下文中模仿示例规律。
7.3 Temperature、Top-p与Top-k¶
模型会为候选Token计算概率,Sampling参数决定如何从概率分布中选择下一个Token:
| 参数 | 作用 |
|---|---|
| Temperature | 调整概率分布的平滑程度,低值更稳定,高值更多样 |
| Top-p | 只从累计概率达到阈值的一组候选Token中采样 |
| Top-k | 只保留概率最高的k个候选Token |
| Max Tokens | 限制最多生成多少Token |
| Stop | 遇到指定序列时停止生成 |
创意写作可以适当增加随机性;事实抽取、代码修改和结构化任务通常使用较低随机性。即使Temperature为0,不同硬件、并发和服务实现下也不一定绝对可复现。
7.4 Reasoning与Test-time Compute¶
一些模型会在回答前投入更多推理Token或进行搜索、自检、验证,这属于增加Test-time Compute。它常能改善复杂数学、代码和规划任务,但会增加延迟与成本。
Chain of Thought是把问题拆成中间步骤的提示与训练方法。中间推理写得很长并不保证结论正确;实际系统更应通过工具、测试和外部证据验证结果,而不是只相信“看起来合理”的推理文字。
7.5 Prefill、Decode与KV Cache¶
推理通常分为两个阶段:
| 阶段 | 说明 |
|---|---|
| Prefill | 一次处理输入上下文,生成第一个输出Token之前的计算 |
| Decode | 逐个生成后续Token |
KV Cache保存Attention层对已有Token计算出的Key和Value,生成后续Token时无需从头重复计算,因此能显著加速Decode。长上下文的KV Cache也会占用大量显存。16
常见性能指标:
- TTFT:Time to First Token,首Token延迟;
- TPS:Tokens per Second,每秒输出Token数;
- Latency:完成一次请求的总时间;
- Throughput:单位时间内处理的请求或Token总量。
8 Hallucination与Knowledge Cutoff¶
Hallucination通常译为“幻觉”,指模型生成看似合理但错误、虚构或无法由证据支持的内容。NIST使用Confabulation描述这类自信但错误的输出,以避免对模型作过度拟人化理解。14
幻觉产生的原因包括:
- 生成目标是预测合理文本,而不是强制验证事实;
- 训练数据不完整、矛盾或过时;
- Prompt含糊或前提错误;
- 上下文中缺少答案;
- 长链推理中的错误不断累积。
Knowledge Cutoff是训练数据大致截止的时间。即使模型知道某个日期,也不代表其中所有知识都准确更新到了该日期。
减少幻觉的常见方法:
- 通过RAG提供可靠资料;
- 要求回答附带可核查来源;
- 使用搜索、计算器、代码执行和数据库等工具;
- 对关键结论进行规则、测试或人工验证;
- 允许模型在证据不足时明确回答“不确定”。
9 RAG¶
RAG是Retrieval-Augmented Generation,即检索增强生成。它在模型回答前从外部知识库检索相关内容,再将结果加入上下文。8
典型流程如下:
9.1 Chunking¶
Chunking是将长文档切成较小文本块。块太大容易混入无关内容,块太小又会丢失上下文。常见策略包括固定长度、按标题切分、按段落切分和滑动窗口重叠。
9.2 Vector Database¶
向量数据库保存Embedding,并根据相似度查找相关文本块。常见相似度包括余弦相似度、点积和欧氏距离。
向量检索擅长语义相似,但对精确编号、专有名词和关键词不一定最好。因此实际系统常将向量检索与关键词检索组合为Hybrid Search。
9.3 Reranker¶
初次检索强调快速召回,Reranker再使用更精确的模型重新排列候选结果。它能提高进入上下文的资料质量,但也会增加延迟。
9.4 RAG的边界¶
RAG不是“接上知识库就不会出错”:
- 检索不到正确资料时,模型仍可能猜测;
- 文档本身可能错误或过期;
- 相关文本不一定真正支持最终结论;
- 引用可能存在,但引用与答案不对应;
- 恶意文档可能包含间接提示注入。
RAG系统需要同时评估召回质量、答案正确性、引用一致性和安全性。
10 Tool与Function Calling¶
Tool是模型能够请求外部系统执行的能力,例如:
- 搜索网页;
- 查询数据库;
- 运行代码;
- 读写文件;
- 发送邮件;
- 操作浏览器。
Function Calling或Tool Calling通常采用以下过程:
模型本身通常不会直接执行函数。它只生成结构化的调用请求,真正的执行、超时、重试、鉴权和错误处理由模型外部的程序完成。
10.1 Structured Output¶
Structured Output要求模型按照JSON Schema等结构生成数据,适合信息抽取和工作流衔接。它能保证格式更稳定,但不保证字段内容一定真实,仍需进行业务校验。
10.2 MCP¶
MCP是Model Context Protocol,用统一协议连接AI应用与外部系统。MCP服务器主要可以提供三类能力:13
| 类型 | 说明 |
|---|---|
| Tools | 可由模型请求执行的操作 |
| Resources | 可读取的文件、数据或上下文资源 |
| Prompts | 可复用的提示模板 |
MCP解决的是“如何用统一接口接入能力”,并不自动解决Agent规划、权限策略、结果正确性或安全问题。
11 Agent¶
Agent是由模型驱动、能够在循环中观察环境、选择工具并调整下一步行动的系统。常见循环可以概括为:
ReAct将Reasoning与Acting交错进行,是理解现代Agent循环的重要范式。9
11.1 Workflow与Agent¶
| 类型 | 决策方式 | 优点 | 代价 |
|---|---|---|---|
| Workflow | 由代码预先规定执行路径 | 可预测、易测试、成本稳定 | 灵活性较低 |
| Agent | 由模型根据当前状态动态决定路径 | 能处理开放问题和意外情况 | 成本、延迟和失败方式更难控制 |
简单、稳定的任务应优先使用确定性代码或Workflow;只有当任务步骤难以预先写死时,Agent的自主决策才真正有价值。10
11.2 Planning与Reflection¶
- Planning:先将目标拆为子任务,再逐步执行;
- Reflection:检查中间结果并决定是否修正;
- Verification:通过测试、规则、第二个模型或外部工具验证结果;
- Checkpoint:保存进度,使长任务能够恢复或跨上下文继续。
这些机制可以提高复杂任务成功率,也可能带来循环、过度规划和Token消耗。
11.3 Multi-agent¶
Multi-agent系统让多个Agent分工协作,例如主Agent负责规划,子Agent分别搜索、编码或审查。
它适合能够并行探索、需要不同角色视角的任务,但并不会自动提高质量。多Agent还会带来任务拆分、状态同步、结果冲突、重复劳动和成本增加等问题。
12 Memory¶
Agent中的Memory不是单一技术,常见形式包括:
| 类型 | 内容 | 常见实现 |
|---|---|---|
| Working Memory | 当前任务计划、中间结果和最近对话 | Context Window |
| Episodic Memory | 过去任务和交互经历 | 数据库、日志、向量检索 |
| Semantic Memory | 用户偏好、事实和领域知识 | 结构化数据库、知识库 |
| Procedural Memory | 完成任务的方法和规则 | System Prompt、Skill、代码 |
长期运行时,系统会通过摘要、压缩、文件、数据库和Checkpoint将状态带到新的上下文。压缩可以节省Token,但也可能丢失细节,因此关键状态最好使用结构化数据或可验证产物保存。
13 Skill¶
Skill通常指可复用的任务能力包。它可能包含:
- 任务说明和操作步骤;
- 领域知识与参考资料;
- Prompt模板;
- 脚本、样例和资源文件;
- 对可用工具和验证方法的约定。
Skill不是模型权重,也不等于工具:
| 概念 | 回答的问题 |
|---|---|
| Prompt | 这一次希望模型做什么? |
| Tool | 模型能够调用什么外部能力? |
| Skill | 完成某类任务时应该如何组织知识、步骤和工具? |
“Skill”目前不是所有平台完全统一的标准。不同产品可能把它实现为一段系统指令、一个Markdown说明文件、一个插件包,或能够按需加载的工作流资源。
14 Harness¶
Harness可以理解为围绕模型运行的“控制系统”。如果说LLM是大脑、Tool是手,Harness就是神经系统、工作台和安全边界。
一个完整Harness通常负责:
- 组织System Prompt和消息历史;
- 加载Tool、MCP和Skill;
- 运行Agent循环;
- 管理上下文、压缩和长期状态;
- 执行工具并处理超时、重试和错误;
- 控制文件、网络、密钥和外部应用权限;
- 提供Sandbox与人工审批;
- 记录Trace、Token、成本和运行日志;
- 保存Checkpoint并支持中断恢复;
- 运行评测和Guardrail。
长时间Agent任务经常跨越多个Context Window。有效的Harness需要让Agent增量工作,并把计划、进度、测试结果和剩余任务保存为下一轮能够读取的产物。12
14.1 Framework、Harness与Orchestrator¶
这些词经常混用,可以做一个不严格但实用的区分:
| 概念 | 重点 |
|---|---|
| Framework / SDK | 提供开发Agent的代码抽象和组件 |
| Harness | 让单个或多个模型可靠运行的完整执行环境 |
| Orchestrator | 负责调度任务、Agent、队列和依赖关系 |
实际产品往往同时承担三种职责,没有绝对边界。
15 概念之间的关系¶
| 层次 | 代表概念 | 主要作用 |
|---|---|---|
| 模型内部 | Token、Parameter、Transformer、Attention、Embedding | 学习和生成内容 |
| 训练 | Pre-training、SFT、RLHF、DPO、LoRA | 获得知识、能力和行为偏好 |
| 单次推理 | Prompt、Context、Sampling、KV Cache | 决定本次模型看到什么、如何生成 |
| 知识增强 | RAG、Vector Database、Reranker | 引入可更新的外部知识 |
| 行动能力 | Tool Calling、Structured Output、MCP | 连接真实数据和外部操作 |
| 自主执行 | Agent、Planning、Memory、Multi-agent | 在循环中完成多步任务 |
| 能力复用 | Skill | 封装某类任务的知识和做法 |
| 运行控制 | Harness、Sandbox、Guardrail、Trace | 管理执行、安全、状态和可观测性 |
16 Evals¶
Evals即评测。公开Benchmark适合比较通用能力,但不能代替针对真实业务的评测。
LLM应用常见评测维度包括:
- 正确性与任务成功率;
- 指令遵循和格式合规;
- RAG召回率、答案忠实度和引用一致性;
- Tool调用参数与最终执行结果;
- Agent完成轨迹、步骤数量和恢复能力;
- 安全、隐私和越权行为;
- 延迟、Token与成本。
常见Grader包括:
| Grader | 适合场景 |
|---|---|
| 精确匹配或规则 | 分类、字段、格式和确定性答案 |
| 单元测试或执行器 | 代码、SQL和可运行任务 |
| 人工评审 | 主观质量、高风险决策和新型失败 |
| LLM-as-a-Judge | 大规模语义评估,但需要校准偏差 |
Agent不仅要评估最终答案,还要评估完整Trace:调用了什么工具、修改了什么状态、是否越权、失败后如何恢复。17
17 Safety与Security¶
17.1 Prompt Injection¶
Prompt Injection是恶意或非预期输入改变模型行为。它可以来自用户直接输入,也可以隐藏在网页、邮件、文档或RAG资料中,后者称为Indirect Prompt Injection。
17.2 Jailbreak¶
Jailbreak通常指刻意绕过模型安全限制。它与Prompt Injection有重叠,但重点是突破安全策略;Prompt Injection的目标还可能是窃取数据、误用工具或改变任务目标。
17.3 Excessive Agency¶
当Agent拥有超出任务所需的权限、工具或自主范围时,一个普通模型错误就可能变成真实损失。例如读取邮件只需要只读权限,不应同时获得发送和删除权限。
17.4 Guardrail¶
Guardrail是模型外部或内部的约束机制,例如:
- 输入和输出过滤;
- JSON Schema与业务规则校验;
- 工具参数白名单;
- 最小权限和Sandbox;
- 高风险动作人工确认;
- 速率、预算和循环次数限制;
- 全程日志、审计与异常告警。
Warning
不能只靠Prompt告诉Agent“不要做坏事”。只要Agent能够访问不可信内容并执行真实操作,就应假设模型可能被误导,通过权限隔离、参数校验、Sandbox和人工审批限制潜在影响范围。
生成式AI还涉及错误信息、隐私泄露、偏见、知识产权、供应链和过度依赖等风险。NIST的生成式AI风险框架强调应在设计、开发、部署和评估的完整生命周期内管理这些问题。14
18 Open Source、Open Weight与API¶
| 方式 | 说明 |
|---|---|
| API Model | 通过服务商接口调用,部署简单,但权重通常不可见 |
| Open-weight Model | 可以下载模型权重,但训练数据、训练代码或许可证未必完全开放 |
| Open-source Model | 源码、权重、数据和许可证达到何种开放程度仍需逐项判断 |
| Local Model | 在本地设备或自有服务器运行,控制力强,但需要计算资源和运维 |
“可以下载权重”不等于严格意义上的开源。选择模型时还需要关注许可证是否允许商用、再分发和衍生训练。
18.1 Quantization¶
Quantization即量化,将权重从FP32、FP16或BF16压缩到INT8、INT4等更低精度,以减少存储和显存占用,并可能提高推理速度。代价是精度损失,实际效果取决于模型、量化方法、硬件和任务。
18.2 Model Serving¶
模型部署还涉及Batching、并发调度、KV Cache管理、显存分配和请求队列。单次请求最快的配置,不一定具有最高总体吞吐量。
19 最后:不要把系统能力都归因于模型¶
同一个模型放在不同系统中,表现可能差异很大:
理解大语言模型时,最重要的不是记住每个新名词,而是先判断它属于哪一层:它是在改变模型权重,改变本次上下文,连接外部能力,还是负责整个系统如何运行。这样面对新的框架和产品时,就不容易被换了一套名字的相同概念迷惑。
参考资料¶
-
Attention Is All You Need —— Transformer论文 ↩
-
Neural Machine Translation of Rare Words with Subword Units —— 子词与BPE ↩
-
Scaling Laws for Neural Language Models —— Scaling Law ↩
-
Training Compute-Optimal Large Language Models —— Chinchilla计算最优训练 ↩
-
Training Language Models to Follow Instructions with Human Feedback —— InstructGPT与RLHF ↩
-
Direct Preference Optimization —— DPO ↩
-
LoRA: Low-Rank Adaptation of Large Language Models —— LoRA ↩
-
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks —— RAG ↩
-
ReAct: Synergizing Reasoning and Acting in Language Models —— ReAct ↩
-
Building Effective AI Agents —— Workflow与Agent ↩
-
Effective Context Engineering for AI Agents —— Context Engineering ↩
-
Effective Harnesses for Long-Running Agents —— 长时间Agent Harness ↩
-
Model Context Protocol: Server Concepts —— MCP Tools、Resources与Prompts ↩
-
Artificial Intelligence Risk Management Framework: Generative AI Profile —— NIST AI 600-1 ↩↩
-
Switch Transformers —— Mixture of Experts ↩
-
Hugging Face Transformers: Cache Strategies —— KV Cache ↩
-
Demystifying Evals for AI Agents —— Agent评测 ↩
