AI Agent搭建：从概念到实战的痛与悟

skill是什么MCP是什么tool又是什么别急着去找定义先问问自己——你搭过Agent吗一、我曾经也以为这些都是新瓶装旧酒说实话我曾经也是那个追着新概念跑的人。skill、MCP、tool、agent framework……每个新概念出来我的第一反应都是这不就是换了个名字吗skill不就是提示词嘛套个markdown模板降低用户写prompt的成本。MCP不就是RPC调用嘛换个协议封装一下。tool不就是函数调用嘛LLM时代改了个名字叫function calling。我甚至一度觉得这些东西本质上都是一样的新瓶装旧酒不过是圈子里的黑话用来抬高门槛、制造焦虑的。直到我真的开始搭一个Agent。二、当你真的去搭一个Agent才会发现痛点是真实存在的我用的模型是qwen3-8B量化版本 q4_k_m通过 llama.cpp 本地部署。自己写了个 MCP Server实现了几个工具调用接了个记忆模块心想这不就齐活了结果一测试问题接踵而至。问题一模型突然抽风有时候对话好好的模型突然就开始疯狂调用工具智能ctrlc,强行中断modle问题二记忆模块间歇性失忆记忆系统有时候能正常提取有时候LLM事实提取为空标签命名直接降级成未命名。明明上一轮还记得的事情下一轮就忘了。问题三工具调用的边界失控模型不知道什么时候该停。该用工具的时候不用不该用的时候乱用。你给它一个get_subdir_list它可能顺手就把整个目录树给你翻个底朝天。这些问题不是概念能解决的是工程问题。三、Harness Engineering不是新概念是新痛点面对这些问题我的第一反应是什么加限制。在 client 或者 server 端加一个检测如果工具调用次数超过 N 次强制中断。甚至直接断开 MCP 连接让模型停下来。这就是Harness Engineering约束工程的一部分。它不是某个框架、某个库、某个协议。它是你在实际搭建过程中为了解决模型行为不可控这个问题而不得不做的一系列工程化约束。限制工具调用次数设置超时机制添加调用链路的熔断器对模型输出做后校验给记忆系统加一致性检查这些东西没有现成的库给你用。MCP 不管这个。Skill 不管这个。Tool 也不管这个。这是你自己的业务逻辑是你必须亲手写的缰绳。四、为什么我说新概念的提出是痛点的解决方案现在回头看skill、MCP、tool它们真的只是新瓶装旧酒吗不是。它们每一个概念的背后都是一群真正搭过Agent的人在解决真实痛点时提炼出来的最佳实践。Skill 不是提示词模板产品侧的 skill确实是个 markdown 文件降低用户写 prompt 的成本。但技术侧的 skill是一个可复用的功能模块包含完整的感知、决策、规划、工具调用。它有SKILL.md定义输入输出有tools/目录封装业务逻辑有config.yaml管理配置。为什么需要这么多结构因为当你把 skill 复用到第三个 Agent 的时候你会发现没有标准化就是灾难。MCP 不是RPC 换皮MCP 解决的是外部系统连接的标准化问题。浏览器、网站、数据库、文件系统——这些东西已经有人写好了、维护好了你通过 MCP 直接调用就行。如果没有 MCP你每接一个新的外部工具都要重新写一遍适配层。Tool 不是函数调用Tool 是模型与外部世界交互的接口定义。它要解决的是如何让模型理解这个工具能干什么、需要什么参数、返回什么结果。这不是简单的函数签名是语义对齐的问题。五、Agent Skill 和 MCP互补不是替代MCP已死我的答案是不见得他们是互补关系。表格场景用 Skill用 MCP业务逻辑核心、定制✅❌外部系统浏览器、网站、数据库❌✅业务逻辑放 skill外部连接走 MCP二者相辅相成。这不是谁取代谁的问题是分工的问题。就像你写后端服务核心业务代码自己写第三方服务用 SDK——道理是一样的。六、写在最后走进圈子才能理解概念我一度认为这些概念都是一样的是因为我没有真正走进去。当你真的去搭一个 AI真的去调一个 8B 量化模型真的去写一个 MCP Server真的去处理模型抽风的问题——你才会发现新概念的提出从来不是新瓶装旧酒。它们是前人踩过的坑、流过的汗、熬过的夜最后封装成的解决方案。Harness Engineering 也是如此。它不是某个框架的名字不是某个论文的术语。它是你在亲手搭建 Agent 的过程中为了解决模型不可控这个真实痛点而不得不做的一系列工程化实践。概念是表象痛点是本质。只有真正走过这条路的人才能分辨其中的区别。没有调查就没有发言权。在 AI 时代这句话变成了没有搭过 Agent就没有资格说新瓶装旧酒。