先把三个层次分清
这个问题很实际。有人说“这个模型支持查日历”，有人说“我做了一个 Agent”，也有人把整个聊天产品都叫作“大模型”。这些说法在日常交流中可能听得懂，但讨论功能、开发成本和错误原因时，把它们混在一起，就容易找错问题所在。
先继续使用会议通知的例子。假设你打开一个办公应用，登录账号，在输入框中写下要求。系统读取日历，生成草稿，保存文件，最后在界面里显示文件位置。
用户看到的是一段连续的体验，背后却有不同层次的工作。
模型负责根据给定输入进行计算，产生文字或工具调用请求；Agent 负责围绕任务，把模型、工具、状态和后续处理组织起来；完整应用则把这套能力做成用户能够使用的产品。
这里是在区分职责，不是在规定每家公司必须怎样拆分代码。一些功能可能放在同一个程序里，也可能由不同服务提供。关键是知道，哪一部分承担哪一种工作。
模型提供的计算能力
先从模型看起。
当程序把“请把会议通知写得正式一些”以及会议资料交给语言模型，模型可以生成一段通知。如果这次调用提供了工具说明，模型也可以生成查询日历的请求。对模型来说，它使用的是实际送入这次计算的信息，输出的是模型接口支持的结果。
模型参数可以保留训练形成的能力，但你在办公应用里的登录身份、日历访问凭证、某个文件夹的真实内容，不会因为模型擅长语言处理，就自动成为它知道的信息。
因此，“模型能够提出日历查询请求”和“这个应用已经接好了你的日历”，是两项需要分别成立的条件。实际查询还需要连接日历服务、处理权限，并取得返回结果。模型请求与工具执行的职责
Agent 怎样组织任务
再来看 Agent。
Agent 接收到用户目标以后，需要让任务能够往下运行。它会使用模型对当前资料的分析，选择查询工具，把执行结果加入后续处理，记录已经找到的会议，再决定是否继续核实或生成草稿。模型的能力，是这个过程中的一个重要部分。
例如，查询返回两条相似记录，Agent 的后续过程可以根据已有项目资料，继续查看其中一条的详情；如果发现并不匹配，再读取另一条。工具实际执行后产生的结果，会影响下一步。
在代码中，这些处理可能由一个循环、一些普通函数和状态记录共同实现，也可能使用成熟框架。采用哪种实现，不改变这件事的基本含义：一次任务需要把多次计算与实际操作衔接起来。Agent 的模型与运行设施
完整应用的产品责任
不过，一个能在开发环境里完成上述过程的 Agent，还没有自动解决所有产品问题。
你打开应用时，首先要知道当前登录的是谁。这个身份决定应当读取哪份日历，允许访问哪些文件，任务结果应该属于哪个用户。即使两个人输入完全相同的请求，应用也不能把一个人的会议资料交给另一个人。
这是身份和数据访问的问题。可以让模型辅助理解操作意图，但访问控制需要在实际执行路径中生效，不能只依赖模型读到一句“请注意隐私”。
接下来，界面需要让用户输入要求、查看进展、打开结果。如果任务还在查资料，应用可以显示正在处理；如果工具需要重新连接账号，就要说明需要完成的操作；如果用户要取消，也需要有相应的入口和处理逻辑。
这些界面和交互工作，与生成通知的语言能力有关联，但有各自的设计与实现。
任务数据也需要安放。会议草稿保存到哪里？文件已经生成以后，关闭页面再回来还能不能找到？运行到一半连接断开，系统能否恢复进展？这些问题涉及文件存储、数据库、任务状态和恢复机制。
模型的上下文、一次任务的进展记录，以及应用长期保存的数据，作用也有所不同。将内容写入可持续使用的存储，需要明确的保存机制；只保存在内存里的状态，可能随着程序结束而消失。运行状态与持久化存储
完整应用还需要决定，哪些内容交给模型处理，哪些内容用规则或普通程序完成。
例如，把会议标题改写成自然的通知，可以交给语言模型；检查日期字段是否缺失、文件是否存在，则可以用明确的程序逻辑处理。用户填写了会议编号，系统也许可以直接查到记录，不必再让模型猜测用户指的是哪场会议。
因此，一个完整应用里面，可以同时存在普通表单、固定工作流、模型调用和 Agent 任务。它们共同服务于用户的实际需求，并不要求每个页面都由 Agent 控制。
到这里，就能看清三个层次之间的关系：
用户使用完整应用 → 应用接收并管理任务 → 需要时启动 Agent 过程 → Agent 调用模型和工具 → 应用保存并呈现结果
这条线只是本例的组织方式。一些应用只调用模型生成一次文字，就已经能很好地完成工作；另一些应用会把一个受限的 Agent 嵌入已有流程，而不是让 Agent 接管整个产品。
模型与模型服务
还有一个容易混淆的地方：模型和模型服务也有区别。
模型本身包括相应的计算结构与参数。为了让其他程序方便调用，人们可以把模型运行起来，通过接口提供服务。这样的服务可能额外处理请求排队、身份校验、调用额度等事情。
应用调用某个服务时，得到的是这个接口承诺提供的能力。服务背后包含哪些工具、存储或运行设施，需要看实际设计，不能把服务提供的全部能力都归到模型参数本身。
错误定位与整体评估
同样的区分，也适用于“换一个更好的模型能不能解决问题”。
假设生成的通知把“下午两点”写成了“下午三点”，需要检查资料怎样进入模型、模型怎样生成，以及后续有没有核对。更换模型可能是改进方向之一，但也可能是上下文丢失了正确时间。
如果系统读到了另一个人的会议，则应先检查身份、查询条件和权限过滤。如果正文正确但文件没有保存，应检查文件工具和保存过程。如果文件已经保存，界面却找不到，则应检查应用的数据同步或展示逻辑。
这些错误看起来都像“AI 没做好”，实际原因可能落在完全不同的地方。先确定出错的职责层，才能选择有效的改进方式。
比较产品能力时，也需要同样的习惯。
两个应用即使使用同一类模型，结果也可能不同。它们给模型提供的资料、工具说明、操作权限、任务组织和结果检查可能不同。反过来，一个应用更换模型以后，也不一定会立刻获得另一个应用已有的文件管理或日历集成能力。
模型的能力评估，通常关注在给定输入条件下能否完成某类任务。应用的评估范围则更广：身份与数据是否正确、工具是否成功执行、任务是否完成、错误能否被处理，以及用户能否找到结果。
以会议草稿为例，模型能写出一段合适文字，只覆盖了其中一部分。完整体验还要求会议选择正确、资料使用准确、文件真正落盘，并且用户能够访问。
也不必因此把开发 Agent 理解成从头建设一整套软件。开发者可以在已有应用中接入模型或 Agent，复用现成的登录、存储和业务系统。学习这些层次，是为了知道需要接上什么，而不是要求把所有基础能力重新做一遍。
以后遇到“这个大模型能不能帮我做某件事”，可以先把需求说具体：是让模型生成内容，是让 Agent 连续组织操作，还是需要一个带账号、权限和文件管理的完整应用？这样才能判断目前已经有了哪些条件，还缺哪一段配合。
下一篇进入 01.07：工作流与自主 Agent 的区别，继续看任务的执行路径主要由谁安排，以及固定步骤和动态选择怎样组合。
当前学习编号：01.06 模型、Agent 与完整应用的区别。
下一学习编号：01.07 工作流与自主 Agent 的区别。后续还有其他学习编号。
关联分支：模型接入对应 12.02 托管 API 与本地模型、12.04 消息角色与对话格式；任务执行对应 01.10 Agent Harness：运行环境与控制设施、16.05 工具调用请求与实际执行的区别、19.02 工作状态与业务状态。
完整应用还关联 22.05 身份认证与访问授权、22.11 多租户隔离与检索权限、23.01 模型评估与完整系统评估、26.05 进度反馈与结果呈现、26.07 业务系统集成与领域规则。这些知识会在各自编号中展开。