AI应用开发的核心链路：模型、上下文、工具、记忆和评测
你有没有这样的体验：你提一个问题给在线的大模型，它回答地得头头是道。但是你开发调用API，把它包装成公司内部AI助手上线，第一天就收到投诉：引用的制度是两年前废止的版本。
这不是模型"不够聪明"的问题。从一次流畅的演示到一个能持续交付正确结果的AI应用，中间隔着一条完整的软件工程链路。
这篇文章沿着一个内部制度助手从原型到可用的实践过程，分析下一个AI应用的开发过程，一般涉及到哪些方面。
做DEMO简单，但是很难用起来
很多一知半解的人利用AI简单做出个DEMO来，就以为AI很厉害可以快速做出产品，也有很多领导不清楚背后的工程，以为AI这也能实现那也能实现，其实并不是这样的。
假如要做一个内部制度助手。通常是利用大模型的API，把员工的问题直接发过去，让模型回答。演示阶段效果不错——问"年假可以结转吗"，模型给出了详细解释，语气专业，格式工整。
如果真的开始使用。有人问"今年病假扣不扣工资"，模型给了一个言之凿凿的答案，但很可能有会引用的是三年前的旧规定。有人问"我还剩几天年假"，模型编出了一个数字。有人说"帮我提交下周三的请假"，模型回复"好的，已经帮你提交了"——当然背后什么也没发生。
这些失败的共同原因是：模型只是在当前输入的基础上生成文本，它不知道公司今年的制度改了什么，不知道这个人的考勤数据，也没有能力真正提交一份请假单。
怎样才算"回答对了"？
针对前面的这些问题，你可能会找一个更强的模型。
但是在换模型之前，有一个更基础的问题没解决：这个助手在什么情况下算是工作正确？
制度问答看起来简单，拆开看却有好几种不同的要求：
回答年假政策，需要引用的是现行有效的条款，而不是模型训练数据里的旧版本。
回答个人余额，需要的是HR系统里这个人当前的真实数据。
提交请假，需要把申请写入审批系统并返回一个真实的单号。
这三种场景对"正确"的定义完全不同，对应用能力的要求也逐级上升。如果不先把这些标准理清楚，开发会不断陷入"模型回答看起来不错但又说不清哪里不对"的循环。
任务定义不只是写一句话。它包括：
这个助手面对的用户是谁
允许它使用哪些信息来源
回答必须满足什么准确性要求
哪些场景需要执行动作，动作失败了怎么处理。
这些内容和模型无关，但决定了后续每一个技术选择。
每次模型推理，能看到些什么信息？
很多人对大模型有一个直觉上的误解：觉得它"知道很多"，所以应该能回答企业内部的问题。
实际上，模型在每次推理时能看到的信息，只有这一次请求中被送入的内容。这些内容通常包括几个部分：
系统指令告诉它身份和行为规则
用户的问题是当前要处理的输入
如果应用做了检索或工具调用，那些结果也会被放进来
多轮对话中前面的消息也可能被保留
所有这些加在一起，构成了模型当前一次推理的上下文。
上下文有两个容易忽略的特点。
第一，它是有限的。即使最新的模型已经支持很长的输入窗口，把整个知识库或全部对话历史一股脑塞进去，效果往往不好——信息太多反而会让模型在不相关的内容中迷失。
第二，上下文不是记忆。这一次推理结束后，模型不会自动记住任何内容。下一次请求如果不重新提供相关信息，模型就和第一次见面一样。
回到制度助手的例子：如果系统只把员工的问题直接发给模型，模型的上下文里只有这句问题。它不知道公司今年更新了哪些制度，不知道这个员工的部门和入职年限，也不知道前一次对话里已经确认了哪些信息。要让回答准确，就必须在发送给模型之前，把相关的材料组织好放进上下文——这件事不是模型做的，是应用做的。
AI应用获取外部信息
上下文解决了"模型看到什么"的问题，但有些信息不是提前准备好就够的。
员工问"年假可以结转吗"，答案藏在公司的制度文档里。这些文档不在模型的训练数据中，但它们是相对稳定的——可以提前处理、索引，在用户提问时检索出最相关的段落，放入当前上下文。这就是检索增强生成（RAG）在做的事情：在生成回答之前，先从指定的知识源中找到相关依据，让模型基于真实材料回答，而不是凭训练时的印象编造。
但员工接着问"我还剩几天年假"，这就不是检索文档能解决的了。余额是这个人在HR系统里的实时数据，每请一次假就变一次。要获取这个数据，应用必须在推理过程中去调用一个外部接口——查询HR系统，拿到结果，再把结果放回上下文让模型继续回答。
再进一步，员工说"帮我提交下周三到周五的请假"，这已经不只是读取数据，而是要执行一个动作——在审批系统里创建一条申请记录。这个动作有后果：提交成功了要返回单号，提交失败了要告诉员工哪里出了问题。
检索和工具调用是两种不同的外部能力。
检索从已有的知识源中找信息，帮助构造上下文；
工具让应用读取实时数据或在外部系统中执行操作。
两者的风险等级也不同——检索最多返回不够相关的结果，工具调用却可能产生真实影响，比如提交了一份有错误的请假单。
当工具越来越多、接入的系统越来越杂，连接方式本身也需要管理。MCP（Model Context Protocol）就是为此设计的一种开放协议：它规定了AI应用怎样用统一的方式发现和调用外部能力，但它不替应用决定该调用哪个工具、调用顺序是什么，也不负责业务逻辑。协议解决的是连接和交换，业务判断仍然是应用自己的事。
对话的状态和记忆
到目前为止，助手可以查制度、读余额、提交请假。但是每一次这样的交互上下文都是独立的。
员工上午提交了请假申请，下午来问"我上午提交的请假批了吗"。如果系统没有保留上午的交互状态，它不知道"上午的请假"指的是哪一条，只能让员工重新说一遍所有细节。
这就是状态和记忆需要解决的问题。
状态和记忆可以分成两个层面：
短期记忆 通常是一次连续会话中需要保持的上下文——员工说了什么、系统做了什么、当前进行到哪一步。这些信息让同一次对话中的后续回合能自然衔接，而不是每次都从头开始。
长期记忆 长期记忆则跨越不同的会话。这个员工上个月提交过一次加班调休，三个月前修改过紧急联系人，这些信息在未来的某次交互中可能有用——但"可能有用"不等于"应该全部保存"。保存全部聊天记录不是记忆，那只是日志。真正的记忆需要选择：什么信息在未来真正有价值，什么时候把它召回到当前上下文，什么时候更新或删除过时的记录。
记忆不是模型自带的能力，而是应用层面的设计。
模型每次推理仍然只看当前上下文——记忆系统的职责是在合适的时机把合适的历史信息重新放回上下文，让模型以为它"记得"。保存什么、保存多久、什么情况下召回、谁有权查看，都需要应用来决定。
怎样评估应用质量
信息来源、外部能力和状态管理都建好之后，团队面对的最后一个问题是：怎样证明这套系统在持续地正确工作？
依赖主观试用是不够的。产品经理问了十个问题，觉得回答都不错，但这十个问题可能恰好避开了所有边界情况。制度更新了一条，系统还在引用旧版本，可能过了两周才有人发现。工具调用偶尔超时，模型悄悄跳过了提交步骤，用户看到的是"已处理"但实际上什么也没发生。
评测不是上线前做一次验收，而是一个持续运行的质量闭环。
建立评测至少需要几个要素：
一组有代表性的任务 不只是简单的问答，还要包括需要检索的、需要调用工具的、信息不完整的、接口返回异常的。
每个任务对应的成功标准 制度问答是否引用了正确版本，余额查询是否返回了真实数字，请假提交是否拿到了有效单号。
过程检查 评测不只看最终回答，还可以检查过程：模型是否调用了正确的工具，是否在该追问的时候追问了，是否在工具调用失败后做出了合理的回退。这些过程信息——通常称为轨迹——对诊断问题非常有价值。一个回答正确的结果背后可能是偶然命中，一个回答错误的结果背后可能只是检索排序的小问题。
有一点需要特别注意：模型说"我已经帮你提交了请假申请"，这不等于真的提交成功了。模型只是在生成文本，它不知道API有没有返回成功。评测必须去检查真实的环境结果——系统日志、数据库记录、API返回值——而不是模型的自我报告。
这张图展示的是一个最简单的AI应用的核心闭环。
业务任务和成功标准是起点，检索和记忆为当前上下文提供信息，模型基于上下文生成内容或决定下一步，工具连接外部系统执行操作，结果和过程轨迹进入评测环节，评测发现的问题再反馈回系统的各个环节进行改进。
不是每个应用都需要启用图中的全部组件——一个简单的文档问答可能只需要检索和模型，不需要工具和复杂的状态管理。
同样，一个非常复杂的AI项目软件，也远不止图上这些组件模块。
不是所有应用都需要用Agent
走到这里，有些读者可能会想：这不就是在描述一个AI Agent（智能体）吗？
不完全是。Agent是一种特定的运行方式：面对一个任务，由模型根据当前观察决定下一步做什么——可能是调用某个工具，可能是追问用户，可能是在工具返回结果后调整计划。
Agent的核心特征是动态决策：步骤不是预先写死的，而是模型在过程中根据情况选择的。
但很多AI应用并不需要这种动态性。
制度助手回答"年假能不能结转"，只需要检索相关条款再生成回答，步骤固定、路径明确，一个包含检索增强的单次模型调用就够了。查询个人年假余额，调用HR接口取数据再格式化返回，步骤也是固定的，用一个简单的工作流串起来就行。
只有当任务变得真正不确定——比如员工说"帮我请假"，但缺少交接人信息，系统需要追问；追问后发现日期和团队活动冲突，需要建议调整；调整后提交接口超时，需要决定是重试还是换一个方式——这种场景下，步骤无法提前写完，才真正需要Agent来根据中间结果动态决定下一步。
做一个应用选择架构的原则是：
用能解决问题的最简单方案
单次调用能搞定的不需要工作流
固定工作流能搞定的不需要Agent。
Agent带来灵活性，但也带来更高的调试难度、更大的评测范围和更多的不可预测行为。
在很多实际项目中，一个好的RAG管道加上几个固定步骤的工具调用，比一个设计不充分的Agent可靠得多。
进一步学习
前面我们沿着一个制度助手的演进，把一个AI应用的核心链路走了一遍：先定义任务和成功标准，再组织上下文让模型获得正确的信息，通过检索和工具接触外部世界，用状态和记忆支持持续交互，最后用评测闭环持续验证结果。
这条链路不绑定任何框架或产品。无论用哪种模型、哪种开发工具，这些环节的问题都需要回答。
如果你对其中某个环节想深入了解：
大模型的基础概念，可以阅读一文全面看懂什么是大模型（LLM）。
RAG、Agent和MCP这三个概念经常一起出现但容易混淆，下一篇《RAG、Agent、MCP之间到底是什么关系》会用同一项业务任务说清它们各自的角色和组合方式。
如果你已经在用AI编程工具但遇到改动失控的问题，《AI辅助开发不只是工具：规则、上下文和评测体系》讨论的是怎样把这条链路落到软件开发协作中。
Agent的详细组成和运行机制，可以阅读一文看懂什么是智能体（AI Agent）和深入理解AI Agent的7大核心概念。
RAG的完整介绍在一文看懂什么是RAG。
MCP协议的概念和使用方式在一文看懂MCP。
参考资料
Anthropic: Building effective agents — 区分预定义工作流与Agent，增强LLM可结合检索、工具和记忆。
OpenAI: A practical guide to building AI agents — Agent适合需要动态工具调用和护栏的场景。
Anthropic: Demystifying evals for AI agents — 评测需要任务、试验、评分器和轨迹，模型声称完成不等于真实结果。
MCP官方架构文档 — Host-Client-Server架构，定义工具、资源和提示等上下文交换能力。
RAG原始论文 (Lewis et al., 2020) — 把参数化模型与可检索知识结合用于知识密集型生成。