大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
本文详细记录了作者在一周时间内，为内部研发平台接入Agent开发能力的完整技术实践，全程干货无冗余，适合想要自建Agent的小白程序员、资深开发者参考学习。内容涵盖技术选型（Faas、Next.js+React、LangGraph）、系统提示词优化、知识库建设（RAG）、工具接入及上下文管理等核心技术点，重点解决了连续对话、上下文压缩等实际开发难题，通过工具结果缓存和上下文压缩机制，有效降低token消耗，提供可直接复用的完整技术实现方案。
 

最近花了一周时间，给内部一款传统研发平台接入了Agent开发能力，很多同行和同学都对Agent的底层实现、落地流程非常感兴趣，所以整理了这篇实战笔记，把整个接入过程、踩过的坑、优化技巧都分享出来，尤其适合想入门自建Agent、提升AI开发能力的程序员，建议收藏备用，避免后续踩坑。

说明：因人力有限，部分细节方案未做深度评测，优先选用业界成熟、实践案例较多的方案，核心重点分享思路梳理和上下文管理的实操过程。文中用到部分内部平台基础能力（如rag、代码管理、deepwiki等），外部开发者可自行寻找对应替代工具，不影响核心流程复用。

我们接入Agent的载体是奥德赛研发平台，它是ICBU买家技术的TQL（淘宝基于开源GraphQL定制的版本）研发平台，核心作用是让开发者通过编写TQL脚本来实现BFF接口，日常主要用于后端开发者的接口开发、调试工作。

近一年来，AI Coding工具（如cursor、claude code）快速普及，极大解放了前端开发者的生产力，于是就想着把这种高效模式带给后端同事，摆脱纯手搓代码的繁琐，因此就有了这次BFF Agent（昵称小D同学）的接入开发。

先给大家看一下原有平台的形态，开发者可以在平台上完成TQL脚本的编码、调试、发布等全流程操作：

核心需求是在现有平台内集成Agent，要求Agent能感知前台页面环境，甚至对页面进行操作（重点用于AI辅助Coding）。经过调研，主流有三种实现方式，这里给大家清晰梳理，方便小白快速选型：

补充：如果只是做简单的对话式Agent，无需自建开发，直接用开源应用平台搭建即可，节省开发成本。

综合考量开发效率、用户体验和后续扩展性，我们最终选择了第三种方案——宿主页面Iframe嵌入Agent，这也是最适合现有平台、小白最易上手的方案。

（一）宿主页面Iframe嵌入Agent

先给大家讲清楚核心数据流转逻辑（小白可直接参考）：

1. 宿主页面（原有研发平台）向Agent暴露关键信息，包括脚本内容、请求参数、调试结果等上下文，同时提供脚本执行、脚本Diff预览等页面操作的工具接口；
2. Agent感知宿主页面的上下文环境后，向服务端发起请求，再将内容编辑、脚本执行等工具执行动作，推送给宿主页面，完成交互。

流程概要图如下，清晰易懂，建议保存：

（二）核心应用框架选择（小白直接抄作业）

框架选择不做过多冗余对比，直接给出贴合场景、易上手的方案，每个选择都说明原因，帮助小白理解背后的逻辑，避免盲目选型。

1. 集团Faas基建

Faas（Function as a Service，函数即服务）是全托管、事件驱动、弹性伸缩的Serverless计算基础设施，核心优势就是让开发者只关注业务逻辑代码，无需操心服务器运维、资源扩缩容、中间件对接等底层细节。

划重点：对于轻量Agent开发来说，Faas的“免运维、聚焦代码”特性简直是刚需，小白无需关注底层部署，专注于Agent核心功能开发即可。

2. Next.js + React

前后端应用框架选择Next.js + React，核心原因有两个，小白可参考适配自己的场景：

1. 内部有成熟的前后端一体化框架可直接复用，降低开发成本；
2. 前后端共用Nodejs、JavaScript开发语言，集成在一个应用中，配合AI Coding工具（如Cursor）可大幅提升开发效率，真正实现“只关注功能，AI帮做实现”，小白也能快速上手。

3. LangGraph

