不依赖开源 Agent 框架时，需要自行实现哪些逻辑？
未标记
考查重点：自建执行循环与状态管理。自行实现上下文适配、模型—工具循环、工具校验执行、状态持久化及预算和终止控制，并留可回放轨迹
本题目录
参考答案
核心回答
不使用开源 Agent 框架，需要自己承担的是把模型决策转成可持续执行、可检查的任务流程，不只是封装一次模型 API。
至少要实现五项职责：
- 模型与上下文适配：组织指令、历史、任务状态和工具定义，解析模型响应及终止状态。
- 执行循环：根据响应决定调用工具、继续推理、等待输入或结束，并控制轮次、时间和成本。
- 工具运行时：注册工具，校验参数和权限，执行调用，把成功或失败结果按调用 ID 回填。
- 状态与恢复：区分会话和任务，保存进度，处理超时、取消、重试，以及外部动作重复执行的问题。
- 验证与观测：检查输出及实际结果，记录关键调用、状态变化、耗时和失败原因，便于调试与回归。
可以继续使用模型 SDK、数据库和现成校验库；不依赖 Agent 框架，不代表所有基础设施都要重写。RAG、长期记忆和多 Agent 编排则按业务需要增加。
展开说明
1. 先把模型调用与工具反馈连成循环
每轮从当前状态构造模型输入，包括有效指令、用户目标、必要历史及可用工具。调用结束后，保存模型的公开回复和结构化工具请求，再判断下一步。
如果有工具请求，就进入工具执行阶段；结果回填后，重新组织上下文调用模型。如果模型给出最终输出，则检查是否满足任务要求。拒绝、输出截断、协议异常和调用失败应分别处理，不能把“这次没有工具调用”一律当成任务成功。
模型适配层还需处理不同接口的响应结构、流式事件和结束原因。流式工具参数应组装完整后再校验执行；供应商要求保留的协议状态也应正确传递，不依赖模型必须公开完整思维过程。
2. 工具调用需要注册表、契约和执行器
建立工具名称到执行函数、参数 Schema 和说明之间的映射。模型返回请求后，先检查工具是否存在、参数是否合法，以及当前调用者能否访问目标资源，再通过适配器执行。
工具结果要对应到具体调用 ID，尤其同一轮有多个工具或多次调用同名工具时，不能按名称猜测。成功结果、参数错误、权限不足、超时等都应有清楚的返回语义，使后续步骤知道应补参数、换路径还是停止。
对于带副作用的工具，还要定义稳定业务幂等标识和结果查询方式。模型调用 ID 用来关联消息，未必能代表跨重试的同一个业务动作。执行权限也由程序控制，不能因为模型提出了调用就直接放行。
3. 状态、上下文和恢复要分清
会话历史让模型知道之前发生了什么；任务状态记录已完成步骤、当前进度、待处理调用及产物。存储键需要区分用户、会话与相应运行，避免多个任务读写同一份可变状态。
长任务要在合适位置保存可恢复状态，选用满足重启和多实例需求的持久化存储。恢复时，除了重新取得上下文，还需确认外部动作是否已经发生。比如请求发出后连接中断，不能仅凭本地没有结果就断定远端没执行；应查询、对账或按业务幂等规则处理。
上下文持续增长时，再加入筛选、摘要和按需检索。完整历史保存下来，不代表每轮都全部发送；压缩后的消息也需要保持工具请求与结果之间的关联。
4. 退出、失败和验证由执行层明确管理
完成条件应与业务目标对应，同时设置最大步骤、总时限和预算。遇到重复行为且没有进展时，反馈原因、调整策略或结束，不能让模型无限重试。
模型请求的修正与网络层重试要分开：非法参数可以作为错误结果反馈，临时网络错误可有限退避重试；权限错误不应通过不断重试解决。任务超时或取消后，还要处理未结束的工具和迟到结果。
输出需要检查格式、必要字段和实际产物；重要业务结果以工具或业务系统状态为依据。记录模型与工具调用的关联、耗时、失败和状态变化，才能区分协议问题、工具错误、上下文缺失及模型判断问题，而不是只保存最终一句回答。
5. 用一个查询任务串起来
以“查询某订单的物流并判断是否需要跟进”为设计示例：程序先确认用户对订单的访问范围，再把订单查询和物流查询工具提供给模型。模型请求查询订单，执行器校验并返回运单信息；模型据此请求物流工具，程序把物流状态按调用 ID 回填，最后检查回答是否依据当前查询结果。
若订单查到了但物流接口失败，任务状态应保留这两种不同结果；可以按策略有限重试或说明信息不完整，不能把“工具都调用过”当作查询已成功。
最初可以先完成单会话、少量只读工具的循环，再用可控的模拟响应检查非法参数、多调用 ID、超时及终止分支。只有业务需要时再增加复杂规划、长期记忆、子 Agent 或跨服务协议，不必一次复制某个框架的全部功能。
常见追问
最简单的 Loop Agent 怎么设计？
保留当前消息和任务状态，循环执行“组装输入 → 调模型 → 判断响应 → 执行工具并回填，或返回结果”，并加上明确的退出与错误处理。最容易漏的是完整保存工具请求、结果按 ID 关联，以及达到上限时返回当前进度和失败原因。
不用框架，还能使用 Function Calling 或 MCP 吗？
可以。Function Calling 提供模型表达调用请求的方式，MCP 提供工具接入协议；工具选择后的校验、执行、结果回填及任务循环仍需应用组织。它们与是否使用 Agent 框架是不同层面的选择。
多工具并行是必须的吗？
不是。有依赖的调用必须等待上游结果；无依赖且执行安全的调用才考虑并行。自行实现时，要管理每个调用的结果、超时和归属，再汇总给模型，而不是简单开几个异步任务就结束。
自己封装与从零开发怎么区别？
可以保留成熟的模型客户端、存储、工具适配和验证组件，只定制业务需要的执行状态与策略。重点是明确哪些职责由现成组件承担、哪些由自己维护。是否值得这样做，可结合框架与自行封装的取舍回答；本题重点是接过了哪些实现责任。
对应教程
- Tools 工具调用：阅读模型请求、程序执行和工具结果回填，理解不用 Agent 框架也必须自行连起来的基础链路。
- Agent 智能体：阅读模型、工具、循环与状态的最小结构，以及检查点和会话归属，反向理解框架替应用封装了哪些逻辑。
参考资料
- 国内：JavaGuide：AI Agent 基础：采用模型接入、工具反馈、上下文和运行循环的职责，说明自行封装超出一次 API 调用的部分。
- 国内：zero2Agent：Loop Engineering：参考结构化调用轨迹、调用 ID、完整流式参数和退出条件，补足手写循环容易忽略的协议细节。
- 国内：WeThinkIn：Agent Harness：参考运行轨迹、最终状态与结果验证维度，说明自建执行层还需提供哪些调试和验收依据。
- 国外：Anthropic：构建有效 Agent：采用环境反馈、工具契约和停止条件的基本机制，说明如何从小的执行闭环逐步扩展。
- 国外：LangChain：Agents：依据框架对模型与工具循环、状态和中间件的封装，说明正文中取消框架后仍需自行承担的控制职责。
