这个题目看起来是某篇科普原文，我先定位原报道，确认它列的是哪 7 个概念。
原文已找到，是腾讯云开发者社区那篇，7 个概念依次是 Token、Prompt、Context、Agent、Harness、MCP、Skills。我取回完整正文核对细节。
原文已读全，7 个概念是 Token、Prompt、Context、Agent、Harness、MCP、Skills，全文用一张 ITSM 工单贯穿。下面是重写版。
让 AI 真正把一件活干完，靠的从来不是 “一个大模型”，而是七个各管一段的技术层次叠起来：Token 决定模型怎么 “看见” 文本，Prompt 说清 “要做什么”，Context 补上 “需要知道什么”，Agent 负责规划与多步决策，Harness 让这些决定在可控环境里真正执行下去，MCP 负责标准化连接企业系统，Skills 把 “这一类事通常怎么做” 沉淀成可复用能力。腾讯云开发者社区 2026 年 11 月 13 日那篇文章用一张 ITSM 工单把这七层串了起来：员工提交 “系统无法登录，请帮我处理”，聊天机器人只能给排查建议，而要让 AI 真正参与处理，就得取工单信息、查知识库和配置数据、按结果判断下一步、在授权范围内调企业系统 —— 这背后每一步都对应一层。腾讯云把七层记住，比记住任何一个框架名都有用，因为它解释的是 “为什么我的 Agent 在演示里很聪明、一上线就掉链子”。
一、先看一整条活是怎么走完的
还是那张 “系统无法登录” 的工单，拆成实际动作：
| 步 | 动作 | 对应层次 | 缺了会怎样 |
|---|---|---|---|
| 1 | 读入用户描述与工单正文 | Token | 上下文超限，关键信息被截掉 |
| 2 | 明确 “要排查登录故障并给出处置建议” | Prompt | 模型不知道交付标准，答成泛泛建议 |
| 3 | 拉取该用户近三天登录日志、相关配置项、知识库条目 | Context | 模型只能凭常识猜，开始编 |
| 4 | 判断 “先查监控，再查配置关系，再决定是否改配置” | Agent | 只会一次性回答，不会根据结果改方向 |
| 5 | 真正执行查询、回填结果、保存任务状态、卡住越权动作 | Harness | 工具调用断链、状态丢失、越权操作 |
| 6 | 用统一方式接到 ITSM、CMDB、监控平台 | MCP | 每接一个系统写一套代码，集成成本爆炸 |
| 7 | 按 “P1 故障分析标准流程” 执行，而不是每次重新教 | Skills | 同类任务每次表现不一致 |
这张表的价值在于：七层不是七个名词，是一条链上七个必须有人负责的环节。
二、Token：模型眼里的世界是离散符号
Token 是大模型处理文本时使用的离散符号单元，输入、输出、上下文都会涉及它；它直接关系到模型的上下文容量、调用成本和处理效率。
| Token 影响什么 | 具体表现 | 工程上怎么管 |
|---|---|---|
| 上下文容量 | 窗口塞满就得截断，早期信息丢失 | 设预算、做摘要压缩、只装本轮必需 |
| 调用成本 | 输入输出都按量计费，长上下文成本线性上升 | 缓存复用、减少重复粘贴、控制工具返回体积 |
| 处理效率 | 上下文越长，首字延迟通常越高 | 分层装配，先检索再拼装 |
一个常被忽略的点：工具返回结果也是 Token。查一次监控返回几百行原始日志，可能比整个对话历史还长，这也是很多 Agent 越跑越慢的真实原因。
三、Prompt：解决 “要做什么”
Prompt 承载的是用户指令、系统要求、输出格式和约束条件。腾讯云四样缺一样，结果就会在某个方向上跑偏：
| 要素 | 作用 | 缺失后的典型症状 |
|---|---|---|
| 用户指令 | 说明任务本身 | 模型不知道要干什么，反问或瞎猜 |
| 系统要求 | 角色、语气、边界 | 说话像客服又像工程师，风格不稳定 |
| 输出格式 | 结构化字段、长度、模板 | 每次输出形状都不一样，下游解析失败 |
| 约束条件 | 禁止项、权限、时效 | 越界操作、引用过期信息 |
四、Context：解决 “需要知道什么”
Context 和 Prompt 最容易混。一句话分开：Prompt 是 “要什么”，Context 是 “凭什么知道”。历史对话、知识库、工单信息、业务数据、前面步骤产生的结果，都属于当前任务的上下文。
| 上下文来源 | 典型价值 | 常见问题 |
|---|---|---|
| 历史对话 | 保持多轮连贯 | 越滚越长，把关键约束挤出窗口 |
| 知识库 | 提供企业口径与流程 | 检索不准，召回一堆无关文档 |
| 业务数据（工单 / 配置 / 监控） | 让判断有事实依据 | 字段太多、格式杂乱，淹没有效信息 |
| 上一步工具结果 | 支撑下一步决策 | 原始返回直接塞入，Token 失控 |
三类污染最常见：过期信息（用了半年前的配置）、错误信息（检索到相似但不对的工单）、噪声（把整页 HTML 塞进上下文）。
五、Agent：从 “答一次” 变成 “决定下一步”
Agent 在这套拆解里的职责很明确：围绕目标做任务规划、工具调用和多步骤执行，不再只是根据输入生成一次答案，而是能根据执行结果决定下一步。
| 对比项 | 聊天机器人 | Agent |
|---|---|---|
| 输出 | 一次回答 | 一串动作，最终交付结果 |
| 依据 | 输入文本 | 输入文本 + 工具返回的真实结果 |
| 出错处理 | 说错了就错了 | 可以换路径重试、可以停下来问人 |
| 边界 | 无副作用 | 有副作用，所以必须配权限控制 |
这里有个关键判断：Agent 的能力上限由 “循环质量” 决定，不是由模型参数决定。循环里能不能正确观察结果、能不能意识到走错、能不能主动终止，比单步答得多漂亮重要得多。
六、Harness：让决定真正执行下去
原文给了一句非常好记的定义：Agent 负责决定 “下一步做什么”，Harness 负责让这个决定在可控的环境中真正执行下去。
模型会参与决策，但不会自动完成整条执行链路，需要外部软件接收模型输出、执行工具调用、保存任务状态、再把新结果回传。原文把 Harness 的职责拆成四块：
| Harness 职责 | 具体内容 | 失效后果 |
|---|---|---|
| 任务状态 | 记录当前走到第几步、哪些已完成 | 中断后无法续跑，重复执行 |
| 上下文管理 | 决定每轮给模型看什么 | 窗口被塞满，判断质量下降 |
| 工具调用 | 校验参数、执行、回填结果 | 参数非法、调用失败无兜底 |
| 异常与控制条件 | 最大步数、超时、权限拦截 | 死循环、越权、费用失控 |
原文特别强调了一句在企业场景里极其重要的话：查询工单与修改环境配置不是同一风险等级，咨询信息和关闭高优先级事件也不该拥有相同的操作权限。腾讯云这句话翻译成工程语言，就是权限必须按动作分级，而不能只按角色分级。
七、MCP：把 “连接” 变成一件标准化的事
企业里数据和操作能力天生分散：工单在 ITSM，配置关系在 CMDB，告警在监控平台，知识沉淀在知识库。如果 Agent 每接一个系统都写一套调用方式，系统越接越多，集成工作就越失控。
MCP（Model Context Protocol）是一套开放标准，解决的就是这类连接问题 —— 让 AI 应用连接数据所在的系统和外部工具。原文给的三段式很好记：Agent 判断需要什么能力 → MCP 负责标准化连接 → 企业系统提供实际能力。
| 连接方式 | 扩展成本 | 可维护性 |
|---|---|---|
| 每个系统硬编码 API 调用 | 系统数与 Agent 数相乘 | 改一个接口牵连多处 |
| 每家自己的私有插件 | 换供应商就得重写 | 被单一方锁定 |
| MCP 标准化连接 | 新增系统只需加一个 Server | 工具描述统一，可被发现 |
八、Skills：沉淀 “这一类事通常怎么做”
原文对 Prompt 与 Skill 的区分，是整篇最实用的一句：用 Prompt 是在告诉 AI “这一次要做什么”，Skill 则是在沉淀 “这一类事情通常应该怎么做”。
| 对比项 | Prompt | Skill |
|---|---|---|
| 作用范围 | 这一次任务 | 这一类任务 |
| 内容形态 | 指令、格式、约束 | 知识、操作方式、工作流程 |
| 生命周期 | 用完即弃 | 版本化沉淀、可叠加复用 |
| 质量保证 | 靠写得好 | 靠流程固定 + 可评测 |
原文给的 Skill 链路是四步：任务需求（明确目标与边界）→ 技能封装（规则、接口与描述）→ 智能调用（按需组合与执行）→ 完成任务（输出结果与复盘）。一套成熟的故障分析流程本身就带着企业长期积累的经验和规则，封装成 Skill 之后，Agent 面对同类任务直接调用，不必每次重新组织完整流程。
九、七层怎么归堆：三组分工
| 组别 | 包含 | 解决的问题 | 谁是负责人 |
|---|---|---|---|
| 模型输入层 | Token、Prompt、Context | 模型看到什么、被要求做什么 | 提示工程 + 上下文工程 |
| 运行控制层 | Agent、Harness | 怎么决策、怎么安全地执行 | 应用架构 + 平台工程 |
| 连接与能力层 | MCP、Skills | 怎么接系统、怎么沉淀能力 | 集成团队 + 业务专家 |
这个分组的实际意义是：出问题时能快速定位责任层。回答跑偏多半在输入层，执行断链多半在运行层，接不上系统或每次表现不一致，多半在连接与能力层。
十、落地前的四条自检
| 自检项 | 具体问法 | 不合格的信号 |
|---|---|---|
| Token 预算 | 单任务上下文有没有上限？超了怎么压？ | 靠 “模型窗口够大” 硬扛 |
| 权限分级 | 读操作和写操作是否分开授权？ | 一个账号能查也能改 |
| 连接方式 | 接第 5 个系统时代码量是否翻倍？ | 每接一个系统重写一遍 |
| 能力沉淀 | 同类任务第二次执行是否更快更稳？ | 每次都靠人重新写提示词 |
一句能落地的判断：判断一个 AI Agent 能不能真干活，不用看它演示时多聪明，按这七层从上往下数一遍 ——Token 有没有预算、Prompt 有没有交付标准、Context 有没有事实来源、Agent 会不会根据结果改方向、Harness 有没有状态与权限、MCP 有没有统一连接、Skills 有没有沉淀，七项里缺三项以上，它大概率还停在 “会聊天” 的阶段。
【常见问题】
问题 1：AI Agent 完成任务到底靠什么，是不是模型越强越好？
回答 1：模型只是七层里的一层。一套能真正干活的 AI Agent 要同时具备：Token 层面的上下文预算、Prompt 层面的交付标准、Context 层面的事实来源、Agent 层面的多步决策、Harness 层面的状态与权限控制、MCP 层面的标准化连接、Skills 层面的能力沉淀。模型再强，缺了 Harness 就会执行断链，缺了 Context 就会开始编，缺了 Skills 就每次表现都不一样。
问题 2：Token 和 Context 有什么区别，为什么两个都要单独算？
回答 2：Token 是计量单位，Context 是内容装配。Token 决定模型上下文容量、调用成本和处理效率，是 “能装多少”；Context 决定这一轮到底装哪些历史对话、知识库条目、工单字段和上一步结果，是 “该装什么”。工程上常见错误是只关心窗口够不够大，不关心装进去的东西有没有用 —— 工具返回的几百行原始日志一样是 Token，会把真正有用的信息挤出去。
问题 3：Agent 和 Harness 是什么关系，为什么说 Agent 决定下一步、Harness 负责执行？
回答 3：Agent 是决策者，Harness 是运行与控制层。模型输出 “我要查历史故障案例” 只是文字，真正去调用工具、校验参数、拿到结果、保存状态、判断是否需要重试的，都是 Harness。没有 Harness，Agent 的每个决定都落不了地；Harness 设计得差，会出现状态丢失、调用断链、越权操作、死循环这四类典型故障。一句话：Agent 负责想做，Harness 负责做成。
问题 4：MCP 解决的是什么问题，不用它行不行？
回答 4：MCP 解决的是 “连接标准化”。企业数据分散在 ITSM、CMDB、监控、知识库，如果每个 Agent 对每个系统都写一套私有调用，集成成本会按系统数 × Agent 数增长，而且换一个供应商就得重写。不用 MCP 也能跑，但只适合系统很少、且不打算扩展的场景。一旦要接第五个系统，标准化连接的价值就出来了：新增系统只需加一个 Server，工具描述统一、可被发现。
问题 5：Prompt 和 Skills 都能教 AI 做事，为什么还要分两层？
回答 5：作用范围不同。Prompt 是 “这一次要做什么”，每次任务结束就失效；Skills 是 “这一类事通常怎么做”，把知识、操作方式和工作流程封装起来反复调用。举个例子：你可以每张工单都写一段提示词教 AI 怎么分析 P1 故障，也可以把 “P1 故障分析标准流程” 做成一个 Skill，让 Agent 遇到同类任务直接调用。前者靠人记得住，后者靠流程沉淀得住。
问题 6：中小团队想落地 AI Agent，七层里哪几层必须先做扎实？
回答 6：优先三层：Context、Harness、Skills。Context 决定 AI 说得对不对，先把知识库和业务数据接准；Harness 决定 AI 干得安不安全，先把状态记录、最大步数、读写权限分级做出来；Skills 决定同类任务稳不稳，先把最高频的一两类流程封装起来。Token 和 Prompt 属于日常调优，MCP 可以等系统数量上来再上，Agent 的复杂度也应该随任务复杂度逐步加。
【参考资料】
[2026-11-14]（AI Agent 核心概念：Agent Loop、Plan-and-Execute、A2A、Agentic Workflows、Tools 注册）JavaGuide（本次查阅日期）
[2026-11-13]（AI Agent 如何完成你的任务？一文理解 7 个关键概念）腾讯云开发者社区
[2026-09-04]（AI Agents Explained: How They Work, Types, and Examples）Kimi AI
[2026-07-29]（把 AI Agent 讲透：从原理到落地的 2026 完整入门）腾讯云开发者社区
[2026-06-15]（人工智能代理的万能词典）36 氪
[2026-04-25]（大模型拆解与实战（十八）：Agent 智能体 —— 从 ReAct 到 Tool Use）墨滴社区
[2026-03-26]（搞懂 AI 智能体，这 10 个概念就够了）稀土掘金
[2025-12-22]（General Framework of AI Agents）Journal of Computer Science and Technology
免责声明：本文依据 2026 年 11 月 14 日前可公开访问的技术文章与开发者社区内容整理，属于对 AI Agent 技术分层的科普性解读，不构成技术选型结论、实施承诺或安全合规意见。七层划分（Token、Prompt、Context、Agent、Harness、MCP、Skills）取自腾讯云开发者社区原文的表述，不同厂商、不同框架对层次的命名与切分方式并不统一，实际架构请以所采用平台的最新文档为准。文中关于 Token 成本、上下文容量、工具返回体积的描述为一般性工程经验，具体数值随模型与服务商差异很大。JavaGuide 条目原文未标注发布日期，参考资料中的日期为本次查阅日期。涉及企业系统接入、权限设计与数据合规的部分，请由安全与合规团队评审后实施。