AI智能体的真相：模型只占20%，剩下80%才是核心

每个人都在谈论AI智能体（Agent），但很少有人能说清它到底是什么。如果让别人解释智能体和ChatGPT有何不同，多半会得到一堆含糊的答案。而真正的关键在于：模型——也就是我们常说的AI——可能只占整个智能体的20%，剩下那不为人知的80%，才是决定智能体能力上限的核心所在。

本文基于B站一位技术UP主的实战讲解，用通俗的方式拆解真实AI智能体的每一个组成部分，并通过一个从零构建的开源示例，验证这些概念如何真正运转起来。

模型不是智能体，只是一个函数

理解智能体的第一步，是打破对模型的迷信。模型本质上只是一个函数：文本进去，文本出来，仅此而已。它不能搜索网页、不能读取你的文件、不能运行代码，甚至记不住你上一条消息说了什么。

当ChatGPT让你感觉比这聪明得多时，是因为模型周围有一大堆软件在承担繁重工作。所谓智能体，就是把一个模型放进某种循环中得到的东西：模型查看目标、选择一个动作、由外部程序真正执行该动作、结果反馈给模型，然后不断重复直到任务完成。

模型是大脑，但一个泡在罐子里的大脑什么也做不了。真正有趣却少有人讲清楚的，是围绕这个大脑的所有配套设施。按照UP主的框架，这里主要有五个部分。

Harness：把一切串联起来的运行时

第一个部分是Harness（运行时框架），它就是前面描述的那个循环。它不是什么神奇的AI，而是一段实实在在用代码写成的软件。

Harness承担着核心的编排职责：向模型发送提示词、执行模型要求的动作、管理上下文窗口避免模型被自己的历史记录淹没，并保持状态使任务能在重启后继续。如果你用过Claude Code、ChatGPT或Cursor，你其实已经在使用Harness了，只是不知道它叫这个名字。它可以说是智能体中最重要的一环，同时也连接着下面几个关键组件。

MCP：让智能体访问工具的通用接口

第二个部分是MCP（Model Context Protocol，模型上下文协议），它是一种让AI智能体访问工具的标准方式。

它要解决的问题很实际：假设你想让智能体搜索网页、查看日历或查询数据库。在MCP出现之前，每一个这样的集成都需要你自己编写和维护。而MCP把每个功能变成一个能说同一种通用语言的服务器，智能体可以连接它、询问它提供哪些工具，然后立即使用。

可以把它想象成USB：你不需要为每个设备写自定义驱动，随便插上就能用。任何MCP服务器都能与任何智能体配合，只要Harness支持它并处理模型与工具之间的桥接。在示例构建中，作者接入了一个处理网页搜索的MCP服务器（Exa），让模型第一次真正拥有了看见外部世界的能力。

MCP由Anthropic于2024年11月正式开源发布，目前已获得OpenAI、Google DeepMind、微软等主要AI厂商的支持，迅速成为行业事实标准。从技术架构看，MCP采用客户端-服务器模型：智能体（客户端）通过JSON-RPC协议与各工具服务器通信，服务器向客户端声明自己提供哪些「工具」（Tools）、「资源」（Resources）和「提示模板」（Prompts）。客户端发现工具后，模型可以在推理时决定调用哪个工具、传入什么参数，服务器执行后返回结构化结果，再由Harness注入模型上下文。目前已有数百个社区开发的MCP服务器，覆盖GitHub、Google Drive、Slack、Postgres等主流场景，开发者可直接复用，无需重新编写集成代码。

技能与沙盒：决定「怎么做」与「安全地做」

如果说MCP决定了智能体「能做什么」，那么技能（Skills）就决定了它「如何把事情做好」。

技能本质上是一个markdown文件，里面是针对特定任务类型的指令，类似交给新员工的标准操作流程：报告该用什么格式、需要遵循哪些步骤、使用哪些工具、要注意哪些陷阱。关键设计在于按需加载——智能体知道有哪些技能可用，但只在判断需要时才加载整份技能通读，避免占用宝贵的上下文空间。

第四个部分是沙盒（Sandbox），这是大多数人从未认真思考的环节。真正的任务往往需要执行代码——分析数据、处理文件、生成报告。但你真的希望AI在你的真实电脑上运行任意代码吗？一条错误命令就可能触及你所有的文件和凭据，尤其在拥有root权限时。

