Agent

1.任务分解

在遇到复杂问题时输出结果质量差的时候进行任务再分解，来提高输出质量

2.评估
例如：输出结果总是提及竞争对手的内容，添加评估输出标准，对内容进行筛选（通过大模型进行评估）

3.设计模式

　　3.1 reflection 输出结果后对结果再反馈错误给LLM，以提高结果的正确率，类似对话模式　　

      

　　　　3.1.1优点：提高正确率
　　　　3.1.2缺点：更加耗性能和token
　　　　3.1.3使用场景：提高的效率根据不同需求而不同，因此需要需求来使用

　　　　3.1.4评估：在客观情况下使用代码统计分析，在主观的情况下需要设立更多评估标准

　　　　3.1.5外部反馈：能够显著提高正确率，例如遍写匹配到输出的错误情况的代码，调用特定的函数去外部寻找信息，重新输出结果

　　3.2 tool use LLM调用各种工具进行解析->输出结果

    

　　　　3.2.1：LLM实际不直接调用你设定好的tools，而是LLM叫Agent去请求tools，然后反馈给LLM
　　　　3.2.2工具语法：通过工具语法给LLM可以调用哪些工具设定规则，这个规则实际就是Tools 工具 Schema（Function Calling），以下是使用AI suite生成工具语法的例子

    

　　　　3.2.3可以执行代码让LLM有更多可能性

　　　　3.2.4MCP：Model Context Protocol，模型上下文协议

三层核心架构（宿主 Host / 客户端 Client / 服务端 Server）

1. Host（宿主，你的 Agent 程序）

你的 SaaS 代码排查 Agent、Claude 桌面、VSCode 等上层应用，是总协调器：

• • 管理所有 MCP 客户端连接
  • 对接 GLM5.2 等大模型
  • 统一权限管控、安全策略、会话生命周期

2. Client（客户端，内置在 Host 里，在框架中有内置，统一封装）

每个外部服务对应一个独立 Client，负责和远端 MCP Server 建立连接，支持两种传输方式：

• • Stdio：本地进程通信（本地文件、本地代码仓库、本地 CLI 工具）
  • Streamable HTTP/SSE：远程网络服务（观测云、数据库、微服务 Trace 接口）

3. MCP Server（核心工具 / 数据源服务,.py文件）

独立部署的标准化服务，对外暴露三类核心能力（对应你做的代码定位系统）：

1. 1. Tools（工具）：就是你截图里的get_current_time这类 Function 定义，提供可被模型调用的函数（code_search、trace_query、日志查询、Git 读取）
   2. Resources（资源）：静态 / 动态业务上下文数据（SaaS 全量代码、业务流程文档、历史故障库、数据库表结构）
   3. Prompts（提示词模板）：预定义好的业务 Prompt 模板，统一给模型注入角色、约束、少样本案例

 　　　　4.和工具语法function calling的区别

对比维度	OpenAI Function Calling	MCP 模型上下文协议
层级	大模型 API 请求内的参数，耦合模型厂商	独立底层通信协议，和大模型解耦，GLM/Claude/GPT 通用
工具生命周期	每次调用 LLM 都要重复上传 tools 数组，临时生效	MCP Server 持续在线，Agent 动态list_tools()拉取工具列表，不用重复传
部署形态	工具逻辑写死在 Agent 代码内部，新增工具必须改代码重发	工具独立部署为 MCP Server，新增代码 / 日志工具只新增 Server，Agent 零改动
上下文能力	仅支持函数调用，无法统一加载私有代码、文档资源	同时提供工具 + 私有业务数据 + 预制 Prompt 三位一体上下文
跨模型兼容	OpenAI、GLM、Claude 工具格式不统一，需要适配转换	一套 MCP Server，任意支持 MCP 的大模型直接复用
安全隔离	工具执行和 Agent 进程混在一起，权限难管控	Server 独立进程 / 远程部署，可单独做权限、沙箱、访问鉴权

 　　　　5.MCP 核心能力

