跳转至

基本名词

AgentGuide项目路径: https://github.com/adongwanai/AgentGuide

📌 LLM

Token
与大模型交互时，用户提示词的自然语言会先转为token，提高效率

Embedding
token是单个数字，可能无法准确表达其原意，因此向量化为多维数组，该过程即embedding

以上两者都LLM的一部分，而RAG Embedding，则是将一整段话向量化，准确识别语义。

📌 Agent

早期限制和背景

  • 上下文窗口短；
  • API 无状态，需要应用自己维护历史；
  • 指令遵循和推理能力不足；
  • 没有原生工具调用；
  • 应用多为静态 Prompt + 硬编码工作流 + 意图穷举。

随着技术发展，Agent得以实现与应用

  • LLM 推理、指令遵循、代码能力提升；
  • 上下文窗口扩大；
  • Function Calling / Tool Calling 出现；
  • 记忆、规划、反思框架成熟；
  • 外部工具和 API 生态丰富。

整体关系

Agent = 认知核心（LLM/多模型） + 记忆 + 规划/反思 + Agent Runtime（执行编排） + 工具/环境。

工作流程：

  1. 用户输入。
  2. LLM 理解、规划、决策。
  3. LLM 通过 Function Calling 输出结构化工具调用意图。
  4. Agent Runtime 解析并执行。
  5. 如果工具走 MCP，则由 MCP Client 按 MCP 协议请求 MCP Server。
  6. MCP Server 执行工具/访问数据源，返回结果。
  7. Runtime 把结果回填给 LLM。
  8. LLM 继续推理，直到生成最终回答或完成任务。

总结：Function Calling 让模型决定“要调用什么工具”；MCP 让应用以标准方式“连接和调用外部工具”；Agent Runtime 是负责执行、编排和状态管理的“执行者”。

CLI还是MCP？

CLI 和 MCP 的核心区别在于服务对象与交互逻辑

  • CLI 要求操作者输入绝对准确的指令。
  • MCP 允许 AI 用自然语言和标准化协议自主探索和调用工具。
核心维度 CLI (命令行界面) MCP (模型上下文协议)
主要服务对象 人类（开发者、运维）与传统自动化脚本 AI 智能体（大语言模型、AI 客户端）
交互逻辑 指令驱动：输入确定的命令与参数（如 mysql -u root），错一个字母就报错。 意图驱动：AI 客户端与 MCP 服务端动态握手，AI 根据用户模糊的自然语言自主选择调用哪个工具。
安全与权限 高风险直连：通常在具有完整 Shell 权限的终端中运行。 沙盒化隔离：MCP 是独立的后台进程，通过 stdio/SSE 通信，只向 AI 暴露限定的工具和数据，无需给 AI 终端权限。
上下文感知 无：每次执行都是独立的，没有持久状态，也不懂业务背景。 强：自带 Resources 概念，能主动把数据库表结构、系统状态等作为“上下文”喂给 AI。
跨平台接入 依赖执行环境：换个没有 Bash 或对应命令的系统就无法运行。 协议级通用：写好一个 MCP Server，Cursor、Claude Desktop 等所有支持该协议的 AI 软件直接无缝挂载。

📌 Skill

定义：在智能体框架中，Skill通常定义 Agent 拥有的能力集合。

1.提示词：ai的人设，系统提示词一般优先级高于用户提示词

2.Command：提示词太长时，需要用md文件存放，通过Command调用对应的提示词（实际似乎没有这一层）。

3.Metadata元数据：文本太多时，花费token多，按场景拆分+md开头写提示信息（即元数据）；功能类似索引，以减少token消耗。

4.References：根据不同的用途，建立对应的路由进行按需调用，也称为渐进式披露。

5.Skill：包括References、Scripts等，根据上下文，调用不同的提示词及对应的脚本（甚至让大模型自己写脚本），实现动态读取提示词。

Skill的功能类似Workflow（常见工具：n8n）的逻辑编排，但不同的是Skills由大模型驱动，更加灵活。