沙盒的方案是给智能体一台「一次性计算机」：一个随用随起的隔离环境，让它以受限权限运行代码，完成后直接丢弃。即便搞砸了也无所谓，因为它根本不在你的机器上。构建生产级智能体时，沙盒对于零风险执行代码至关重要。

沙盒技术在AI智能体场景中通常基于容器（Docker/OCI）或微虚拟机（如AWS Firecracker、gVisor）实现。容器方案启动快、资源开销小，但内核共享带来一定的逃逸风险；微虚拟机则在毫秒级启动的同时提供接近虚拟机的隔离强度，更适合执行不可信代码。权限控制上，沙盒通常会限制网络出站规则（只允许访问特定域名）、文件系统挂载范围以及系统调用白名单（seccomp），确保即便模型生成了恶意命令，其影响也被严格控制在隔离边界内。在多租户商业部署场景下，每个用户会话通常对应一个独立的沙盒实例，任务完成后立即销毁，从根本上消除用户间数据泄露的可能。

生产层：从Demo到真正可用的分水岭

第五部分是生产层，这是把「演示」和「真正可运行的产品」区分开来的关键，它实际由三件独立的事组成。

• 子智能体（Sub-agents）：让一个大任务分散到多个并行的工作者中，而不是靠单个上下文窗口做完所有事。这既能并行加速，也能多次运行模型而不依赖单一实例。
• 审批（Approval）：强制智能体在执行敏感操作前停下来，请求人工批准，相当于一道护栏。
• 可观测性（Observability）：对每一步、每次工具调用、每个结果的完整记录。当出问题时，你能真正看到智能体做了什么，而不是靠猜测。这在追踪结果、优化失败的工具调用时尤为重要。

可观测性在AI智能体领域有别于传统软件监控。由于智能体的执行路径是由模型动态决策的，同一个输入在不同运行中可能产生完全不同的工具调用链，传统的日志打点难以覆盖所有分支。业界通常借助OpenTelemetry标准或专门的LLM可观测性平台（如LangSmith、Langfuse、Arize Phoenix）来追踪每次模型推理的输入输出、token消耗、延迟和工具调用详情。这些数据不仅用于排查故障，还是评估智能体「哪一步推理出了偏差」的关键依据——在复杂多步任务中，错误往往不在最终输出，而隐藏在中间某次工具调用的参数拼装上。子智能体架构则引入了额外的并发协调问题：多个子任务可能竞争同一资源或产生冲突结果，编排层需要有合并、去重与冲突解决的逻辑。

实战验证：用开源框架构建研究智能体

为了证明这套结构不是空谈，作者用一条命令 npx truefoundry/trueforge 启动了开源框架TrueForge（Windows下需在WSL中运行，前提已安装Node.js）。框架启动后会提供一个本地端口，浏览器打开即可进入图形界面。

因为是开源框架，你可以接入任意模型——OpenAI、Anthropic、Gemini，或自定义提供商。作者甚至连接了运行在自己DGX Spark上的Qwen3系列本地模型，实现完全本地化运行，这是Claude Code这类工具做不到的。

作者先做了一组对比：在没有接入任何工具时，让模型扮演研究智能体，去调研当前最好的本地AI模型。结果全部来自训练数据，模型仍以为现在是2025年前后，因为它无法访问网络。

随后，作者依次配置了三样东西：连接器（接入Exa网页搜索的MCP服务器）、技能（启用网页工件构建器，用于生成交互式仪表板）、沙盒（TrueForge可在Linux/WSL中创建自己的隔离Shell，若需大规模运行则可接入Daytona等远程沙盒）。

用同样的提示词再跑一次，结果截然不同：智能体列出了可用工具、启动了多个子智能体、通过真实网络搜索给出了包含DeepSeek^广告 R1、MiniMax、GLM、Mistral等最新模型的研究摘要，并借助技能实时构建出可交互的网页仪表板。整个过程的每一步都能在可观测性日志中追溯。

最后，作者把这套配置保存为一个可复用的「研究员」智能体，既能在Web界面直接调用，也能通过TrueForge SDK在代码中触发，甚至用Docker Compose、Kubernetes配合Okta SSO部署给团队使用。

写在最后

这次拆解把一个被过度神化的概念还原成了工程实践：智能体 = 模型 + Harness + MCP + 技能 + 沙盒 + 生产层。模型提供智能，但真正让智能体「有用、可靠、可控」的，是围绕它的那80%基础设施。下次再有人把智能体和ChatGPT混为一谈时，你会清楚地知道差别究竟在哪里。