Agent Loop 与工具
用户要求“比较这些论文的结论，再写一段综述”时，模型需要先取得材料，再决定如何组织回答。Agent Loop 把这个过程接成可以继续推进的循环：模型提出工具请求，系统执行，结果进入下一轮判断。
一、一个研究请求怎样循环推进
一次用户消息对应一次研究运行。系统先准备会话、模型、文件范围、历史与工具，随后进入模型循环。主循环设置模型轮次、时间、Token和调用预算。V1.1对需要内容检查的研究任务提前收起外部工具，为正文生成和修改保留轮次。
工具结果回填后，Agent Loop 会将其加入历史，重新组装下一轮输入并检查预算，再调用模型。因此回路返回“准备本轮输入”，让模型在下一次判断时使用新取得的证据。
模型通常使用 tool_choice=auto，自行判断是否需要调用工具。产品指令要求新的研究事实先使用附件或检索文献。程序负责限制可用工具、执行次数和资料范围，模型负责问题拆分、查询表达和内容综合。
| 决定 | 由谁处理 | 对用户任务的影响 |
|---|---|---|
| 本次用哪些论文、什么模型和助手要求 | 用户选择与请求准备 | 确定研究范围和工作方式 |
| 下一步是否检索、查询什么 | 模型在当前工具集合中选择 | 针对问题补充资料 |
| 工具参数怎样执行、结果如何返回 | Tool System | 将模型请求转为实际操作 |
| 已取得的材料怎样写成比较或综述 | 模型 | 决定内容结构和表达 |
| 是否继续执行、是否需要中止 | 循环条件与运行控制 | 管理等待时间、预算和取消 |
一轮外层循环可能包含很多内部模型调用。检索工具会改写查询、判断片段相关性，因此外层轮次与总模型调用次数分别统计。
一次运行可以通过少量外层工具调用，完成检索内部的多次模型和 Embedding 调用。模型取得结果后生成回答；用户继续要求缩写时，系统沿用历史与引用开启新一轮运行。
二、正文生成之后怎样检查
研究回答生成后，系统根据适用规则检查内容。发现事实或证据问题时，检查结果需要指出具体论述和问题，再交给模型修改。检查器返回格式错误或超时时，先重试检查。
V1.1的一次排查中，898字正文已经符合篇幅要求，检查器的解析错误却触发了重写，新稿变成1024字，随后撞到最后一轮限制。修复将检查器技术故障与正文问题分开处理，并为写作和修改保留轮次。
检查结果、重试和最终交付状态一起进入运行记录。复测仍按真实正文评分，检查通过后的事实、条件与引用也要逐项核对。
三、工具的选择、执行与结果回流
模型看到的是工具名称、使用说明和参数结构。系统还会给工具补上用户、材料范围、对话历史等运行信息。它们由服务端提供，不要求模型重新猜测。
同一批中的多个 internal_search 会合并 queries 后执行，避免每个查询各自走一套完整检索。不同工具可以并行执行。工具返回后，系统分别组织面向模型的文本和面向界面的资料；引用关系随结果更新。
| 工具契约中的内容 | 作用 |
|---|---|
name、description、参数结构 |
让模型知道何时调用、需要提供什么 |
is_available 与本轮允许工具 |
决定本轮真正可用的能力 |
override_kwargs |
服务端补充用户、历史、来源编号等信息 |
llm_facing_response |
让下一轮模型理解结果 |
rich_response |
保存来源、文档及界面展示所需信息 |
tool_call_id |
把返回结果与原工具请求对应起来 |
当前研究实例的模型输入中出现了 internal_search、open_url 和 add_memory。助手配置里还有其他工具关联，实际是否提供给模型取决于可用条件和用户设置。普通研究路径使用文献检索；网页读取的访问边界见权限与运行控制，记忆写入见Memory。
工具发生可处理错误时，系统将错误转成模型可理解的结果，模型可以据此调整。主动取消会中止执行。模型没有给出最终回答时，运行会报告失败，避免把一个只有工具动作的过程当作完成。