补充

第5点：agent目录，当主Agent调用该Skill时，可能会根据agent中的配置启动一个专门处理该任务的子Agent，拥有独立的prompt、工具权限、模型参数等。

智能体目录在不同软件的名称不一样，如：.claude/agents/、.trae/rules/、~/.gemini/extensions/

📌 其他

🚁 多模态

指的是 AI 模型能够理解和处理多种不同类型（模态）的信息，并能在它们之间建立联系。

常见的模态包括：

  • 文本（语言、文字）
  • 图像（照片、图表、绘画）
  • 音频（语音、音乐、环境音）
  • 视频（动态画面与声音的结合）

🚁 llm参数

Temperature

  • 低温，严谨保守可预测，适合事实性回答如代码、翻译、数学题等。温度为0时，输出结果几乎相同。
  • 高温，创意多样性，适合创意协作、头脑风暴。

Top_p

  • 低Top-p，模型只考虑概率最高、最集中的那极少一部分词汇，偏严谨保守。
  • 高Top-p，模型会考虑更多词汇，相当于把取值范围扩大。

Top_k

  • 低Top-k，模型只从最高的10个词中选，回答很集中。
  • 高Top-k，模型从更多的词中选，多样性增加。

参数与人设提示词的关系：前者相当于硬件参数，改变数学概率；后者相当于软件参数，引导知识调用和风格模仿。

可以先给人设再搭配参数调整。

参考资料：

大模型参数如何设置（温度、Top-p、Top-k）+使用场景

📌 sandbox

基于传统虚拟机做精简，保留应用必须的虚拟硬件，称为MicroVM。

Q: 为什么不用docker容器？
A: 容器本质是进程，多个容器共享宿主机操作系统内核，一旦有内核漏洞或逃逸，还是可能会影响宿主机。

  • MicroVM作用: 隔离环境，以防agent运行危险命令影响宿主机。
  • MicroVM局限: 启停不足于支持毫秒级响应的需求。

云沙箱路线

开源方案目前有: CubeSandbox、E2B

通过云沙箱底座，管理（创建、销毁、回收）MicroVM资源。

📌 注意力机制

长上下文读取时，根据语义重要性分配注意力，并行计算所有Token间的关系，解决RNN记不住长文的痛点

但因复杂度是O(n²)，所以长文本极耗算力。因此，这也是为什么要做KV Cache（缓存历史计算的K/V）来加速推理的原因。

token缓存

多次请求使用相同的系统提示词（System Prompt）、长文档背景或历史对话前缀，可以命中缓存，减少算力消耗，且首字延迟更低。

当场景需分级时，如“重推理”和“轻处理”的任务，应保持使用同个模型: 通过派发子agent返回结果给主agent的方式进行。

而在agent开发工具，还可通过让agent读代码文件以享受缓存，而非把代码直接写在prompt中。

总结

  • 前缀匹配决定缓存: 前缀里任何位置的变化，都会让其后所有内容的缓存失效
  • 用消息代替指令修改: 切换模式、时间更新等改动，塞进对话消息，别去动系统指令
  • 勿中途切工具/模型: 延迟加载代替工具增删
  • 如同监控在线率一样监控命中率
  • 分叉必须共享主对话前缀

📌 大模型选择

  1. 分场景

    • 重推理还是轻处理任务
    • 上下文窗口大小要求，如长文档刚需：若1M的上下文窗口能直接塞入语料，则不必做复杂的RAG切片。既减少了工程复杂度，又避免了切片丢失上下文的幻觉。

  2. 细分领域

    • 代码垂直（如Claude 3.5/3.7）：训练语料含海量高质量GitHub代码，抽象能力和工程架构力碾压同级。
    • 中文原生（如DeepSeek、文心）：中文语义理解（成语、古诗词、谐音梗）远优于海外模型，且价值观对齐更贴合本土监管。

  3. 成本控制的考量