KatzenyaSax: Hello!

提示词工程 & 上下文工程大模型提示词工程（Prompt Engineering）是什么？提示词技巧有哪些？上下文工程(Context Engineering) 是什么？和 Prompt Engineering 有什么区别？ 提示词工程Prompt 该怎么写？Prompt 一般四要素 要素 作用 常见表述 Role（角色） 告诉模型该用哪个领域的知识和语气 “你是一位 10 年经验的 Java 架构师” Task（任务） 说明要完成什么动作 “请评审以下代码的性能问题” Context（上下文） 补充和任务相关的背景 “当前线上 QPS 2000，响应时间超 500ms” Format（格式） 规定输出长什么样 “输出 JSON，包含 bottleneck、solution 两个字段” 其实归根结底，就是给模型明确的边界与约束，告诉模型xxx之内的随便做，xxx之外的不能做，这个xxx就是要告诉模型的边界。 而在顺序上，为什么一般遵循 角色、任务、上下文、格式 呢？因为模型容易更加重视提示词的开头和结尾，所以对于需要严格定义的要素，一般放在开头和结尾。 ...

Agent 记忆系统AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制 记忆系统的设计Agent 的记忆一般分成短期和长期，二者需要从逻辑上、物理上进行隔离。不过，一般而言长期记忆从短期记忆的沉淀中得来。 短期记忆短期记忆是内存的记忆，用于存放当前交互过程，包括用户提问、模型每轮回复、工具调用的中间结果。我们可以说：短期记忆就是Agent动态构建的Context。 短期记忆长度受限于模型的窗口，为了防止 Context 超过窗口，一般对短期记忆做如下操作： 压缩。 卸载：将上下文分索引，只将索引存到上下文中，内容卸载到本地持久化，按需查找再填入 Context。 隔离：一般是 Multiagent 时，master 给 slave 相对干净的上下文执行。 长期记忆长期记忆是持久化的记忆，例如 coding agent 普遍用 jsonl 文件存储交互信息；又或者一些通用 Agent 中将一些真理知识存入向量数据库，这些信息很大程度来源于短期记忆。 那长期记忆和 RAG 有什么区别？ 技术侧重点不一样；长期记忆只是单纯地将重要信息持久化，防止丢失；而 RAG 系统则 ...

Agent 核心概念Agent 核心概念 一个可用的 Agent 必须包含哪几个部分？必须有以下三大部分： LLM、Tool、Context。 其中，LLM 负责工作决策；Tool 由 LLM 决策调用，增强 LLM 功能；Context 构建 LLM 工作上下文。 前两者自不必说，很多人实际上忽略了 Context 的重要性，这一部分甚至可以排在三者中最重要的地位，在 LLM 高度依赖 AI 厂商提供的 API、Tool 直接化用传统编程成果的当下，Context 的高度依赖设计者自身经验，上下文质量直接决定一个 Agent 的智商，这可能将是未来竞争的主要战场。 ToolAgent 调用工具，必不可少的两大要素：Structured Schema & MCP Protocol。前者使 LLM 能够规范调用工具，后者使 Agent 与工具直接能够实现通信。 Structured Schema现在主流的数据格式基本都在向 OpenAI Function Calling Schema 靠拢，一个 Schema 被设计出来是供 LLM 查看的，里面定义了诸如工具名称、用途、何时调用 ...

结构化输出大模型结构化输出：从 JSON 契约到 Function Calling 落地 本文主线：先看“只靠 Prompt 要 JSON”为什么不稳，再看怎么用 Schema 把输出变成契约，最后落到 Function Calling、MCP 和 Java 后端工具执行。 在如今 Agent 工作量中，需要大模型频繁地调用各类工具以跳脱出原始的对话框，当前的 Agent 也越来越依赖结构化输出，能够稳定、可靠地输出各种形式的结构化内容，意味着 Agent 对于工具的掌握就越熟练。 为了让大模型输出严格的结构化内容，让大模型在自回归生成时就遵守结构规范是一种符合直觉的方案，但在我们实际的经验中，大模型会频繁地不按照我们的要求进行，所以除了在大模型本身下功夫外，还需要在外部进行干预。 prompt 为什么不能强制规范结构化输出底层原因：大模型自身性能不足、幻觉、上下文污染。 具体表现为： 格式漂移：确实输出了 JSON，但是不只有 JSON，还有一些自然语言，比如 “以下是…”，或者在最后解释 “上述 JSON 是……” 等，如果直接返回给后端，光是自然语言这几句话就直接让服务爆了。 ...

上下文工程第九章 上下文工程 代码仓库 上下文工程学符合工程规范的上下文设计Transformer 本身有着缺陷，而为了防止上下文腐败和上下文漂移，我们需要人为地将上下文控制在一定长度和结构内，控制长度是为了防止重点事项被稀释，控制结构是为了尽可能地提升信息密度。 长度上能做的不多，只有及时遗忘、控制信息长度，反而是上下文的结构需要我们仔细思考。官方在文档中提到，建议按照以下结构控制上下文： 系统提示（System Prompt）：语言清晰、直白，信息层级把握在“刚刚好”的高度。 工具（Tools）：工具定义了智能体与信息/行动空间的契约，必须促进效率：既要返回token 友好的信息，又要鼓励高效的智能体行为 示例（Few-shot）：始终推荐提供示例，但不建议把“所有边界条件”的罗列一股脑塞进提示。请精挑细选一组多样且典型的示例，直接画像“期望行为”。对 LLM 而言，好的示例胜过千言万语。 总的指导思想是：信息充分但紧致。 上下文检索与 Agent 工作上下文的结构与长度，是随着 Agent 工作实时变动的，特别体现在：需要的时候主动检索，不需要的时候不加载 ...

