很多使用者会混淆一个核心问题：Qoder整个软件是智能体，还是里面的大模型是智能体？ 结论前置：Qoder整套软件是智能体运行平台（Agentic Platform）；Qoder内部实例化出来的Agent（智能体）是一套「模型+Harness调度框架+工具+记忆+校验闭环」的组合；单独的底层大模型，只是智能体的推理大脑，它本身不是智能体。下面通过分层表格、对比表格、执行链路表格完整全景拆解。
一、四层分层架构全景表
从外层产品到内层基础模型，逐层定义、定位、核心组件、能不能独立干活。
| 层级 | 名称 | 定位 | 核心组成 | 是否属于智能体 | 独立运行能力 |
|---|---|---|---|---|---|
| 第1层 | Qoder（整套软件产品） | 智能体工作台/Agent运行平台 | 桌面端、IDE插件、CLI、云端控制台、账号权限、会话管理、模型路由、UI交互面板、SDK网关 | ❌ 不是智能体，是承载、调度、管理智能体的平台 | 可以独立打开软件，但自身不会自动执行任务，必须启动Agent会话才会干活 |
| 第2层 | Qoder Agent（智能体实例） | 具备自主任务闭环的执行单元 | Agent Harness调度器、系统提示词、工具集（读写文件、终端、MCP）、RepoWiki项目记忆、沙箱安全护栏、子Agent编排、规划-执行-验证循环、人工审批节点 | ✅ 这才是Qoder里所说的智能体 | 不能脱离平台框架单独跑，必须依附Qoder Runtime；可以切换底层模型，框架不变 |
| 第3层 | SubAgent（子智能体） | 主Agent委派的专项专家单元 | 独立上下文、独立工具白名单、独立模型配置、隔离会话线程，如代码探索Agent、方案规划Agent、测试Agent | ✅ 属于轻量智能体 | 由主Agent动态拉起，完成专项任务后回收结果，生命周期依附主任务 |
| 第4层 | 底层LLM大模型（Qwen / DeepSeek / Kimi / GLM等） | 智能体的推理大脑 | 基础预训练大模型，输入文本、输出文本推理结果 | ❌ 单纯模型≠智能体 | 只能做文本推理，没有工具调用、记忆、任务规划、环境操作能力，离开Harness就是普通对话模型 |
官方原文佐证：模型负责思考；Harness负责把任务闭环跑完。同一个模型，放到不同Agent Harness里面，自主执行能力天差地别。
二、三者核心差异对比表（解决最容易混淆的点）
| 对比项 | Qoder整套软件平台 | Qoder Agent智能体 | 底层大模型 |
|---|---|---|---|
| 核心目标 | 提供人机交互入口、资源调度、权限管控、多任务管理、模型路由 | 接收用户目标，自动拆解步骤、调用工具、反复验证迭代直到交付结果 | 基于输入文本做推理、生成文本、理解需求、给出思路 |
| 自主执行能力 | 无自主能力，被动等待用户启动任务 | 具备目标驱动的自主闭环：规划→执行→校验→纠错迭代 | 无自主闭环，没有工具权限，不会主动操作文件、跑命令、验证结果 |
| 可替换性 | 框架固定，可以接入不同模型、自定义Agent模板 | Agent模板可配置：换模型、增减工具、修改权限规则 | 可自由替换，Auto路由会自动匹配最优模型；模型换了，Agent调度逻辑不变 |
| 记忆能力 | 全局账号、项目知识库的存储载体 | 会话级+项目级长期记忆（RepoWiki、Knowledge Card） | 只有单次上下文窗口，原生不具备项目持久记忆 |
| 安全边界 | 统一沙箱、审批策略、审计日志入口 | 单会话内工具白名单、动作审批、执行隔离 | 本身没有权限、没有沙箱，不知道什么操作是危险的 |
| 通俗类比 | 程序员工作室、办公工作台 | 会自主干活的程序员（有脑子、能看文档、敲代码、自测、改错） | 程序员的大脑，只会思考，没有手脚、没有记事本、不知道项目规则 |
三、一次完整任务的执行链路表（直观看到三者如何配合）
以需求：给Java项目新增一个接口并自测
| 步骤 | 执行主体 | 动作说明 |
|---|---|---|
| 1 | 用户在Qoder工作台输入需求 | Qoder平台接收指令，创建新Session，加载项目RepoWiki知识库，由路由选择模型 |
| 2 | Agent Harness（智能体框架） | 调用LLM模型，让模型做任务拆解，输出执行方案 |
| 3 | 底层LLM模型 | 理解需求、梳理方案、识别需要修改的文件、识别依赖 |
| 4 | Agent（智能体） | 拿到方案后，调用文件读取工具读取源码，拉起代码探索SubAgent |
| 5 | SubAgent子智能体 | 检索项目结构，返回上下文给主Agent |
| 6 | Agent（智能体） | 再次调用LLM生成代码修改内容，调用写文件工具修改源码 |
| 7 | Agent（智能体） | 调用终端工具执行编译、单元测试，拿到报错结果 |
| 8 | 底层LLM模型 | 分析报错日志，给出修复思路 |
| 9 | Agent（智能体） | 循环迭代修改代码、复测，直到测试通过，结束闭环，提交结果给工作台展示 |
| 10 | Qoder平台 | 保存会话记录、更新项目知识库，展示最终改动差异，等待用户确认 |
可以看到：模型只是循环里面的一个推理组件；Agent是串联所有动作、驱动循环的主体；Qoder软件是承载这一切的工作台。
四、容易踩坑的概念误区澄清
| 误区 | 正确理解 |
|---|---|
| 误区1：Qoder是一个智能体 | ❌ Qoder是平台，平台里面可以创建无数个独立Agent智能体，Agent是平台上运行的实例 |
| 误区2：Qoder里面的模型就是智能体 | ❌ 模型只是大脑。脱离Agent Harness、工具、记忆、循环校验，模型只能聊天，不能自主完成工程任务 |
| 误区3：Agent绑定死某一个大模型 | ❌ Agent是配置模板，同一个Agent模板，可以切换Qwen、Kimi、DeepSeek等不同底层模型，Agent框架不变 |
| 误区4：SubAgent是独立软件 | ❌ SubAgent是主Agent派生出来的专项智能体，属于Agent体系内的分工，不是独立产品 |
五、业务落地视角总结
站在产品与落地角度：
- 当我们口语说"用Qoder智能体写代码"，是简化说法，完整含义是：在Qoder平台上，启动一套配置好的Agent智能体，由选定的底层大模型作为推理核心，自主完成工程任务；
- 平台、Agent、模型三者是解耦分层设计：这也是Qoder支持多模型自动路由、自定义Agent模板、MCP工具扩展的底层基础；
- 智能体的核心，从来不是大模型本身，而是Harness带来的闭环能力：规划、工具调用、结果校验、反思纠错、长期项目记忆、安全管控。模型决定思考质量，Agent框架决定它能不能把一件复杂工作从头到尾做完。