LangChain团队在WorkFlow/Agent领域深耕多年，高度抽象了Agent的开发模式，而LangGraph作为其核心工具，最大的优势是“低代码、易上手”。

它通过巧妙的状态图设计，让开发者无需深入理解Agent底层逻辑，只需关注系统提示词、工具节点（通常是mcp），就能轻松实现一个具备自主决策能力的Agent，手残党、小白友好度拉满。

（一）应用框架初始化

结合上面的选型，我们将LangGraph抽象的状态图展开，替换成自己的工具，就能得到BFF Agent的基础架构，小白可参考这个思路，替换成自己的工具即可快速搭建骨架。（此处无需深究细节，后续会详细讲解工具接入）

BFF Agent状态图：

基础伪代码（小白可直接复制修改，结合Cursor优化）：

GPT plus 代充 只需 145import { StateGraph, END, START } from ‘@langchain/langgraph’; // 创建状态图 const agentGraph = new StateGraph({ channels: { messages: { reducer: (prev, next) => […prev, …next], default: () => [], }, }, }); // 添加节点 agentGraph.addNode(‘agent’, async (state) => { const response = await model.invoke(state.messages); return { messages: [response] }; }); agentGraph.addNode(‘tools’, async (state) => { const lastMsg = state.messages[state.messages.length - 1] as AIMessage; const toolMessages = []; for (const toolCall of lastMsg.tool_calls || []) { const result = await tools .find((t) => t.name === toolCall.name) .invoke(toolCall.args); toolMessages.push( new ToolMessage({ content: result, tool_call_id: toolCall.id }), ); } return { messages: toolMessages }; }); // 设置边 agentGraph.addEdge(START, ‘agent’); agentGraph.addEdge(‘tools’, ‘agent’); // 条件边：根据是否有 tool_calls 决定路由 agentGraph.addConditionalEdges( ‘agent’, (state) => { const lastMsg = state.messages[state.messages.length - 1] as AIMessage; return lastMsg.tool_calls?.length > 0 ? ‘tools’ : END; }, { tools: ‘tools’, [END]: END }, ); // 编译图 const graph = agentGraph.compile(); 

提示：参考LangGraph官方文档，配合Cursor工具，可快速实现上述基础有向、有环状态图，这就完成了BFF Agent服务的基础骨架。模型选择上，由于需要实现生码功能，我们选用了Claude-4.5-haiku，小白可根据自身需求，替换成Qwen、ChatGPT等模型。

重点提醒：搭建完基础骨架后，核心工作是“从能用到好用”，也就是上下文工程的优化，这部分直接决定Agent的体验和性能，后续内容全程干货，小白一定要重点看！上下文优化没有固定顺序，因为不同类型的上下文会交叉影响，需要根据实际场景灵活调整，比如优化完系统提示词后，可能发现工具调用不符合预期，需要回头再调整提示词。

（二）系统提示词优化（核心技巧，小白必学）

补充：Anthropic官方推荐的提示词优化技巧非常实用，下面分享我高频用到的3个基础技巧，小白可直接套用，更多高级技巧建议大家去学习官方文档，能少走很多弯路。

1. 角色设定：给模型设定清晰的角色，能显著提升模型性能，改进模型注意力，帮助模型聚焦核心任务，减少无关输出。比如我们给模型设定“专业TQL脚本编写助手”的角色，让它专注于TQL相关操作。
2. 使用XML格式：这是Anthropic官方强推的技巧，实测效果显著。当遇到模型不遵循指令、上下文过长导致遗忘或幻觉时，将提示词改成XML格式，能有效解决问题，让提示词更清晰、更易被模型识别。
3. 提供正例示例（few-shot）：给模型提供少量准确的正例，能大幅改善输出质量。这里提醒小白一个坑：尽量给正例，不要给反例，避免分散模型注意力（比如你让模型“不要想吃饭”，它反而会刻意关注这件事）。

下面结合我们的实际场景，给大家展示这3个技巧的具体用法，小白可直接参考套用：

1. 角色设定 + XML格式结合

核心问题：淘宝的TQL本质是GraphQL的方言，且ICBU在其基础上做了定制，大模型（包括Claude、Qwen）默认不了解这种私域知识，这也是小白自建Agent时最常遇到的问题——模型不熟悉业务私域知识，导致输出不符合预期。

