1 / 一次回答
给模型目标和材料,模型生成回答。一次调用可以满足解释或起草需求;模型说“已查表”不代表系统真的查过表。图中的目标包含约束与验收标准,输出是待检查的产物。
FROM AN ANSWER TO A FEEDBACK LOOP
先理解回答、工具与反馈循环,再看 Harness、固定流程和完整经营报告架构怎样协作。
持续更新的主题 · 内容编辑 2026-09-09
前面讲清了模型怎样生成回答、怎样利用资料。现在多一个要求:资料不足时,它能否自己提出下一步调查,并根据返回结果继续工作?
先用经营调查理解通用循环,再进入经营报告的完整业务架构。这样既能知道它能做什么,也能理解每个组件为什么出现。
让模型参与下一步决策
设想要解释利润下降。一次模型调用只能根据眼前材料回答;接上工具后,可以请求查表或计算;把工具结果交回模型后,它才能根据新证据决定继续查什么。
目标与材料 → 模型提出动作 → 程序校验并执行工具 → 返回观察 → 继续调查或停止。 最后一步回到前面,才形成 反馈循环。
组织这个循环的 Harness 负责准备输入、调度工具、记录进度、检查预算与停止条件。它是围绕模型安排执行的一组机制,不是统一行业标准,也不保证任务一定成功。下面先看三步通用机制;后面的完整业务图再加入流程与公司运行职责。
先看一次调用,再接工具,最后让结果返回下一轮。节点位置不变;具体业务流程在后面的经营报告图展开。
通用机制教学拆解 · 来源整理 2026-09-09 · 不代表某一产品的实现或可靠性证明
实线:目标、动作、观察与交付;虚线:预算、验证与停止控制。图中操作均由软件执行。
窄屏可左右滑动图;下方正文和关系表也可独立阅读。
给模型目标和材料,模型生成回答。一次调用可以满足解释或起草需求;模型说“已查表”不代表系统真的查过表。图中的目标包含约束与验收标准,输出是待检查的产物。
模型提出查询或计算请求,软件检查权限与参数后执行工具。动作是否发生,以工具和外部系统的实际返回为依据。工具可读取资料,也可能改变环境;仅产生一次工具调用,还不能说明系统能持续完成任务。
执行结果整理成观察,交回下一轮模型调用;系统更新已确认状态,并根据验收、预算和人工交接条件决定继续或停止。目标、模型、受控工具和返回观察组成闭环;Harness 组织输入、执行与控制,运行状态不等于聊天文本。
例如模型从汇总表看到成本上升,尚无证据证明原因,就应请求授权明细、求助或保留缺口,而不是补写原因。固定 Workflow 可以安排必须经过的阶段,Agent 在需要调查的局部决定下一步。是否增加这些机制,取决于任务要求和维护代价。
| 从哪里 | 含义 | 到哪里 |
|---|---|---|
| 目标与材料 | 目标与材料 | 模型 |
| 模型 | 请求执行 | 受控工具执行 |
| 受控工具执行 | 实际结果 | 返回观察与进度 |
| 返回观察与进度 | 观察进入下一轮 | 模型 |
| 模型 | 检查与停止提议(控制) | 验证与停止条件 |
| 验证与停止条件 | 提交产物或缺口 | 待验收产物 |
| 受控工具执行 | 执行证据 | 验证与停止条件 |
把循环组织起来
模型可能重复尝试、误读工具返回,或在证据不全时宣布完成。Harness 把这些问题变成可执行的规则。
| 循环里遇到什么 | 系统怎样处理 |
|---|---|
| 材料太多或过时 | 选择本轮上下文,必要时重新读来源 |
| 工具报错 | 记录失败,反馈可理解的原因,再决定重试或求助 |
| 任务做了很久 | 保存已确认进度,检查时间与调用预算 |
| 模型说完成 | 按预设标准检查产物,区分完成、失败和等待人工 |
让固定流程包住局部循环
经营报告还有不可跳过的业务要求:先选定并冻结证据,再起草七章与异常解读,检查后交给人编辑采纳。可以预先确定的阶段由 Workflow(固定流程)组织,需要调查和修订的局部交给 Agent。
下面同一张图逐步增加工具、反馈、固定阶段和运行底座。它解释本案例要求怎样增加;与前面的模型技术历史分开阅读。实现依据见 案例说明。
增加组件也增加接口、维护和运行成本。只需一次调用的任务可以到此为止;简单固定流程也可以用普通程序表达。企业 Runtime 在这里承担跨用户任务承接与运行管理,不能只用一个“记忆”盒子代替。
同一张图,5 步展开。完整图是本案例的职责全貌;每一步都是需求选择,并非行业能力排名。
案例事实 2026-09-08 · 教学拆解 · 当前单机实现
实线 → 请求、反馈或交付 · 虚线 ⇢ 流程控制或运行约束 · 双向箭头 ⇄ 请求与返回
窄屏可左右滑动图;下方正文和关系表也可独立阅读。
业务要求: 给定材料,写一段分析。
新增能力: 应用将材料发给模型,返回文字供人阅读。适合输入齐全的简单任务。
代价与边界: 材料之外的数字和解释不能凭空当作事实。这是教学拆解,不是项目最初版本的历史声明。
业务要求: 分析必须找到允许使用的业务证据。
新增能力: 模型提出调用,程序检查范围并执行,将证据返回模型。双向箭头表示请求与反馈,不是模型直接访问数据库。
代价与边界: 要维护接口和证据范围;一次工具调用不自动构成自主 Agent。当前助手读取冻结证据包,不开放生产库、任意 SQL 或 shell。
业务要求: 草稿不合格时,根据具体反馈继续修订。
新增能力: Pi 组织模型、工具和观察的循环;提交工具检查草稿并返回错误。通过才结束,超出轮数、工具次数或时长也会停止。原理见 Agent Loop。
代价与边界: 多轮增加耗时与费用。当前禁用 Pi 通用内置工具,只开放读取证据、提交草稿;这不等于强操作系统沙箱。
业务要求: 必须先起草,再经过独立校验和存档,不能由模型跳过验收。
新增能力: LangGraph 编排起草与校验两个固定阶段,Pi 位于起草阶段内部。工具反馈帮助修改,交付前的程序复核决定能否保存可交付结果。
代价与边界: 普通代码也能表达这个简单流程;使用框架应衡量收益和成本。当前没有启用 LangGraph 持久检查点恢复。原区域报告的四阶段是另一应用,不能混画。
业务要求: 不同员工发起自己的任务,能查询、取消、主动重试,结果按权限返回业务系统。
新增能力: Task Hub 统一用户与应用授权、个人凭证、持久队列、执行尝试和产物访问。调用与交付持续检查权限;人工采纳和定稿留在经营观察。Runtime 与 Harness 的职责可能交叠,按实际承担者理解。
代价与边界: 当前单机、单 Worker 串行;重启把遗留执行标为中断,主动重试创建新的尝试,不承诺无缝恢复。完整图是本案例的完整职责,不是最强或唯一架构。高可用、强隔离、多智能体和长期记忆需另行论证。
| 从哪里 | 含义 | 到哪里 |
|---|---|---|
| 受控业务工具 | 读 / 返回 | 业务证据 |
| 业务入口 | 任务 | 固定业务流程 |
| 固定业务流程 | 起草 | 智能体循环 |
| 智能体循环 | 调用 / 输出 | 大模型 API |
| 智能体循环 | 工具调度 / 观察反馈 | 受控业务工具 |
| 智能体循环 | 研究结果 | 草稿验证 |
| 受控业务工具 | 检查 / 反馈 | 草稿验证 |
| 草稿验证 | 通过交付 | 结果与人工判断 |
| 固定业务流程 | 控制:必须复核后存档(控制) | 草稿验证 |
| 业务运行底座 · Task Hub | 调用前校验权限(控制) | 受控业务工具 |
| 业务运行底座 · Task Hub | 执行记录 / 产物归属(控制) | 草稿验证 |
| 业务入口 | 冻结汇总 | 业务证据 |
沿经营报告看失败与交付
草稿不合格时,谁发现、谁反馈、谁修改、谁决定停止?沿回放看经营报告怎样起草、修订和交付。
已有试跑曾因修订耗尽时长或轮数;后来开发者改进工具参数与错误反馈,在未延长预算的条件下完成后续实测。回放综合这些记录,展示修订机制,并非一条原始运行日志的逐字复现。
这里区分两种变化:开发者跨次修改系统;Agent 在一次运行中根据反馈修改草稿。前者不能被说成后者自动学会。公开数据与步骤经过教学编排,实际边界见 案例说明。
合成数据 · 基于项目记录的教学回放 · 非单次原始日志 · 不调用模型
人和业务系统: 选择一份合成报告,明确关注点,期望得到七章草稿及已有规则异常的解释,最终由人采纳。
回放综合既有实现与多次验证记录,步骤经过教学编排,不是原始轨迹逐字复现,也不现场调用模型。
业务系统: 冻结数据并计算指标,只传入本报告允许的汇总证据。用户补充背景仍是自述,不升级为事实。
运行底座: 核对用户、应用授权与凭证,创建任务,由 Worker 执行。
Pi 和工具程序: 读取允许的证据,提交结构化草稿。数字使用证据标识占位,由程序插入冻结数值;没有依据的章节说明缺口。
本案例指标计算发生在业务系统中,模型不新增计算,也不联网调查原因。
检查程序: 未读取引用、缺失字段或不合规数字都会阻止通过。Pi: 收到反馈后在剩余预算内修订;无证据的原因保留为假设或交给人核实。
既有试跑发生过反复修订耗尽时长和轮数。失败保留为失败,不以假模型替代,也不自动新开付费任务。
开发者在不同试跑之间: 把字符串草稿参数改成明确对象结构,批量返回数字问题与具体字段诊断,支持批量读取证据。这不是 Agent 在一次运行中自主修改自身代码。
Pi 在后续任务内: 根据反馈修订草稿。四轮、八次工具调用、三分钟限制没有延长,后续记录出现完整成功。这个观察说明工具与反馈值得优化,不构成单因素因果实验。
程序: 独立复核章节、异常覆盖、引用和数值占位符,保存草稿与检查结果。人: 看依据、编辑并逐段采纳,业务系统记录来源,形成报告修订。
结构和数值引用通过不证明因果正确。AI 不改指标,也不自动定稿。
运行底座: 支持取消与主动重试,每次尝试保留产物。已发出的请求可能仍收费;中断状态不等于自动恢复推理现场。
业务判断: 新增并发要求查队列与 Worker;解释缺依据查证据与人工复核;工具频繁报错查接口与反馈。先定位瓶颈,再决定换模型或增加组件。
案例事实日期 2026-09-08。失败与成功来自多次验证;教学步骤不构成成功率、因果正确性或生产可靠性证明。
理解新名字的位置
Skill 提供任务方法与资源;MCP 连接工具与资源;Memory 涉及信息保留与召回;多 Agent 涉及任务拆分与协作。它们补充循环的不同部分,当前经营报告案例没有把这些扩展全部启用。
先定位失败来自数据、工具、上下文、预算还是验证,再决定增加什么。具体扩展与长任务机制在 Coding Agent 篇 展开。任务怎样进入公司流程,见 业务接入篇。
Agent 让模型参与下一步行动,Harness 管理循环,Workflow 组织确定的阶段,企业 Runtime 承接运行管理。它们可以组合;选择依据是任务要求、代价与可验证的结果。
如果草稿数字正确但原因解释错了,该换模型、补资料、改验证还是请业务人员复核?如果十名员工同时提交任务,单 Worker 底座又会遇到什么限制?在图中指出受影响的位置。