1. Agent 系统的构成
Agent 系统常被理解成模型加界面。这个公式能解释聊天产品，解释不了长任务、工具调用和生产环境。
模型负责理解、推理和生成。上下文怎么装配、工具怎么调用、状态怎么恢复、权限怎么控制、结果怎么验证，这些都不由模型决定，要由模型之外的工程系统承担。
把这部分拆开，可以得到 7 层：
1 | 7 治理：评测 / 权限 / 成本 / 观测 / 安全 |
编号是依赖关系，不是调用顺序。下层提供能力，上层组织任务。治理层是横切面，不是最后一站。
这套分层参考了两类材料：龙井那篇 AI 入门长文，解释模型能做什么；阿里云的 AI Agent Handbook，解释企业级 Agent 的运行时和治理。前者给能力边界，后者给工程边界。
拿客服 Agent 举例。
- 模型：理解用户问题。
- 知识：提供产品文档和订单数据。
- 上下文：装配用户问题、订单状态和检索结果。
- 行动：调用查订单、退款接口。
- 编排：决定先查什么、什么时候停。
- 产品：承接对话和人工转接。
- 治理：限制能查哪些数据、能退多少钱，并记录每一步操作。
任何一层缺了，用户看到的都是「这个 AI 不太好用」。但问题不一定出在模型。
2. Harness 的责任边界
模型之外的运行时与治理，可以统称为 Harness。业务系统、知识源、交互界面和组织流程在 Harness 外。Harness 不是一段更长的提示词，也不是某个框架。它负责把模型的判断变成可执行、可恢复、可验证的任务过程。
Harness 在业界的用法有宽有窄。我在《深入理解 AI Agent》读后感里用的是窄版，只算上下文和工具之外的约束、验证和纠正；这篇按广义用法，把模型之外的运行时和治理都算进来。
Harness 再往下拆，至少有四块：
- 编排：任务契约、循环、上下文、工具、权限、验证、状态。
- 运行：进程、调度、队列、恢复。
- 执行环境：文件、命令、浏览器、网络、凭证、沙箱。
- 平台治理：多租户、网关、配额、审计、观测、评测、安全。
两层、四块、七层、八组件不是四套模型：
- 两层：划边界，Model / Harness。
- 四块：划 Harness 内部责任，编排 / 运行 / 执行环境 / 平台治理。
- 七层：划系统组成，模型 / 知识 / 上下文 / 行动 / 编排 / 产品 / 治理。
- 八组件：专题篇里的运行时视图，任务契约 / 控制 / 上下文 / 工具 / 执行环境 / 验证 / 状态 / 观测。
这 7 层是本文的归纳，不是两份材料的原分类。
这 7 层只回答 Agent 系统由什么组成。真要落地，还得看谁来运行，怎么持续改进。专题篇《harness：定义、价值与选型》展开 Harness 的四块责任、最小集合和三类场景选型，这篇先给出整体架构视图。
3. 模型层的能力边界
模型负责理解问题、生成回答、判断下一步。它不负责记住产品文档，也不负责保证退款接口真的成功。
所以几类问题经常被混在一起：
- 回答太空泛：任务定义不清，提示词和输出格式要先改。
- 不知道公司内部规定：缺知识，RAG 或业务查询要补。
- 说话风格和格式不对：提示词、少样本通常够用，必要时才做微调。
- 不会操作业务系统：缺工具，Function Calling 和权限要补。
- 多步任务做不完：缺编排、状态和校验，换更大模型也解决不了。
这五类问题经常被归因成一句「模型不够强」。换模型能改善第一类，后面几类还是要靠系统。
提示词、RAG、微调、工具也不是一回事。提示词改的是任务描述；RAG 改的是模型能看到的信息；微调改的是模型的行为倾向；工具改的是模型能做的动作。四者不能互相顶替。
每一层都可能成为瓶颈。先找当前任务里最不可恢复的失败路径，再看它落在哪一层。
- 模型强、检索差：回答很自信，事实是错的。
- 检索强、缺工具：分析完整，交付不了。
- 工具强、权限全开：执行效率高，影响范围也大。
- 能力都有、没有评测：无法判断下一次改动是变好还是变坏。
4. 上下文、状态、记忆、知识与技能
这几个概念经常被混用。
上下文是这一次模型调用看到的内容。系统提示、用户问题、历史摘要、检索结果、工具返回，都算上下文。上下文每次都要重新装配，它不是聊天记录的自然堆积。
状态是任务已经发生了什么，做到哪一步，哪些工具调用成功，产物放在哪里。状态要持久化，要能恢复。工具调用前记下意图和授权，执行后记结果；失败后用幂等键查询外部系统，不能只凭写前日志判断有没有发生。
记忆是跨任务保留的用户偏好、历史事实和领域经验。记忆要有写入策略，要知道谁可以写、什么时候写、写什么格式、冲突怎么合并、什么时候过期、怎么删除。没有这些规则，记忆库会被污染。
知识是组织已有的文档、制度、产品资料和业务数据。知识通常来自外部系统，要有版本、权限和来源。
技能是某类任务的可复用方法，可以是说明、脚本、模板或检查清单。技能要版本化，能复用，也能回滚。
有些系统把记忆、资源、技能统称为上下文；本文把上下文限定为单次模型调用的输入，记忆、知识和技能分开看。
还有几个概念也常被混用。Task 是业务任务，Session 是一次连续交互，Event 是发生过的事实，Trace 是一次执行的完整链路，Artifact 是产物，Outcome 是业务结果。把它们分开，长任务才能恢复，评估才能归因。
最常见的错误，是把聊天记录当状态，把向量库当记忆，把检索结果直接塞进上下文，把一段提示词当技能。这些对象混在一起，系统表面上可运行，出了问题却不知道该修哪一层。
5. 一次 Agent 任务怎么执行完
一个任务真正执行完，至少要经过这几步：
1 | 目标 → 取上下文 → 规划 → 执行 → 观察 → 校验 → 记忆 → 交付 |
以报销单处理为例。
- 目标：把单据和公司制度对上。
- 取上下文：发票、审批记录、制度条款。
- 规划：先验真，再查标准，再算金额。
- 执行：调用 OCR、查员工额度、写报销单。
- 观察：看接口返回。
- 校验：金额、抬头、时间、审批人是否合规。
- 记忆：记录这次用了哪版制度。
- 交付：给出通过、驳回或转人工。
模型提出工具调用或输出结果的意图；权限、执行、结果回写、状态保存和完成校验，由模型外面的系统负责。
完成不是模型输出一句「已完成」。模型只能提出完成申请，系统要根据事实确认。文件、测试报告、接口返回、审批记录、业务系统状态，不同任务要的证据不同，但原则一样：模型申请完成，系统提交完成。
这也是 Demo 和生产系统的区别。Demo 只需要一次成功。生产要求失败时能被看见，能恢复，能追责。
验证在单次任务内执行；评测在任务之外，用离线回归决定下一版要不要改。
6. 从 Demo 到生产系统的四项能力
Demo 停在生成。生产系统要具备四项能力：
- 结果可验证。
- 动作有权限。
- 失败可恢复或可补偿。
- 过程可追溯。
这四项能力很大程度上决定了一个 Agent 系统能不能上生产。
一次受控行动，至少要经过六步：选能力、判权限、校验参数、隔离执行、校验结果、记录状态和审计。少了任何一步，模型的一个建议就可能直接变成线上事实。
同样是 Agent，决定组件强度的是四个轴，不是行业名称：动作是否可逆、影响半径多大、验证信号多贵、交互是否同步。
编码场景通常动作可逆、验证信号便宜，所以可以先长跑、失败重试；但部署生产仍是不可逆动作，要单独审批。
办公场景的动作落在邮件、日历、文档、IM 里，验证弱，主要靠过程可见、随时中断、人工审核。按组织架构授权、定时任务、审批和审计仍是硬要求。
业务场景的动作常有副作用，验证信号贵，错误不能盲目重跑。它需要最小权限、幂等键、执行前策略拦截、预算硬限制、状态回放、外部对账和独立审批通道。
这些场景的组件可以复用，循环实现不能照搬。
7. 验证、评测与调优
评测先分清两个对象：单次任务的完成门禁叫 Verifier，跨版本的版本评估叫 Evaluation。
Verifier 在任务内运行，决定这一步能不能继续、结果能不能交付。Evaluation 在任务外运行，用固定任务集、固定环境、固定评分规则，比较两版 Harness 或两个模型。
Evaluation 不能只看最终结果。至少要分三层看：单步是否选对工具、参数是否正确；轨迹是否存在绕路、重复调用或越权；最终产物和业务结果是否达成。
调优不应从更换模型开始。更可靠的顺序是：先看 Trace，按失败类型聚类，再定位问题来自上下文、状态、工具、权限、环境、循环还是模型，然后做最小修改，执行回归测试，再评估是否引入 SFT 或 RL。
SFT 改的是模型的行为习惯，RL 需要可交互的环境和可靠的奖励。它们适合解决模型能力问题，不适合替代缺失的知识、工具、权限和校验。上下文和工具没修好，先做微调，通常会掩盖问题。
8. 医疗 Agent 的 7 层职责
以医疗 Agent 为例，7 层可以直接映射到系统职责。
- 模型：做语言理解、摘要和初步推理，不能独立做诊断。
- 知识：指南、说明书、院内规范，必须带版本和来源。
- 上下文：按患者、时间、问题装配；过敏史、用药、既往史作为状态来源保留，要带来源、时间和置信度。
- 行动：查病历、算剂量、预约；开药必须医生确认。
- 编排：问诊流程、检查项、转诊；不能跳过关键步骤。
- 产品：医生工作站、患者端和人工转接；高风险操作在这里呈现审批。
- 治理：脱敏、权限、审计、人工复核；评测纳入发布门禁。
医疗系统要先回答三个问题：错误能不能被发现，发现后能不能追到原因，追到后能不能改。回答不了这三个问题，模型再强也不适合进临床。
9. Agent 产品评估的八个问题
评估一个新的 Agent 产品时，我会先问：
- 使用什么模型和版本，能力边界在哪？
- 当前任务的上下文从哪里来？是否支持上传文件、引用来源和读取历史？
- 私有知识和实时数据的来源是什么？更新和权限怎么做？
- 它可以访问哪些系统和工具？工具清单和权限能配吗？
- 跨会话保留哪些状态和记忆？记忆能查看、修改、删除吗？
- 如何验证任务完成？是否有测试、引用和复核？
- 单任务成本是多少？是否能看到 token、时延和额度？
- 发生故障后怎么处理？是否支持回滚、审计和导出？
这八个问题没有标准答案。无法回答其中任何一个问题的产品，大概率还停在演示阶段。
10. 7 层模型的适用边界
7 层不是成熟度模型，也不是每个 Agent 系统都要建全。内部工具可能只需要模型、上下文、工具和最小循环；如果连循环和终止条件都没有，它更接近 workflow，不是 Agent。面向客户的业务系统，迟早要补状态、验证和治理。
先看当前最弱的是哪一层，再看这一层由谁负责。
模型之外的运行时怎么拆，见专题篇《harness：定义、价值与选型》。
11. 相关阅读
- harness：定义、价值与选型
- 生产级 Agent 架构：以 Eino 搭建 Chatbot 为例
- Agent Orchestration - 智能体编排
- Agent 的 Token 成本：缓存、静态前缀、轨迹
- Eino 运行时分析：从编译期单例到协程级调度
- OpenViking - 基于文件的分层记忆系统
- 稳定性：从传统工程到大模型时代
12. 参考
- 《2小时从零看懂 AI：一篇文章建立AI认知体系（8000元企业内训同款）》，龙井（原文自述）。
- 阿里云 AI Agent Handbook
- Anthropic：Harness design for long-running application development
- OpenAI：Harness engineering
- LangChain：The Anatomy of an Agent Harness