企业官网建设流程全解析

上下文工程

本博客为 DataWhale 开源教程《AI-Agent-Book：从入门到 Agent 工程实践》的组队打卡学习笔记。>本blog为datawhale开源教程《ai-agent-book：从入门到Agent工程实践》的组队打卡学习笔记

文章目录

• 上下文工程
• Agent调用大模型的API
• 带工具调用的多轮交互：Agent 的核心循环
• KV Cache

上下文的设计和管理称为上下文工程（Context Engineering）
Agent 拿到的上下文质量直接决定了它能否完成任务：它需要实时的代码上下文、流程的规范、环境信息三类，上下文的质量是Agent能力的关键
上下文工程并非技术问题而是组织问题，高度透明的文档创造了对AI友好的环境
Agent 的下一步行动取决于截至当前的完整交互上下文，而不只是眼前这一条输入

Agent调用大模型的API

大模型 API 的核心是一个消息列表（messages）
列表中的每条消息都有一个角色（role）标识，模型根据角色来理解每条消息的含义和来源，组成为：

1. system：系统提示词，由开发者编写，定义 Agent 的身份、行为规则、约束条件
2. user：用户消息，来自终端用户的输入
3. assistant：助手消息，模型之前的回复，包括文本回复和工具调用请求
4. tool：工具结果，Agent 框架执行工具后，将结果以tool角色的消息送回给模型
   system、user、assistant 和 tool 四种消息角色分别对应系统提示词、用户消息、模型回复和工具执行结果。工具定义（tools）作为请求的独立字段（而非消息），告诉模型有哪些工具可以使用、每个工具接受什么参数，并不是一种消息角色

带工具调用的多轮交互：Agent 的核心循环

第一次 API 调用——Agent 框架发送初始请求
模型返回工具调用请求，真正执行工具的是 Agent 框架
模型负责决策（调用什么工具、传什么参数），Agent 框架负责执行（实际调用 API、运行代码）
Agent 框架执行工具，然后发起第二次 API 调用
Agent 框架拿到模型的工具调用请求后，执行工具，然后将完整的对话历史加上工具执行结果一起发送给模型
第一次的 assistant 消息被原样放回消息列表——这让模型能“看到”自己之前做了什么决策
tool 消息通过 tool_call_id 与对应的工具调用关联
模型根据工具结果生成最终回复
请求→工具调用→执行→送回结果→再请求
模型返回了 tool_calls 就执行工具并继续循环，没有就输出结果并退出

KV Cache

模型每生成一个 token，都要回头看一遍前文所有 token 的中间计算结果。如果每轮都从头算一次，开销会随上下文长度爆炸式增长。KV Cache 的做法是：把前文的中间计算结果缓存下来，下一轮只需要计算新增 token 的部分（前提是要复用的上下文 token 前缀保持不变）