解决思路：通过角色设定，让模型聚焦GraphQL相关知识，同时明确TQL与GraphQL的区别；用XML格式组织提示词，让模型更易识别指令；在提示词中加入基础私域知识，引导模型通过工具查询详细内容，避免提示词过于冗长。

小D Agent的提示词摘要（小白可复制修改，替换成自己的业务场景）：

<role>你是小 D 同学，一个专业的 TQL 脚本编写助手，TQL 是淘宝基于 GraphQL 扩展的查询语言，你只会写 TQL 语法，不会任何其它脚本。你的任务是帮助用户基于企业知识和用户输入，编写高质量的 TQL 脚本。</role> <instructions> <instruction>你非常欠缺 TQL 知识，但好在系统内置了很多工具，你可以充分使用这些工具来辅助你完成任务。</instruction> <instruction>系统在开源 GraphQL 的基础上，扩展了很多自定义的指令，如果你遇到不确定或无法实现的需求，可充分用工具查询相关知识</instruction> <instruction>回答要专业、友好、有条理。使用 Markdown 格式输出。</instruction> <instruction>在编写 TQL 脚本时，要确保语法正确、查询结构清晰、字段选择合理。</instruction> </instructions> 

关键说明：第一条指令很关键，小白可重点参考——在没有这条指令时，模型会过于自信（即使temperature=0，最严谨状态），拿到需求后直接写GraphQL脚本，与TQL语法不符；加入这条指令后，模型会变得谨慎，主动调用知识库查询私域知识，减少错误输出。

另外，TQL在GraphQL基础上的扩展内容较多，为了避免提示词过于冗长、分散模型注意力，我们只在提示词中保留基础介绍（索引知识），引导模型在使用具体能力时，通过工具动态查询详细内容，这也是小白优化提示词的核心技巧之一。

TQL自定义指令（小白可替换成自己的业务指令）：

GPT plus 代充 只需 145<directives> 非常重要！系统有大量的扩展指令，具体用法需要通过工具查询相关知识， 在使用这些指令时，一定要先学习指令的用法，不要盲目使用。 指令一般紧挨着字段或函数， fieldA @指令名 或 funcA(xx) @指令名 这样使用。 以下是常用指令（格式: “指令名”:“描述|参数”）: <![CDATA[, “字符串操作”:{“suffix”:“添加后缀|value”,“prefix”:“添加前缀|value”}, “条件过滤”:, “列表操作”:, “逻辑脚本”:{“mapping”:“映射|func”,“const”:“常量|value,beforeExecute=false”}, “高级扩展”:{“medusa”:“Medusa服务|url,language”,“diamond”:“Diamond服务|url”} }]]> </directives> 

TQL全局函数（小白可替换成自己的业务函数）：