记忆与检索第八章 记忆与检索 代码仓库 框架现有的缺陷？最显著的一点是：所有的历史上下文，都只在程序运行期间存在的（也就是内存里），程序运行完毕历史就没了，会话之间的上下文也没法共享。 另一个缺陷则是，我们太过于依赖 LLM 本身的能力了，我们必须承认不同供应商的 LLM 的知识库水平是不同的，比如 gemini 知识库很全，claude 在 coding 知识上很强。完全依靠 LLM 的知识库是不稳定的，我们需要构建自己的知识库。 所以我们的框架，当务之急是解决以上问题，我们最容易想到的是将历史上下文持久化，这样就可以解决上下文共享，也可以建立我们自己的知识库。 上手体验：MemoryTool + RAG官方依然给出了完整的 rag 组件，使用 pip 安装： 123pip install "hello-agents[all]==0.2.9"python -m spacy download zh_core_web_smpython -m spacy download en_core_web_sm 随后，需要三个组件：Qdrant、Neo4J、Embedding， ...

构建你的 Agent 框架第七章 构建你的智能体框架 代码仓库 本章目标本章目标为，我们需要手写以下架构： 123456789101112131415161718192021222324252627282930HelloAgent/ │ ├── core/ # 核心框架层 │ ├── agent.py # Agent基类 │ ├── llm.py # HelloAgentsLLM统一接口 │ ├── message.py # 消息系统 │ ├── config.py # 配置管理 │ └── exceptions.py # 异常体系 │ ├── agent/ # Agent实现层 │ ├── simpleAgent.py # SimpleAgent实现 │ ...

第四章 智能体经典范式构建 本章任务： Cli：构建一个基本的客户端，能够成功调用 LLM ，并解析 LLM 流式返回的结果 ReAct(Reasoning and Action)：着重于实现如何让模型在执行过程不断根据当前状况动态地更新行动计划； Plan-and-Solve：着重于构建模型的规划能力； Reflection：模型的反思能力。 基本 Cli前置库： 1pip install openai python-dotenv 仔细阅读一下 HelloAgentLLM.py 具体干了什么。 初始化1234567891011def __init__(self, model: str = None, apiKey: str = None, baseUrl: str = None, timeout: int = None): # 1.初始化客户端。优先使用传入参数，如果未提供，则从环境变量加载。 self.model = model or os.getenv("LLM_MODEL_ID") apiKey = apiKey or os. ...

大模型 API 调用工程实践：流式输出、重试、限流与结构化返回 这篇文章从 构建一个生产级ai对话框 的实际业务出发，解析了一些开发者可能遇到的问题，并尝试解答。 LLM 的调用LLM 调用大致流程流程如下： 客户端请求，服务器鉴权：用户（客户端）提出访问请求，发给服务器（开发者的），服务器需要确认该请求的用户、套餐、配额，确认是否允许此次访问； 服务器组装 prompt：若访问合法，则服务器会将 system prompt、历史信息、RAG 知识、MCP 工具包、用户 prompt、输出格式等信息组装成需要 llm 处理的 prompt； 服务器 token 估算：组装好的 prompt 会被 Tokenizer 拆分为 token，同时计算 token 输入量，估算需要给输出留多少 token 量，并决定是否压缩上下文、裁切上下文、是否可以换用更加契合需求的模型； 模型网关路由：选择模型、供应商、区域等路由工作。此外模型网关还肩负这一个重要职能：全权确保大模型的输出稳定，所以还包含了超时参数、重试策略、限流桶等； 供应商 LLM 工作：服务器将请求发往供应商，请求调用大模 ...

LLM 运行机制：Token、上下文窗口与采样参数怎么影响输出 Token 及其影响基于历史 token 的预测 自回归生成：根据前面的历史，预测后面的输出。 如何去预测？一般来说需要模型自行识别历史 token 中哪些是相关性高的，哪些是相关性低的，选取高相关性的 token 更容易预测。因此，模型的一个重要参数是选取规则，目前有 Temperature / Top-p 等，选取规则本身是会影响模型预测精度的。 而选取 token 后，需要输出 token，这里引申另一个重要参数是 Max Tokens，即决定模型在单次预测中，最多可以输出的 token 总量。不过，这个参数并不会影响模型本身的预测精度，因为预测的结果是不变的，模型只是按照 max token 这个参数计算并输出，如果不够了截断就是了。 分词器 Tokenizer 分词器 Tokenizer：将自然语言切分 token 的规则。 Tokenizer 本身是需要训练的，一旦训练好，此后均按照这套规则进行分词。 各大模型基本上会自己训练一套 Tokenizer，所以不同的模型直接的 token 计算规则不能 ...