1、什么是MCP?和Function call区别是什么?
Function call：是点对点的私有接口适配，让大模型调用本地的工具函数。
MCP：是一个通用协议，开发一次，能被多个模型客户端调用。
在项目中最初使用Function call，但每次换模型(比如：从qwen换到deepseek)都要改prompt格式，所以引入了mcp。
比如：做了一个桌面txt统计工具，通过mcp的ListTools接口，模型可以直接发现list_desktop_txt_files工具。
这种标准化让agent具备了插件能力，用户可以随意安装新的MCP Server，程序无需修改代码即可动态新增工具能力
2、处理多文件或海量文档时，如何解决 Context Window 限制？
1、分级存储策略
将信息按使用场景分层，避免一次性加载所有内容
短期记忆：用内存List维护当前会话上下文，随用随丢，仅保留当前对话的关键信息
长期记忆：引入外部存储(Elasticsearch / 向量库)，将海量文档持久化存储，通过检索按需加载到模型上下文。
2、轻量化无向量库方案(中小规模场景)
针对几百份PDF级别的中小规模知识库，无需复杂向量库即可快速部署
1、用docparser解析文件为纯文本，并缓存hash文件避免重复解析
2、在文件系统层面构建倒排索引，通过BM25算法实现关键词检索，快速定位目标文档片段
3、企业级优化：ES混合检索(BM25 + 向量检索的混合)
单纯向量检索关键词丢失、单纯BM25检索语义不足
1、先用BM25锁定包含关键词的具体条款，实现精确匹配
2、再用向量检索检索补充语义相关的案例
3、最后把相关的少量片段送入LLM
3、你上线前怎么测试Agent?RAG的效果如何量化?
1、测试集定义：构建带标注的测试集，定义明确的Input + Expected Output，覆盖正常、边界和异常场景。
2、自定义评估器：不仅评估最终答案是否正确，更要评估 Agent 的决策路径是否合理。为此，我会基于 LangSmith/LangFuse 搭建自动化测试流水线，实现指标的自动采集与评估。
关键指标之一是自定义的ProcessingMode评估器：比如用户问 "查余额" 这种简单问题，如果 Agent 调用了复杂的 Planner 链路，而非直接走 API 查询，即使答案正确，在测试中也会判定为失败，因为这浪费了 Token 和时间，影响系统整体效率。我要求 Agent 在路由阶段的ProcessingMode准确率达到 95% 以上才允许上线，以此控制Token消耗和系统延迟。
4、你的Agent如何实现自我修复?
设计了一个while循环，当Code Interpreter 返回 Error时，不直接把错误抛给用户，而是把错误信息 + 之前的代码重新喂给LLM，提示它，这段代码报错了，
请分析原因并重写。
设置了max_retries = 3，在测试中80%的Pandas数据类型错误(如字符串转数字失败)，都能通过这种机制自动修复，用户无感知。
5、设计Agent工具时，原子性怎么把可控?
工具不能太万能，也不能太细碎。
1、一个工具只做一件事
2、参数尽量少，最好不要超过3个
3、不要做全能工具
4、LLM调用成功率显著提升
比如：最开始我设计了一个巨大的工具叫analyze_data(file_path)，结果LLM不知道怎么传参数。
后来拆分为原子工具:load_csv()，get_column_names(),calculate_correlation()
这样LLM的调用率显著提高
6、如何降低Agent的Token消耗?
没必要杀鸡用牛刀
采用了模型分级策略
1、意图识别/简单路由：用Qwen-flash(便宜、快)
2、核心推理/代码生成：用Qwen-Max或Qwen-plus(聪明、贵)
3、总结/润色：用小模型
还优化了SystemPrompt，把几页纸的文档精简为Markdown表格，减少了40%的Context的输入成本
7、如果Agent一直在这个任务里死循环了怎么办?
Agent有时会陷入打开网页-->失败-->重试-->失败的死循环。
在架构层加了一个死循环检测器，
每次Agent行动前，我会计算当前Action与过去3次Action的语义相似度，如果3次都在做及其相似的操作且没有
产出新结果，程序会强制打断。
并向Agent发送一条系统提示：你似乎卡住了，请尝试换一种策略，或者直接向用户求助。
if (连续3次动作高度相似) AND (环境状态无变化):
判定为死循环
打断执行
发送提示：你似乎卡住了，请换策略或求助
8、如果Agent响应很慢，你是怎么排查的?
Agent的慢通常有俩块
LLM推理慢：Token多、思考步骤长、模型本身慢
工具执行慢：网络、数据库、爬虫、第三方API
需要查看Trace调用链路。
项目中接入了langfuse进行全链路监控，有一次用户反馈响应要30秒。
我查看Trace发现，LLM思考花了3秒，但是search_tool花了25秒!!!
原因：爬虫卡在了某个网站的重试机制上。
优化：给工具加了timeout=5s的限制，并发调用多个搜索源，避免单点拖慢整体
如果不看Trace，可能会认为模型太慢。
9、Agent思考时间长，怎么优化前段用户体验?
既然不能让模型变快，就让用户觉得没那么慢。
实现了Stream流式输出和透明化思考。
打字机效果：LLM生成一个字，前段显示一个字，不让用户盯着空白，加载圈干等
透明化思考：当Agent在调用工具(如查数据库、搜向量)，前端实时展示状态
可见性缓解用户的等待焦虑，觉得Agent真的在干活，而不是卡死。
本质：把黑盒等待 变成 可见的工作流
10、什么时候应该微调模型，什么时候用RAG?
RAG：解决不知道的问题(缺乏特定数据，实时性数据)，成本低，更新快
缺数据 → 外挂知识库，成本低、易更新。
Fine-tuning：解决学不会、做不好的问题，成本高，更新慢，
格式乱、语气飘、输出不专业、逻辑不规范 → 用微调 "教它怎么写"。
RAG First：优先外挂知识库，不动模型权重
只有当风格、格式、输出范式怎么提示都不达标时，再上微调