<TQLFunctions name=“系统内置的全局函数”> <description>以下是 TQL 脚本中可直接使用的内置函数，详细用法请通过知识库查询。</description> <![CDATA[ 【字符串处理】 - QL_concat: 拼接三个字符串（a, b, c参数） - QL_string_replace: 字符串替换（replaceText, searchString, replaceString） - QL_stringToList: 字符串按分隔符转列表（data, delimiter） - QL_stringToJSON: 字符串转JSON对象 - QL_jsonStringify: JSON对象转字符串 - QL_joinStringByPath: 通过JSON Path提取属性并拼接（object, path, delimiter） - QL_urlDecode: URL解码 - QL_addHttpsSchema: 自动添加或转换为https协议头 - QL_addUrlParam: 给URL添加参数（url, param） 【数值计算】 - QL_sumLong: 两数相加（addition1, addition2） - QL_subtraction: 两数相减（minuend, subtrahend） - QL_divideInt: 整数除法向下取整（dividend, divisor） - QL_random_int: 生成指定范围随机整数（min, max） 【条件判断】 - QL_if: 三元条件判断（condition, output, orElse） - QL_conditional: 复杂条件表达式，支持#env.get()获取变量（exp, params） - QL_defaultIfBlank: 空值时返回默认值（str, defaultValue） - QL_timestampComparator: 判断当前时间是否在指定时间戳范围内 【AB测试】 - QL_abTest: AB实验分流，返回命中的实验桶标识（experiment） - QL_batchAbTest: 批量执行多个AB实验 【数据处理】 - IDs_fromString: 从字符串解析ID对象，支持商品/类目/供应商/公司/国家（ids）【重要】 - QL_mergeList: 合并两个列表（aim主列表, tail尾部项） - QL_subList: 截取列表子集（base, from, to） 【国际化】 - QL_medusa: 美杜莎翻译，获取国际化文案（key）【所有文案必须使用】 - QL_countryFlag: 获取国家国旗链接（country） 【数据脱敏】 - QL_desensitization: 数字脱敏，末位补0（value） 【输出与重命名】 - TQL_output: 输出固定对象，包括布尔值、数字、数组、对象（object） - 字段重命名: 使用GraphQL别名 或 @hide指令隐藏原字段 ]]> </TQLFunctions> 

2. 示例用法（小白避坑重点）

提醒小白：不要一上来就给模型堆砌大量示例，建议先让模型自由发挥，在调试过程中，针对模型容易出错的场景，再给出精准的正例引导，这样能更高效地提升模型输出质量。

比如我们在调试中发现，模型总是将请求参数硬编码在脚本中，没有抽离成查询参数，导致脚本复用性差，于是就给了如下正例示例，快速解决了这个问题：

GPT plus 代充 只需 145<rule> <title>参数分离原则</title> <content> 建议将 GraphQL 请求的参数单独放在 variables 中，但要以实际需求为主。如果用户明确要求将参数写死在脚本中，或者参数是固定的常量值，可以直接写在脚本中。 当需要参数分离时： - 脚本中使用变量定义（\(variableName） - 参数值通过 editVariables 工具设置到 variables 中 - 使用 editScript 和 editVariables 两个工具分别更新脚本和变量 示例（参数分离）： 脚本：query(\)userId: String!) { user(id: $userId) { name } } 参数：variables：{“userId”: “12345”} 这样做的好处：脚本可复用，参数和逻辑分离，便于维护和调试。 </content> </rule> 

总结：系统提示词优化的核心是“聚焦注意力、清晰指令、精准引导”，小白可直接套用“角色设定+XML格式+正例示例”的组合，结合自身业务场景调整，能快速提升Agent的输出质量。

（三）知识库建设（RAG实战，小白可落地）

前文提到，系统提示词只能承载少量私域知识，而TQL的详细用法、服务端内部接口字段、线上成熟脚本等海量知识，无法一次性放入提示词，此时RAG（检索增强生成）就是最成熟、最适合小白的知识管理方式。

我们的小D Agent知识库，主要分为三大类，小白可参考这个分类逻辑，搭建自己的知识库：

1. 线上热门脚本库

通过监控线上脚本调用量，提取出Top 100的热门脚本，然后用Qwen小模型对每个脚本进行解析，生成格式化的文档（包含脚本功能、用法、注意事项），帮助模型快速理解脚本含义，提升生码准确性。

示例如下：

小白重点技巧：RAG的分片策略直接影响召回质量，建议将每个脚本独立作为一个文档，再导入到知识库平台（我们用的是内部kbase，小白可选用开源RAG工具，如LangChain RAG、Chroma等），避免文档过大导致召回不准确。

补充：kbase是内部自建的知识库平台，支持嵌入和通过mcp召回知识，外部开发者可选用开源替代工具，核心逻辑一致，不影响使用。

2. 系统内置字段库

这类知识包括TQL及ICBU扩展的指令、全局函数、服务端领域模型字段。由于GraphQL支持自省，这些信息可通过扫描服务端注解获取，但经过多年迭代，自省内容已达600w+字符，直接导入会导致召回效果差，因此需要先做数据清洗，小白可参考以下清洗步骤：

1. 扫描出全局指令、函数、领域模型的全集，与线上热门脚本进行匹配，只保留高频使用（出现3次以上）的内容，语义相似的内容人工区分，功能相同、语义不同的内容选择性保留；
2. 剔除标注为废弃的内容，避免误导模型；
3. 拆分文档：全局指令、函数各自独立为文档，领域模型适当合并，提升召回精准度。

提醒小白：数据清洗过程比较耗时，需要耐心和细心，可借助AI工具（如Cursor、Claude）编写脚本，辅助完成清洗工作，提升效率。清洗后的内容整理成文档，导入知识库即可。

3. 服务端代码理解库

上述两类知识主要是“结果性知识”，为了让模型从源头理解字段、函数背后的逻辑，服务端源码是重要的补充。我们选用了内部的deepwiki平台（已解析过服务端应用源码，召回效果较好），通过其提供的能力召回代码片段，帮助模型深入理解业务逻辑。

小白可参考：如果没有类似的内部平台，可选用开源的代码检索工具，或直接将服务端核心源码片段整理成文档，导入知识库，核心目的是让模型理解知识的底层逻辑，减少输出错误。

（四）工具接入（小白可直接参考的链路设计）

Agent的工具设计分为两类：本地工具和远程（MCP）工具，小白可根据自身场景，选择合适的工具类型，核心是“满足需求、简化开发”。

1. 远程（MCP）工具

主要用于召回上文提到的知识库内容，我们选用了两个核心远程工具：

• kbase的mcp server：用于召回热门脚本、系统内置字段等知识库内容；
• deepwiki的mcp server：用于召回服务端代码片段。

小白优化技巧：远程工具提供的功能通常比较全面，但我们实际只需要用到其中一部分，因此设计了“白名单机制”，只加载白名单内的工具，减少上下文冗余，保护模型注意力，这也是降低token消耗的关键技巧之一。

补充：MCP工具的鉴权认证，可参考对应平台的官方文档，这里不做赘述，小白可根据工具文档完成配置。

2. 本地工具

本地工具主要用于实现Agent与宿主页面的交互，完成脚本编辑、执行、验证等核心功能，小白可直接参考我们的工具设计，替换成自己的业务逻辑：

• 编辑脚本（editScript）：功能是编辑/更新GraphQL脚本内容；输入为script（字符串，完整的脚本代码）；输出为更新状态（成功/失败）。
• 编辑变量（editVariables）：功能是编辑/更新GraphQL请求变量（mock参数）；输入为variables（字符串，完整的JSON格式变量）；输出为更新状态。
• 执行脚本（executeScript）：空方法，核心作用是引导模型择机执行脚本，实际执行逻辑在前端宿主页面实现。
• 验证结果（validateResult）：功能是验证脚本执行结果；输入包括prompt（验证要求描述）、currentScript（可选，当前脚本）、currentVariables（可选，当前变量），执行结果通过闭包注入；输出为结构化验证结果（包含是否通过、问题总结、优化建议等）。

3. 工具调用链路（小白必懂）

将所有工具注册到Agent后，常规调用链路如下：

小白疑问：服务端的工具调用，如何触发前端UI侧的操作？比如Agent调用“执行脚本”工具时，需要前端页面点击执行按钮，再将结果回传给Agent，这个交互如何实现？

解决方案：通过前后端全双工通信，维护长连接，当Agent调用“执行脚本”等需要前端响应的工具时，服务端不执行具体逻辑，仅等待前端页面完成操作后，将结果传回服务端，再继续Agent的状态流转（这就是LangGraph中的“中断”，也叫HITL人机协同）。

小白坑点：我们使用的Faas基建，默认不支持长连接，函数最长保活时间为300s（默认50s），无法满足长连接需求，这里给大家卖个关子，后续上下文管理部分会讲解如何曲线救国，解决这个问题。

（五）上下文管理（核心难题解决，小白可复用）

当完成上述能力建设后，Agent已经能实现脚本编写、执行、验证等基础功能，但还面临两个核心难题，也是小白自建Agent时最容易卡住的地方：

1. 模型本身不支持连续对话，需要自行实现会话持久化；
2. 上下文窗口容易膨胀，导致模型注意力稀疏、出现幻觉，同时token消耗过高。

我们做过测试，一轮包含工具调用的简单对话，就能消耗近1/4（5w）的token，主要原因是默认设计中，每个节点的返回消息都会拼接到LLM消息列表中，长期积累会导致上下文臃肿。

1. 连续对话实现（小白易上手）

连续对话的实现逻辑非常简单，小白可直接复用：

当用户开始新对话时，生成一个唯一的sessionId，用于存储该会话的消息列表；每次消息列表发生变化（用户输入、Agent响应、工具调用结果），都将其持久化存储（我们用的是tair，小白可选用Redis等缓存工具）；当用户有新输入时，通过sessionId取出历史消息列表，与新输入拼接后发给大模型，即可实现连续对话。

补充：LangGraph提供了checkpoint机制，支持从任意节点重新开始会话，我们的场景暂时用不到，小白可根据自身需求选择是否使用。

2. UI工具调用的巧妙实现（解决Faas长连接问题）

结合Faas不支持长连接的问题，我们设计了一套巧妙的解决方案，小白可直接参考，无需复杂开发：

1. Agent接口采用SSE（服务端向客户端流式推送）方式，服务端收到请求后，流式向前端推送分片消息，同时将每轮消息持久化存储；
2. 当Agent调用需要前端UI响应的工具（如执行脚本）时，将工具调用信息推送给前端后，直接退出LangGraph状态流转，结束此次请求；
3. 前端完成操作（如点击执行按钮、确认脚本修改）后，生成一条“隐藏消息”（如：【脚本执行成功，结果是xxx，请继续处理】），重新调用Agent的SSE接口；
4. Agent接口收到请求后，通过sessionId取出之前持久化的历史消息，拼接上这条隐藏消息，从头开始初始化AgentGraph调用，实现会话的无缝衔接。

用户前台看到的效果：会话连续无中断，Agent能根据前端操作结果继续处理任务；

实际发送给模型的消息：历史消息+隐藏消息，实现状态衔接；

通过这种方式，既解决了Faas不支持长连接的问题，又实现了UI工具与Agent的无缝交互，小白可直接复用这套逻辑，无需额外开发长连接功能。

3. 会话压缩（降低token消耗，小白核心技巧）

解决了连续对话问题后，上下文窗口膨胀、token消耗过高的问题，核心解决方案是“压缩”——只保留关键摘要信息，剔除冗余内容，小白可参考我们的两步压缩策略：

（1）工具响应结果压缩

工具调用结果通常比较冗长，直接放入上下文会消耗大量token，因此我们在Agent内部新增了“工具结果缓存+检索详情”工具（summaryToolResult），核心逻辑如下：

1. 工具调用完成后，将结果缓存起来（避免重复调用消耗token）；
2. 通过summaryToolResult工具，根据用户需求，从缓存结果中精准检索相关内容，只将检索后的关键信息放入消息列表，剔除冗余内容。

小白优化技巧：summaryToolResult工具的核心是“精准检索、结构化输出”，无需使用高端模型，我们选用了更轻量的Qwen模型，既能满足需求，又能节省token成本。同时，为了让输出更结构化、保留关键信息，我们给该工具的提示词也做了XML格式优化（沿用前文提到的提示词技巧）。

summaryToolResult工具提示词（小白可直接复制修改）：

<?xml version=“1.0” encoding=“UTF-8”?> <prompt> <role>你是一个数据提取助手。你的任务是从给定的工具调用结果中，根据用户的查询需求，提取并返回相关的事实信息。</role> <extractionRules> <rule>只返回与查询高度相关的事实信息</rule> <rule>保持信息的准确性，不要编造内容</rule> <rule>如果找不到相关信息，明确说明</rule> </extractionRules> <specialRules> <description>当提取的内容涉及以下类型的功能说明时，必须使用对应的 XML 结构详细输出完整的用法信息：</description> <featureType name=“全局函数”> <xmlTemplate><![CDATA[ <function> <name>函数名称</name> <description>函数功能说明</description> <parameters> <param required=“true/false”> <name>参数名</name> <type>参数类型</type> <default>默认值（如有）</default> <description>参数说明</description> </param> <!– 更多参数… –> </parameters> <returns> <type>返回值类型</type> <description>返回值说明</description> </returns> <example>使用示例代码</example> </function> ]]></xmlTemplate> </featureType> <featureType name=“领域模型字段”> <xmlTemplate><![CDATA[ <field> <name>字段名称</name> <type>字段类型（标量/复合）</type> <description>字段描述</description> <arguments> <arg required=“true/false”> <name>参数名</name> <type>参数类型</type> <default>默认值（如有）</default> <description>参数说明</description> </arg> <!– 更多参数… –> </arguments> <subFields> <subField> <name>子字段名</name> <type>子字段类型</type> <description>子字段说明</description> </subField> <!– 更多子字段… –> </subFields> <example>使用示例代码</example> </field> ]]></xmlTemplate> </featureType> <featureType name=“内置指令”> <xmlTemplate><![CDATA[ <directive> <name>@指令名称</name> <description>指令功能说明</description> <locations> <location>FIELD</location> <location>QUERY</location> <!– 可应用的位置：FIELD, QUERY, FRAGMENT_SPREAD, INLINE_FRAGMENT 等 –> </locations> <arguments> <arg required=“true/false”> <name>参数名</name> <type>参数类型</type> <default>默认值（如有）</default> <description>参数说明</description> </arg> <!– 更多参数… –> </arguments> <notes> <note>注意事项或限制</note> <!– 更多注意事项… –> </notes> <example>使用示例代码</example> </directive> ]]></xmlTemplate> </featureType> <featureType name=“自定义标量类型”> <xmlTemplate><![CDATA[ <scalarType> <name>类型名称</name> <description>类型说明</description> <format>取值范围或格式要求</format> <example>使用示例</example> </scalarType> ]]></xmlTemplate> </featureType> </specialRules> <outputFormat> <rule>涉及功能用法时，必须使用上述对应的 XML 结构输出</rule> <rule>可以在 XML 结构前后添加简要的文字说明</rule> <rule>如果有多个同类型功能，每个功能使用独立的 XML 块</rule> <rule>XML 中的示例代码直接写入 example 标签内</rule> <rule>如果某个字段没有值，可以省略该标签或留空</rule> </outputFormat> <outputHint>如果查询内容不涉及上述特殊功能类型，则按照常规方式简洁输出关键信息，无需使用 XML 格式。</outputHint> </prompt> 

优化后效果：同样的工具调用，主Agent的上下文token占用从5w下降到4k，不足原来的1/10，大幅降低token消耗，同时避免上下文冗余。

（2）上下文整体压缩

即使对工具响应进行了压缩，长期连续对话后，上下文窗口仍可能超限。参考Cursor、Claude Code等产品的实现逻辑，我们引入了“上下文自动压缩”机制，小白可直接复用配置：

核心触发时机：当上下文窗口使用率超过80%时，触发自动压缩（可根据自身模型窗口大小调整阈值）；

优化细节：压缩时保留最近3轮用户对话后的消息列表，避免压缩后模型遗忘近期任务，减少压缩带来的信息损耗（因为上下文压缩是有损的，过度压缩会导致模型失忆）。

提醒小白：上下文压缩需要谨慎，建议参考Claude Code的压缩提示词（可在GitHub上搜索Claude-Code-Reverse获取），避免压缩过度导致Agent功能异常。

线上最终配置（小白可直接复制修改）：

GPT plus 代充 只需 145{ enabled: true, // 启用压缩 dangerThreshold: 80, // 1-100 当上下文窗口使用超过 80% 时触发压缩 keepRecentRounds: 3, // 保留最近 3 轮用户对话开始之后的消息不被压缩 } 

消息压缩图示（清晰展示压缩逻辑）：

到这里，内部研发平台Agent接入的核心工作就全部完成了，通过一周的开发，实现了从基础骨架搭建到功能优化的全流程，解决了连续对话、上下文压缩、工具交互等核心难题，大幅降低了token消耗，Agent能稳定辅助开发者编写、执行、验证TQL脚本。

后续优化方向：采集用户使用过程中的bad case，持续优化系统提示词、工具逻辑和知识库内容，提升Agent的准确性和易用性。

本文内容偏详细，对资深开发者来说可能有部分冗余，但重点面向小白和想要自建Agent的程序员，尽量把每个步骤、每个坑点都讲清楚，建议收藏备用，实际开发时可直接参考复用，少走弯路。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。