1. 从热搜词里读出的技术风向把大模型、Agent、llama.cpp、MCP、SSRF这五个词摆在一起再对照那一长串热搜词能明显感觉到一个信号2026年这个时间点上行业关注的重心已经从模型能不能跑起来转移到了模型怎么被安全地接进真实系统里。前两年大家聊的是参数量、显存、量化等级现在聊的是Agent框架怎么选、MCP协议怎么接、本地部署用哪个模型最划算以及一个绕不开的话题——当大模型开始调用外部工具、访问网络资源时SSRF这类传统Web安全漏洞会以全新的形态冒出来。这篇日报式的梳理我打算按从业者的实际关注点来组织而不是按新闻时间线罗列。核心围绕四块本地部署与微调的工程实践、Agent开发与框架选型、MCP协议的落地细节、以及大模型时代SSRF漏洞的攻防变化。每一块都会给出可操作的配置思路和踩坑经验适合正在做本地部署、Agent开发或者安全测试的读者参考。先说清楚一个前提这些内容是基于当前社区讨论热度和常见实践整理的具体版本号和参数会随时间变化但底层的选型逻辑和排查思路是相对稳定的。你在实际操作时务必以自己环境的实测结果为准。2. 本地部署与微调从显卡选型到量化落地2.1 为什么哪个模型最佳这个问题本身就问错了热搜里有个高频问题ollama本地部署大模型哪个模型最佳。这个问题每天都能在各种群里看到但说实话它没有标准答案因为最佳取决于三个变量你的硬件、你的任务类型、你能接受的延迟。我见过太多人一上来就问推荐模型结果装完发现自己的显卡根本带不动或者跑起来了但推理速度慢到没法用。正确的顺序应该是先摸清硬件底牌再倒推模型规格。以热搜里提到的RX 6750 GRE为例这张卡12GB显存属于中端偏上的消费级显卡。在这个显存条件下7B到8B参数的模型用4-bit量化Q4_K_M是比较舒服的区间能留出足够的上下文空间。如果想上14B就得接受更激进的量化Q3或更低质量损失会比较明显。至于32B以上的模型除非用CPUGPU混合推理并且不介意速度否则不建议在这张卡上尝试。这里有个容易被忽略的点显存占用不只是模型权重。上下文长度context length对显存的消耗是线性的8K上下文和32K上下文的KV Cache差距可能是好几个GB。很多人算显存时只算了模型大小结果一开长上下文就OOM。我的经验是在模型权重占用之外至少预留2到4GB给KV Cache和运行时开销。2.2 llama.cpp的量化选择Q4_K_M为什么是默认答案llama.cpp作为本地推理的老牌工具它的量化体系是绕不开的知识点。热搜里虽然没直接问量化但ai大模型本地部署配置这个需求背后量化选择是第一步。简单说量化就是把模型权重从16位浮点压缩到更低位宽用精度换显存和速度。llama.cpp支持从Q2到Q8的各种量化等级还有K-quants和I-quants等不同方案。社区里最常推荐的默认值是Q4_K_M原因很实际Q4_K_M在4-bit量化的基础上对部分关键层用了更高的精度这就是K的含义质量损失相对可控相比Q5它省下的显存能让你多开几千token的上下文相比Q3它的输出质量明显更稳定尤其在代码和逻辑推理任务上我做过一组对比测试同一个7B模型在Q4_K_M和Q5_K_M下日常问答和代码补全的差异很小但在需要多步推理的任务上Q5的稳定性确实更好。所以如果你的显存够Q5_K_M是更稳妥的选择如果显存紧张Q4_K_M是性价比最高的平衡点。至于I-quantsIQ系列它在同等位宽下质量更好但推理速度会慢一些因为需要更多的反量化计算。在CPU推理场景下这个差异比较明显GPU场景下影响相对小。2.3 微调实战qwen2.5-7b微调行业模型的完整链路热搜里qwen2.5-7b微调行业大模型和环境配置模型微调模型部署效果展示详细教程这两个词放在一起说明大家要的是一条龙方案。我把这条链路拆成几个关键决策点来讲。环境配置阶段最容易踩的坑是CUDA版本和PyTorch版本的匹配。很多人直接pip install最新版结果和显卡驱动对不上。我的建议是先确认驱动支持的CUDA版本上限然后装对应版本的PyTorch。用conda管理环境比pip更省心因为conda能帮你处理CUDA toolkit的依赖。微调方法选择上7B模型全量微调需要大量显存单卡基本不现实。LoRA和QLoRA是主流选择。LoRA在原始权重旁挂低秩矩阵训练参数量降到原来的百分之几QLoRA在此基础上把基座模型也量化了进一步降低显存需求。对于行业模型微调QLoRA通常够用除非你的数据量特别大、任务特别复杂。数据准备是最耗时的环节也是最容易被低估的。行业模型微调的数据质量比数量重要得多。我见过用几千条高质量问答就调出可用效果的也见过用几万条脏数据把模型带偏的。数据格式上Alpaca格式和ShareGPT格式是两种主流前者适合单轮指令后者适合多轮对话。清洗数据时重点检查指令是否明确、回答是否准确、有没有重复和矛盾样本。效果评估不能只看loss曲线。loss下降不代表模型变好了可能只是过拟合了。必须准备一个独立的验证集人工评估生成质量。我通常会用三类指标任务准确率针对具体任务、格式合规率输出是否符合预期结构、以及人工打分流畅度、相关性、准确性。2.4 部署环节的显存与并发权衡模型微调完部署上线又是另一套逻辑。热搜里大模型部署和android app集成ai大模型gguf说明部署场景很分散从服务器到移动端都有。服务器部署常用vLLM或TGI这类推理框架它们支持连续批处理continuous batching能显著提升并发吞吐。但代价是显存占用更高因为要同时维护多个请求的KV Cache。如果你的场景是低并发高延迟容忍直接用llama.cpp的server模式反而更省资源。移动端集成GGUF格式模型是这两年的新趋势。GGUF是llama.cpp推出的模型格式专门为端侧推理优化。在Android上跑7B模型即使是Q4量化也需要至少4GB可用内存而且推理速度受限于手机芯片。实际体验上3B以下的模型在手机上更实用7B更适合旗舰机型且要做好发热和耗电的心理准备。提示端侧部署时模型文件建议放在应用私有目录避免被其他应用读取。同时注意GGUF文件的完整性校验损坏的模型文件会导致推理崩溃且难以排查。3. Agent开发框架选型与能力边界3.1 Agent、Skill、Harness三个容易混淆的概念热搜里harness和agent区别、skill和agent的区别这两个问题出现频率很高说明概念混淆是普遍现象。我用一个类比来讲清楚。把Agent想象成一个员工。Agent本身是这个员工能自主决策、调用工具、完成多步任务的整体能力。Skill是这个员工掌握的具体技能比如会用Excel、会写SQL。Harness则是管理这个员工的工作流程和约束比如规定他每步要汇报、出错要重试、不能越权操作。技术上讲Agent是一个循环观察环境、思考决策、执行动作、再观察结果。Skill是Agent可以调用的具体能力单元通常封装成一个函数或工具。Harness是包裹在Agent外面的控制层负责编排、监控、错误处理和边界限制。理解这个区别很重要因为它决定了你的开发重心。如果你要做的是让模型能查天气那是一个Skill如果你要做的是让模型自主规划一次旅行并预订所有环节那需要Agent加Harness。3.2 Agent框架选型从LangChain到更轻量的方案热搜里agent框架和agent开发学习路线说明很多人在入门阶段。当前Agent框架大致分几类重框架型LangChain、LlamaIndex这类生态丰富、组件齐全但抽象层多调试困难版本迭代快导致文档经常对不上轻量编排型AutoGen、CrewAI这类专注多Agent协作概念清晰但灵活性受限底层可控型直接基于模型API自己写循环用最少的依赖实现Agent逻辑我的建议是学习阶段可以用LangChain快速理解概念但真正做项目时如果需求不是特别复杂自己写Agent循环反而更可控。因为框架的抽象会在你排查问题时变成障碍你不知道到底是模型的问题还是框架的问题。一个最小可用的Agent循环大概长这样import json def agent_loop(task, tools, model_client, max_steps10): messages [{role: user, content: task}] for step in range(max_steps): response model_client.chat(messages, toolstools) if response.tool_calls: for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append({role: tool, content: result}) else: return response.content return 达到最大步数限制这段代码没有依赖任何框架但包含了Agent的核心循环、工具调用、结果回填。你可以在此基础上加错误重试、日志、权限控制逐步演化成生产级方案。3.3 Agent Evals怎么知道你的Agent到底行不行热搜里agent evals是个很关键但容易被忽视的话题。Agent和普通模型调用最大的区别是它的输出不是一段文本而是一系列动作和最终结果。所以评估Agent不能只看最终答案对不对还要看过程是否合理。我常用的评估维度有四个维度说明评估方式任务完成率最终是否达成目标自动化断言或人工判定步骤效率用了多少步完成统计平均步数对比基线工具调用准确率是否选对工具、传对参数日志分析错误恢复能力遇到失败能否自我纠正注入故障测试其中错误恢复能力最能体现Agent的成熟度。一个健壮的Agent在工具调用失败时应该能分析错误原因、调整策略、重试或换方案而不是直接崩溃或陷入死循环。测试时可以故意让某个工具返回错误观察Agent的反应。3.4 多Agent协作的坑什么时候不该用多Agent热搜里agent项目和agent开发热度很高很多人一上来就想做多Agent系统。但我的经验是大部分场景单Agent加多个工具就够了多Agent反而会引入通信开销和协调复杂度。多Agent适合的场景是任务可以明确分解成多个独立子任务且子任务之间需要不同的人格设定或知识背景。比如一个Agent负责写代码一个负责审查一个负责测试。如果只是任务步骤多单Agent按顺序执行更简单可靠。多Agent最大的坑是无限对话。两个Agent互相回复谁也说服不了谁token烧完了任务没进展。解决办法是设置最大轮次限制以及一个明确的终止条件。另外Agent之间的消息传递要结构化不要用自然语言闲聊否则信息损耗很大。4. MCP协议从概念到实际接入4.1 MCP到底是什么为什么突然火了热搜里mcp是什么、mcp协议、mcp server、mcp开发一连串词说明MCP是当前最热的技术话题之一。MCP全称Model Context Protocol是一个让大模型应用与外部数据源、工具之间标准化通信的协议。用生活化的类比在没有MCP之前每个大模型应用要接一个工具都得自己写一套对接代码就像每个电器都有自己的充电接口。MCP相当于统一了接口标准变成了USB-C。工具提供方实现一次MCP Server所有支持MCP的客户端都能直接用。这个价值在于解耦。以前你换一个模型或换一个Agent框架所有工具对接都要重写。有了MCP工具层和模型层可以独立演进。这也是为什么figma mcp、playwright mcp、blender mcp这些具体工具的MCP实现会集中出现——大家都在抢着把自己的能力标准化输出。4.2 MCP Server的开发要点热搜里mcp开发 workbuddy和mcp server说明有人想自己开发MCP Server。开发一个MCP Server核心是实现协议定义的几个能力Resources资源类似文件或数据、Tools可调用的函数、Prompts预设提示模板。技术栈上官方提供了Python和TypeScript的SDK。Python SDK适合快速原型TypeScript SDK在类型安全上更好。一个最小的MCP Server大概包含声明工具列表、实现工具调用处理、启动stdio或SSE传输层。传输层选择是个关键决策。stdio适合本地进程间通信简单可靠但只能本机用。SSEServer-Sent Events适合远程访问但需要处理网络和安全问题。如果你只是本地开发调试stdio就够了如果要给团队共享SSE更方便但必须加认证。注意MCP Server如果暴露了文件系统访问或命令执行能力一定要做严格的权限校验。一个没有限制的MCP Server等于把系统控制权交给了模型这是极其危险的。4.3 具体工具接入figma mcp、playwright mcp、blender mcp的实践差异热搜里出现了好几个具体工具的MCP接入需求我挑几个有代表性的讲。figma mcp主要用于设计稿到代码的转换。接入后模型可以读取Figma文件的结构、样式、组件信息然后生成对应的前端代码。实际使用中效果取决于设计稿的规范程度。如果设计师用了大量自定义样式和非常规布局生成的代码质量会下降。建议在使用前先整理设计稿用标准的Auto Layout和组件。playwright mcp让模型能控制浏览器做自动化测试或网页操作。这个能力很强但风险也高。模型可以点击、输入、导航如果目标网站有敏感操作可能造成误操作。使用时建议限制在测试环境并且对可访问的域名做白名单。blender mcp是3D建模领域的应用模型可以通过MCP控制Blender执行建模操作。这个场景比较垂直但对3D工作者来说能大幅提升效率。需要注意的是Blender的Python API很庞大MCP Server封装哪些能力、怎么封装直接决定了可用性。4.4 codex联动burp mcp安全测试的新玩法热搜里codex联动burp mcp这个组合很有意思。Burp Suite是Web安全测试的常用工具通过MCP把它接入模型可以让模型辅助分析流量、生成测试用例、甚至自动化的漏洞探测。这个玩法的价值在于模型可以理解HTTP请求的语义而Burp负责实际的抓包和重放。模型看到请求后可以判断哪些参数可能存在问题然后通过MCP让Burp发送修改后的请求再分析响应。这比纯手工测试效率高很多。但这里有个重要的边界自动化漏洞探测必须在你拥有授权的目标上进行。未经授权的测试是违法的这个红线不能碰。另外模型生成的测试用例可能有误报和漏报最终判断还是要靠人。5. SSRF漏洞在大模型时代的攻防变化5.1 SSRF的本质为什么它经久不衰热搜里ssrf、ssrf漏洞、ssrf漏洞利用实战、ctfshow ssrf打redis、ctfhub ssrf这一串词说明SSRF依然是安全领域的热门话题。SSRF全称Server-Side Request Forgery服务端请求伪造本质是攻击者诱导服务器向攻击者指定的地址发起请求。为什么SSRF经久不衰因为它的成因太普遍了。任何接受URL参数并去请求的功能都可能存在SSRF。图片加载、Webhook、文件导入、API代理这些功能在Web应用里到处都是。而且SSRF的利用链可以很深从探测内网到打Redis、打云元数据服务危害极大。传统SSRF的防御手段主要是白名单、协议限制、内网地址过滤。但这些手段在大模型场景下遇到了新挑战。5.2 大模型如何放大了SSRF的攻击面大模型接入外部工具后SSRF的攻击面被显著放大了。原因有三第一模型可以自主构造请求。以前SSRF需要攻击者手动构造URL现在模型在Agent循环中可能根据任务需要自动生成URL去请求。如果模型被诱导它可能主动去访问恶意地址。第二MCP Server成了新的SSRF入口。一个提供网页抓取能力的MCP Server如果不对目标地址做限制模型就可以让它去请求内网地址。而且MCP Server通常运行在服务器上权限比普通Web应用更高。第三模型的判断力不可靠。你告诉模型不要访问内网地址它可能在大多数情况下遵守但通过精心构造的提示词可以绕过这个限制。安全边界不能依赖模型的自觉。5.3 实战排查一个SSRF漏洞的完整发现链路假设你在测试一个集成了大模型的应用它有一个智能摘要功能可以输入URL让模型抓取网页内容并总结。排查思路如下第一步确认请求行为。输入一个外部URL用抓包工具观察服务器是否真的去请求了这个地址。如果服务器返回了网页内容说明存在服务端请求。第二步测试协议和地址限制。尝试输入file:///etc/passwd看是否能读取本地文件。尝试输入内网地址如http://127.0.0.1:6379看是否被拦截。尝试用十进制IP、八进制IP、DNS重绑定等绕过手段。第三步探测内网服务。如果基础SSRF成立可以扫描内网端口。常见目标是Redis6379、MySQL3306、以及云环境的元数据地址。CTF中ssrf打redis就是利用SSRF让服务器连接Redis通过Redis的协议特性写入文件或执行命令。第四步构造利用链。单纯的SSRF可能只能探测要造成实际危害需要结合其他漏洞。比如SSRF加Redis未授权可以写WebShellSSRF加云元数据可以获取临时凭证。5.4 防御SSRF在大模型场景下要加哪些措施针对大模型场景的SSRF防御我总结了几条实操建议网络层隔离MCP Server和模型执行环境放在独立的网络分区限制其能访问的地址范围。这是最有效的手段即使应用层被绕过网络层也能兜底。URL白名单对于必须访问外部地址的功能维护明确的白名单而不是黑名单。黑名单永远有绕过方法。协议限制只允许http和https禁止file、gopher、dict等危险协议。DNS解析后校验不要只校验URL字符串要在DNS解析后校验实际IP防止DNS重绑定。禁止跟随重定向或者对重定向的每一跳都做校验防止通过重定向绕过。模型输出审查对模型生成的URL做二次校验不要直接信任模型的输出。提示SSRF防御的核心原则是默认拒绝。任何未明确允许的地址都应该被拦截而不是试图枚举所有危险地址。6. 把这些串起来一个从业者的日常视角把上面这些内容串起来看会发现它们不是孤立的技术点而是一条完整的链路。本地部署和微调解决的是模型从哪来的问题Agent开发解决的是模型怎么干活的问题MCP解决的是模型怎么接工具的问题SSRF防御解决的是接工具之后怎么不出事的问题。我自己的实践体会是这条链路上最容易出问题的环节往往不是技术最复杂的部分而是边界最模糊的部分。比如MCP Server的权限设计很多人开发时只想着功能实现没想过模型可能被诱导去调用危险能力。再比如Agent的错误处理很多人只测正常流程没测工具失败时Agent会不会陷入死循环。另一个体会是工具选型不要追新。llama.cpp、LangChain这些工具之所以流行是因为它们经过了大量实际场景的检验。新出的框架可能概念更先进但坑也多。除非你有明确的理由否则用成熟方案能省下大量排查时间。最后说一个具体的技巧在做Agent开发时一定要加详细的日志。记录每一步的输入、输出、工具调用、耗时。因为Agent的行为是概率性的同一个输入可能走出不同的路径。没有日志你根本无法复现问题。我习惯把日志按会话ID分组这样排查时能完整还原一次交互的全过程。这个领域变化很快今天的最佳实践明天可能就被推翻。但底层的工程原则——隔离、校验、日志、边界控制——是不会变的。把这些原则吃透比追任何一个具体工具都重要。 大模型本地部署、Agent开发与MCP协议落地：SSRF安全攻防实战指南
1. 从热搜词里读出的技术风向把大模型、Agent、llama.cpp、MCP、SSRF这五个词摆在一起再对照那一长串热搜词能明显感觉到一个信号2026年这个时间点上行业关注的重心已经从模型能不能跑起来转移到了模型怎么被安全地接进真实系统里。前两年大家聊的是参数量、显存、量化等级现在聊的是Agent框架怎么选、MCP协议怎么接、本地部署用哪个模型最划算以及一个绕不开的话题——当大模型开始调用外部工具、访问网络资源时SSRF这类传统Web安全漏洞会以全新的形态冒出来。这篇日报式的梳理我打算按从业者的实际关注点来组织而不是按新闻时间线罗列。核心围绕四块本地部署与微调的工程实践、Agent开发与框架选型、MCP协议的落地细节、以及大模型时代SSRF漏洞的攻防变化。每一块都会给出可操作的配置思路和踩坑经验适合正在做本地部署、Agent开发或者安全测试的读者参考。先说清楚一个前提这些内容是基于当前社区讨论热度和常见实践整理的具体版本号和参数会随时间变化但底层的选型逻辑和排查思路是相对稳定的。你在实际操作时务必以自己环境的实测结果为准。2. 本地部署与微调从显卡选型到量化落地2.1 为什么哪个模型最佳这个问题本身就问错了热搜里有个高频问题ollama本地部署大模型哪个模型最佳。这个问题每天都能在各种群里看到但说实话它没有标准答案因为最佳取决于三个变量你的硬件、你的任务类型、你能接受的延迟。我见过太多人一上来就问推荐模型结果装完发现自己的显卡根本带不动或者跑起来了但推理速度慢到没法用。正确的顺序应该是先摸清硬件底牌再倒推模型规格。以热搜里提到的RX 6750 GRE为例这张卡12GB显存属于中端偏上的消费级显卡。在这个显存条件下7B到8B参数的模型用4-bit量化Q4_K_M是比较舒服的区间能留出足够的上下文空间。如果想上14B就得接受更激进的量化Q3或更低质量损失会比较明显。至于32B以上的模型除非用CPUGPU混合推理并且不介意速度否则不建议在这张卡上尝试。这里有个容易被忽略的点显存占用不只是模型权重。上下文长度context length对显存的消耗是线性的8K上下文和32K上下文的KV Cache差距可能是好几个GB。很多人算显存时只算了模型大小结果一开长上下文就OOM。我的经验是在模型权重占用之外至少预留2到4GB给KV Cache和运行时开销。2.2 llama.cpp的量化选择Q4_K_M为什么是默认答案llama.cpp作为本地推理的老牌工具它的量化体系是绕不开的知识点。热搜里虽然没直接问量化但ai大模型本地部署配置这个需求背后量化选择是第一步。简单说量化就是把模型权重从16位浮点压缩到更低位宽用精度换显存和速度。llama.cpp支持从Q2到Q8的各种量化等级还有K-quants和I-quants等不同方案。社区里最常推荐的默认值是Q4_K_M原因很实际Q4_K_M在4-bit量化的基础上对部分关键层用了更高的精度这就是K的含义质量损失相对可控相比Q5它省下的显存能让你多开几千token的上下文相比Q3它的输出质量明显更稳定尤其在代码和逻辑推理任务上我做过一组对比测试同一个7B模型在Q4_K_M和Q5_K_M下日常问答和代码补全的差异很小但在需要多步推理的任务上Q5的稳定性确实更好。所以如果你的显存够Q5_K_M是更稳妥的选择如果显存紧张Q4_K_M是性价比最高的平衡点。至于I-quantsIQ系列它在同等位宽下质量更好但推理速度会慢一些因为需要更多的反量化计算。在CPU推理场景下这个差异比较明显GPU场景下影响相对小。2.3 微调实战qwen2.5-7b微调行业模型的完整链路热搜里qwen2.5-7b微调行业大模型和环境配置模型微调模型部署效果展示详细教程这两个词放在一起说明大家要的是一条龙方案。我把这条链路拆成几个关键决策点来讲。环境配置阶段最容易踩的坑是CUDA版本和PyTorch版本的匹配。很多人直接pip install最新版结果和显卡驱动对不上。我的建议是先确认驱动支持的CUDA版本上限然后装对应版本的PyTorch。用conda管理环境比pip更省心因为conda能帮你处理CUDA toolkit的依赖。微调方法选择上7B模型全量微调需要大量显存单卡基本不现实。LoRA和QLoRA是主流选择。LoRA在原始权重旁挂低秩矩阵训练参数量降到原来的百分之几QLoRA在此基础上把基座模型也量化了进一步降低显存需求。对于行业模型微调QLoRA通常够用除非你的数据量特别大、任务特别复杂。数据准备是最耗时的环节也是最容易被低估的。行业模型微调的数据质量比数量重要得多。我见过用几千条高质量问答就调出可用效果的也见过用几万条脏数据把模型带偏的。数据格式上Alpaca格式和ShareGPT格式是两种主流前者适合单轮指令后者适合多轮对话。清洗数据时重点检查指令是否明确、回答是否准确、有没有重复和矛盾样本。效果评估不能只看loss曲线。loss下降不代表模型变好了可能只是过拟合了。必须准备一个独立的验证集人工评估生成质量。我通常会用三类指标任务准确率针对具体任务、格式合规率输出是否符合预期结构、以及人工打分流畅度、相关性、准确性。2.4 部署环节的显存与并发权衡模型微调完部署上线又是另一套逻辑。热搜里大模型部署和android app集成ai大模型gguf说明部署场景很分散从服务器到移动端都有。服务器部署常用vLLM或TGI这类推理框架它们支持连续批处理continuous batching能显著提升并发吞吐。但代价是显存占用更高因为要同时维护多个请求的KV Cache。如果你的场景是低并发高延迟容忍直接用llama.cpp的server模式反而更省资源。移动端集成GGUF格式模型是这两年的新趋势。GGUF是llama.cpp推出的模型格式专门为端侧推理优化。在Android上跑7B模型即使是Q4量化也需要至少4GB可用内存而且推理速度受限于手机芯片。实际体验上3B以下的模型在手机上更实用7B更适合旗舰机型且要做好发热和耗电的心理准备。提示端侧部署时模型文件建议放在应用私有目录避免被其他应用读取。同时注意GGUF文件的完整性校验损坏的模型文件会导致推理崩溃且难以排查。3. Agent开发框架选型与能力边界3.1 Agent、Skill、Harness三个容易混淆的概念热搜里harness和agent区别、skill和agent的区别这两个问题出现频率很高说明概念混淆是普遍现象。我用一个类比来讲清楚。把Agent想象成一个员工。Agent本身是这个员工能自主决策、调用工具、完成多步任务的整体能力。Skill是这个员工掌握的具体技能比如会用Excel、会写SQL。Harness则是管理这个员工的工作流程和约束比如规定他每步要汇报、出错要重试、不能越权操作。技术上讲Agent是一个循环观察环境、思考决策、执行动作、再观察结果。Skill是Agent可以调用的具体能力单元通常封装成一个函数或工具。Harness是包裹在Agent外面的控制层负责编排、监控、错误处理和边界限制。理解这个区别很重要因为它决定了你的开发重心。如果你要做的是让模型能查天气那是一个Skill如果你要做的是让模型自主规划一次旅行并预订所有环节那需要Agent加Harness。3.2 Agent框架选型从LangChain到更轻量的方案热搜里agent框架和agent开发学习路线说明很多人在入门阶段。当前Agent框架大致分几类重框架型LangChain、LlamaIndex这类生态丰富、组件齐全但抽象层多调试困难版本迭代快导致文档经常对不上轻量编排型AutoGen、CrewAI这类专注多Agent协作概念清晰但灵活性受限底层可控型直接基于模型API自己写循环用最少的依赖实现Agent逻辑我的建议是学习阶段可以用LangChain快速理解概念但真正做项目时如果需求不是特别复杂自己写Agent循环反而更可控。因为框架的抽象会在你排查问题时变成障碍你不知道到底是模型的问题还是框架的问题。一个最小可用的Agent循环大概长这样import json def agent_loop(task, tools, model_client, max_steps10): messages [{role: user, content: task}] for step in range(max_steps): response model_client.chat(messages, toolstools) if response.tool_calls: for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append({role: tool, content: result}) else: return response.content return 达到最大步数限制这段代码没有依赖任何框架但包含了Agent的核心循环、工具调用、结果回填。你可以在此基础上加错误重试、日志、权限控制逐步演化成生产级方案。3.3 Agent Evals怎么知道你的Agent到底行不行热搜里agent evals是个很关键但容易被忽视的话题。Agent和普通模型调用最大的区别是它的输出不是一段文本而是一系列动作和最终结果。所以评估Agent不能只看最终答案对不对还要看过程是否合理。我常用的评估维度有四个维度说明评估方式任务完成率最终是否达成目标自动化断言或人工判定步骤效率用了多少步完成统计平均步数对比基线工具调用准确率是否选对工具、传对参数日志分析错误恢复能力遇到失败能否自我纠正注入故障测试其中错误恢复能力最能体现Agent的成熟度。一个健壮的Agent在工具调用失败时应该能分析错误原因、调整策略、重试或换方案而不是直接崩溃或陷入死循环。测试时可以故意让某个工具返回错误观察Agent的反应。3.4 多Agent协作的坑什么时候不该用多Agent热搜里agent项目和agent开发热度很高很多人一上来就想做多Agent系统。但我的经验是大部分场景单Agent加多个工具就够了多Agent反而会引入通信开销和协调复杂度。多Agent适合的场景是任务可以明确分解成多个独立子任务且子任务之间需要不同的人格设定或知识背景。比如一个Agent负责写代码一个负责审查一个负责测试。如果只是任务步骤多单Agent按顺序执行更简单可靠。多Agent最大的坑是无限对话。两个Agent互相回复谁也说服不了谁token烧完了任务没进展。解决办法是设置最大轮次限制以及一个明确的终止条件。另外Agent之间的消息传递要结构化不要用自然语言闲聊否则信息损耗很大。4. MCP协议从概念到实际接入4.1 MCP到底是什么为什么突然火了热搜里mcp是什么、mcp协议、mcp server、mcp开发一连串词说明MCP是当前最热的技术话题之一。MCP全称Model Context Protocol是一个让大模型应用与外部数据源、工具之间标准化通信的协议。用生活化的类比在没有MCP之前每个大模型应用要接一个工具都得自己写一套对接代码就像每个电器都有自己的充电接口。MCP相当于统一了接口标准变成了USB-C。工具提供方实现一次MCP Server所有支持MCP的客户端都能直接用。这个价值在于解耦。以前你换一个模型或换一个Agent框架所有工具对接都要重写。有了MCP工具层和模型层可以独立演进。这也是为什么figma mcp、playwright mcp、blender mcp这些具体工具的MCP实现会集中出现——大家都在抢着把自己的能力标准化输出。4.2 MCP Server的开发要点热搜里mcp开发 workbuddy和mcp server说明有人想自己开发MCP Server。开发一个MCP Server核心是实现协议定义的几个能力Resources资源类似文件或数据、Tools可调用的函数、Prompts预设提示模板。技术栈上官方提供了Python和TypeScript的SDK。Python SDK适合快速原型TypeScript SDK在类型安全上更好。一个最小的MCP Server大概包含声明工具列表、实现工具调用处理、启动stdio或SSE传输层。传输层选择是个关键决策。stdio适合本地进程间通信简单可靠但只能本机用。SSEServer-Sent Events适合远程访问但需要处理网络和安全问题。如果你只是本地开发调试stdio就够了如果要给团队共享SSE更方便但必须加认证。注意MCP Server如果暴露了文件系统访问或命令执行能力一定要做严格的权限校验。一个没有限制的MCP Server等于把系统控制权交给了模型这是极其危险的。4.3 具体工具接入figma mcp、playwright mcp、blender mcp的实践差异热搜里出现了好几个具体工具的MCP接入需求我挑几个有代表性的讲。figma mcp主要用于设计稿到代码的转换。接入后模型可以读取Figma文件的结构、样式、组件信息然后生成对应的前端代码。实际使用中效果取决于设计稿的规范程度。如果设计师用了大量自定义样式和非常规布局生成的代码质量会下降。建议在使用前先整理设计稿用标准的Auto Layout和组件。playwright mcp让模型能控制浏览器做自动化测试或网页操作。这个能力很强但风险也高。模型可以点击、输入、导航如果目标网站有敏感操作可能造成误操作。使用时建议限制在测试环境并且对可访问的域名做白名单。blender mcp是3D建模领域的应用模型可以通过MCP控制Blender执行建模操作。这个场景比较垂直但对3D工作者来说能大幅提升效率。需要注意的是Blender的Python API很庞大MCP Server封装哪些能力、怎么封装直接决定了可用性。4.4 codex联动burp mcp安全测试的新玩法热搜里codex联动burp mcp这个组合很有意思。Burp Suite是Web安全测试的常用工具通过MCP把它接入模型可以让模型辅助分析流量、生成测试用例、甚至自动化的漏洞探测。这个玩法的价值在于模型可以理解HTTP请求的语义而Burp负责实际的抓包和重放。模型看到请求后可以判断哪些参数可能存在问题然后通过MCP让Burp发送修改后的请求再分析响应。这比纯手工测试效率高很多。但这里有个重要的边界自动化漏洞探测必须在你拥有授权的目标上进行。未经授权的测试是违法的这个红线不能碰。另外模型生成的测试用例可能有误报和漏报最终判断还是要靠人。5. SSRF漏洞在大模型时代的攻防变化5.1 SSRF的本质为什么它经久不衰热搜里ssrf、ssrf漏洞、ssrf漏洞利用实战、ctfshow ssrf打redis、ctfhub ssrf这一串词说明SSRF依然是安全领域的热门话题。SSRF全称Server-Side Request Forgery服务端请求伪造本质是攻击者诱导服务器向攻击者指定的地址发起请求。为什么SSRF经久不衰因为它的成因太普遍了。任何接受URL参数并去请求的功能都可能存在SSRF。图片加载、Webhook、文件导入、API代理这些功能在Web应用里到处都是。而且SSRF的利用链可以很深从探测内网到打Redis、打云元数据服务危害极大。传统SSRF的防御手段主要是白名单、协议限制、内网地址过滤。但这些手段在大模型场景下遇到了新挑战。5.2 大模型如何放大了SSRF的攻击面大模型接入外部工具后SSRF的攻击面被显著放大了。原因有三第一模型可以自主构造请求。以前SSRF需要攻击者手动构造URL现在模型在Agent循环中可能根据任务需要自动生成URL去请求。如果模型被诱导它可能主动去访问恶意地址。第二MCP Server成了新的SSRF入口。一个提供网页抓取能力的MCP Server如果不对目标地址做限制模型就可以让它去请求内网地址。而且MCP Server通常运行在服务器上权限比普通Web应用更高。第三模型的判断力不可靠。你告诉模型不要访问内网地址它可能在大多数情况下遵守但通过精心构造的提示词可以绕过这个限制。安全边界不能依赖模型的自觉。5.3 实战排查一个SSRF漏洞的完整发现链路假设你在测试一个集成了大模型的应用它有一个智能摘要功能可以输入URL让模型抓取网页内容并总结。排查思路如下第一步确认请求行为。输入一个外部URL用抓包工具观察服务器是否真的去请求了这个地址。如果服务器返回了网页内容说明存在服务端请求。第二步测试协议和地址限制。尝试输入file:///etc/passwd看是否能读取本地文件。尝试输入内网地址如http://127.0.0.1:6379看是否被拦截。尝试用十进制IP、八进制IP、DNS重绑定等绕过手段。第三步探测内网服务。如果基础SSRF成立可以扫描内网端口。常见目标是Redis6379、MySQL3306、以及云环境的元数据地址。CTF中ssrf打redis就是利用SSRF让服务器连接Redis通过Redis的协议特性写入文件或执行命令。第四步构造利用链。单纯的SSRF可能只能探测要造成实际危害需要结合其他漏洞。比如SSRF加Redis未授权可以写WebShellSSRF加云元数据可以获取临时凭证。5.4 防御SSRF在大模型场景下要加哪些措施针对大模型场景的SSRF防御我总结了几条实操建议网络层隔离MCP Server和模型执行环境放在独立的网络分区限制其能访问的地址范围。这是最有效的手段即使应用层被绕过网络层也能兜底。URL白名单对于必须访问外部地址的功能维护明确的白名单而不是黑名单。黑名单永远有绕过方法。协议限制只允许http和https禁止file、gopher、dict等危险协议。DNS解析后校验不要只校验URL字符串要在DNS解析后校验实际IP防止DNS重绑定。禁止跟随重定向或者对重定向的每一跳都做校验防止通过重定向绕过。模型输出审查对模型生成的URL做二次校验不要直接信任模型的输出。提示SSRF防御的核心原则是默认拒绝。任何未明确允许的地址都应该被拦截而不是试图枚举所有危险地址。6. 把这些串起来一个从业者的日常视角把上面这些内容串起来看会发现它们不是孤立的技术点而是一条完整的链路。本地部署和微调解决的是模型从哪来的问题Agent开发解决的是模型怎么干活的问题MCP解决的是模型怎么接工具的问题SSRF防御解决的是接工具之后怎么不出事的问题。我自己的实践体会是这条链路上最容易出问题的环节往往不是技术最复杂的部分而是边界最模糊的部分。比如MCP Server的权限设计很多人开发时只想着功能实现没想过模型可能被诱导去调用危险能力。再比如Agent的错误处理很多人只测正常流程没测工具失败时Agent会不会陷入死循环。另一个体会是工具选型不要追新。llama.cpp、LangChain这些工具之所以流行是因为它们经过了大量实际场景的检验。新出的框架可能概念更先进但坑也多。除非你有明确的理由否则用成熟方案能省下大量排查时间。最后说一个具体的技巧在做Agent开发时一定要加详细的日志。记录每一步的输入、输出、工具调用、耗时。因为Agent的行为是概率性的同一个输入可能走出不同的路径。没有日志你根本无法复现问题。我习惯把日志按会话ID分组这样排查时能完整还原一次交互的全过程。这个领域变化很快今天的最佳实践明天可能就被推翻。但底层的工程原则——隔离、校验、日志、边界控制——是不会变的。把这些原则吃透比追任何一个具体工具都重要。