• • 动态工具发现
    Agent 启动后自动连接 MCP 服务，实时拉取所有可用工具（代码检索、链路查询、单元测试执行），不用硬编码写死 tools JSON。
  • 统一私有上下文供给
    把整套 SaaS 源码、业务流程、Trace 日志、故障案例全部封装为 MCP Resources，模型需要时按需加载超长代码片段，替代简陋的 RAG 手动拼接逻辑。
  • 双向递归 Agent 能力（Sampling）
    MCP Server 可以反过来调用 LLM（子 Agent 递归），比如查询到超长支付链路后，自动发起子推理分析，传统 Function Calling 无法做到服务端主动调用模型。
  • 完整传输与状态管理
    支持进度推送、请求取消、错误标准化、日志回流；2026-07-28 最新规范已从有状态会话改为无状态，大幅提升分布式多 Server 集群部署能力。
  • 预制 Prompt 模板统一管理
    所有代码排查专用 System Prompt、少样本案例托管在 MCP 服务，Agent 无需硬编码 Prompt 文本，可在线更新提示词不用重启系统。

3.3 planning LLM通过规划行动流程->输出结果

3.4 multi-agent collaboration 多个智能体赋予不同的角色功能团队协作完成->输出结果

4.构建智能体AI的实用技巧

　　4.1建立评估集：客观的使用代码去约束修复、主观的使用设定黄金标准去使用LLM-judge

　　　　4.1.1客观：例一个检验发票Agent，存在时间提取准确率低的问题，建立二十张发票为一组的数据集，比对每次提取的发票时间正确率，定位错误根因，通过代码或者prompt对出现的问题进行修复

　　　　工程实现方式

1. 独立 Python 评估脚本，复用生产 Agent 代码，避免线上线下逻辑不一致；
2. 支持批量跑全量测试集、支持单类困难样本定向测试；
3. 支持版本标记：每次迭代 Prompt/Agent 代码 / LLM 微调后，标记版本 v1/v2/v3，留存所有预测结果历史。

　　　　4.1.2主观：例一个写文章的Agetn，存在遗漏观点问题，通过建立黄金标准让LLM-judge进行修复

　　4.2误差分析与确定后续步骤优先级

　　　　例一个通过搜索网上资源的写文章的，找出错误示例，分析每一步的输出结果来判断定位错误在哪里，计算在哪一步的错误概率比较多

          

       

　　4.3组件级评估：进行单组件的评估，直接进行端到端的评估成本较高

　　4.4解决发现的问题

　　　　4.4.1修改prompts，多去读优秀项目的prompt，提高自身prompt的编写

　　　　4.4.2换LLM，LLM可能针对不同的任务效率不同，可以尝试执行同种任务验证LLM对某种任务的执行结果正确率

　　　　4.4.3拆分任务，

　　　　4.4.4关注trace中各个任务

　　　　4.4.5微调大模型，难度偏大，最后再考虑

　　4.5延迟、成本与优化：

　　4.6总结开发流程：https://www.bilibili.com/video/BV1DfrdByE2H?spm_id_from=333.788.videopod.episodes&vd_source=ce8f93194a63c57cca08d7e9eb10d3e5&p=24

 　　

 5.Zero-Shot、few-shot、One-Shot、Many-Shot概念

1. Zero-Shot（零样本）
    
   只给角色指令，不给任何示例，直接让模型输出结果。

例：只写 “你是发票提取专家，输出 JSON”，不给任何发票样例。

 

缺点：复杂票据（红字、差额票）极易字段缺失、格式错乱。

2. Few-Shot（少样本）

    

   在 System Prompt / 用户上下文里，塞入少量人工标注好的真实样例（3~8 条最佳），告诉模型「输入长什么样、正确输出长什么样」。

    

   核心逻辑：不用微调 LoRA，靠上下文示例教会模型业务格式与领域规则，纯 Agent 层优化，无额外云费用，完美适配你云端调用 GLM 的架构。
3. One-Shot（单样本）：只给 1 条示例
4. Many-Shot（多样本）：十几条以上，容易触发上下文超长、token 成本上涨、推理变慢