AI Agent 开发 01｜先弄清楚，谁在执行任务

让模型写一个待办应用，它可以给你一整页代码。代码出现在聊天框里，项目目录里却可能什么都没有。要跨过这一步，应用需要接收模型提出的操作，执行文件写入，再把结果送回去。

Agent 开发可以从这件小事开始理解。模型负责判断接下来做什么，程序负责让操作发生。一次操作带来的结果，会影响模型下一次的判断。

这套系列根据冴羽《AI Agent 开发实战》的学习整理稿重新编排，保留原教程来源，并补充工程上的判断。阅读时有 JavaScript 基础就够了。我们会逐步设计一个项目知识库助手，让它读取资料、回答问题、保留引用，最后接上网页。文中的演示数据和项目需求均用于学习。

把一次任务拆开看

用户问项目应该怎样启动。助手首先需要知道当前项目用了什么工具，于是请求读取开发文档。程序检查文件是否允许读取，得到正文，交回模型。模型从正文中发现启动命令，再解释给用户。

这里有三个可以分别检查的结果。模型有没有选对文件，文件函数有没有读到内容，最后的回答有没有忠实使用内容。任何一处出错，都可能让用户拿到错误命令。

工具调用通常以结构化数据表达。下面只是我们自定义的教学格式。

{
  "type": "tool_call",
  "name": "read_project_doc",
  "args": { "path": "development.md" }
}

模型输出这段数据以后，文件仍未被读取。宿主程序要查找工具、验证参数、执行函数，还得等待函数返回。文件内容只能来自这次读取。

把它继续做下去，就得到最基本的执行循环。

接收目标
→ 模型选择行动
→ 程序校验并执行工具
→ 工具结果进入消息历史
→ 模型继续行动或结束

循环需要保存状态。它至少应该知道用户最初要求什么、已经读过什么、最近一次工具返回了什么。否则，下一轮模型可能又去读取同一个文件，也可能丢掉前面刚确认的限制。

学教程时容易一次碰到 Memory、RAG、Workflow 和 MCP。可以先把它们放回刚才的任务。

它们可以组合，也可以单独使用。固定的文档问答可以由程序先检索，再调用模型生成答案。只有当下一步要随着反馈变化时，才需要增加模型选择行动的空间。

例如用户只想查询开发指南中的包管理器，固定检索已经足够。如果用户要求解释一段登录流程，而资料散落在几个文件中，助手可能要先找入口，再追到具体实现。后者更适合逐步观察和行动。

一次请求里通常装着系统规则、用户问题、最近消息、工具说明和检索结果。这些内容共同占用上下文。

把整个项目全塞进去，会增加输入量，也会夹进大量与当前问题无关的内容。只给一小段，又可能缺少决定答案的前提。后面讲的记忆和检索，都与这个取舍有关。

先保留眼下最需要的材料。用户问启动方式，就优先提供开发指南和包管理配置；问某个字段的来源，再去找相关代码。每次补充内容，都应该能解释它为什么与当前判断有关。

历史记录也要按这个原则使用。数据库里保存了一万条消息，只能说明应用存过它们。最终请求实际装了哪些消息，仍由程序决定。

模型写出“已经完成”只是一个信号。文件任务要检查文件，代码任务要检查相关行为，知识问答要检查答案和证据。

停止原因还要分开记录。正常完成、工具失败和达到执行上限，对用户意味着不同结果。让循环最多运行五轮，可以避免无休止地执行；第五轮停下来时，任务可能仍未做完。

这一篇可以做一个纸面练习。把“告诉我项目怎样启动”写成一次执行记录，依次标出模型请求、工具的真实输出和最终答案。然后删掉工具输出，看你还能凭什么确定答案。这一步想清楚以后，再看框架封装的函数会容易很多。

本篇依据冴羽《AI Agent 开发实战》学习整理稿中的概念总览与最小执行机制重写。原教程见冴羽的 Agent 基本概念、JavaScript 最小实现和先动手的学习建议。

系列下一篇会写一个无需模型密钥的离线循环，让请求、执行和回传都能在终端里看见。