主题分享 / 大模型与智能体

FROM AN ANSWER TO A FEEDBACK LOOP

从回答到完成任务。

先理解回答、工具与反馈循环,再看 Harness、固定流程和完整经营报告架构怎样协作。

熟悉业务,无需技术基础5 幕 · 15–22 分钟 · 导览精选 5 分钟

持续更新的主题 · 内容编辑 2026-09-09

先从你见过的现象出发

前面讲清了模型怎样生成回答、怎样利用资料。现在多一个要求:资料不足时,它能否自己提出下一步调查,并根据返回结果继续工作?

先用经营调查理解通用循环,再进入经营报告的完整业务架构。这样既能知道它能做什么,也能理解每个组件为什么出现。

01

让模型参与下一步决策

接上工具之后,为什么还需要反馈循环?

设想要解释利润下降。一次模型调用只能根据眼前材料回答;接上工具后,可以请求查表或计算;把工具结果交回模型后,它才能根据新证据决定继续查什么。

目标与材料 → 模型提出动作 → 程序校验并执行工具 → 返回观察 → 继续调查或停止。 最后一步回到前面,才形成 反馈循环。

组织这个循环的 Harness 负责准备输入、调度工具、记录进度、检查预算与停止条件。它是围绕模型安排执行的一组机制,不是统一行业标准,也不保证任务一定成功。下面先看三步通用机制;后面的完整业务图再加入流程与公司运行职责。

ONE CANVAS · GROW WITH THE REQUIREMENTS

从一次回答,到根据反馈继续行动

先看一次调用,再接工具,最后让结果返回下一轮。节点位置不变;具体业务流程在后面的经营报告图展开。

通用机制教学拆解 · 来源整理 2026-09-09 · 不代表某一产品的实现或可靠性证明

实线:目标、动作、观察与交付;虚线:预算、验证与停止控制。图中操作均由软件执行。

窄屏可左右滑动图;下方正文和关系表也可独立阅读。

从一次回答,到根据反馈继续行动目标交给模型,模型提出工具动作,软件执行后返回观察;观察进入下一轮,系统依据验证和预算决定继续或交付。 目标与材料请求执行实际结果观察进入下一轮检查与停止提议提交产物或缺口执行证据 目标与材料问题 · 资料 · 约束预先约定验收标准模型理解当前可见信息提出回答或下一步动作待验收产物回答 · 报告 · 缺口人的验收与业务交接受控工具执行校验权限与参数查表 · 计算 · 改文件返回观察与进度成功 · 错误 · 缺证据更新已确认状态验证与停止条件继续 · 求助 · 结束检查预算与交付标准

1 / 一次回答

给模型目标和材料,模型生成回答。一次调用可以满足解释或起草需求;模型说“已查表”不代表系统真的查过表。图中的目标包含约束与验收标准,输出是待检查的产物。

2 / 接上工具

模型提出查询或计算请求,软件检查权限与参数后执行工具。动作是否发生,以工具和外部系统的实际返回为依据。工具可读取资料,也可能改变环境;仅产生一次工具调用,还不能说明系统能持续完成任务。

3 / 反馈与停止

执行结果整理成观察,交回下一轮模型调用;系统更新已确认状态,并根据验收、预算和人工交接条件决定继续或停止。目标、模型、受控工具和返回观察组成闭环;Harness 组织输入、执行与控制,运行状态不等于聊天文本。

例如模型从汇总表看到成本上升,尚无证据证明原因,就应请求授权明细、求助或保留缺口,而不是补写原因。固定 Workflow 可以安排必须经过的阶段,Agent 在需要调查的局部决定下一步。是否增加这些机制,取决于任务要求和维护代价。

完整架构的文字关系与深入入口
从哪里含义到哪里
目标与材料目标与材料模型
模型请求执行受控工具执行
受控工具执行实际结果返回观察与进度
返回观察与进度观察进入下一轮模型
模型检查与停止提议(控制)验证与停止条件
验证与停止条件提交产物或缺口待验收产物
受控工具执行执行证据验证与停止条件
02

把循环组织起来

谁管理进度、错误和停止条件?

模型可能重复尝试、误读工具返回,或在证据不全时宣布完成。Harness 把这些问题变成可执行的规则。

循环里遇到什么 系统怎样处理
材料太多或过时 选择本轮上下文,必要时重新读来源
工具报错 记录失败,反馈可理解的原因,再决定重试或求助
任务做了很久 保存已确认进度,检查时间与调用预算
模型说完成 按预设标准检查产物,区分完成、失败和等待人工
03

让固定流程包住局部循环

什么时候需要完整业务架构?

经营报告还有不可跳过的业务要求:先选定并冻结证据,再起草七章与异常解读,检查后交给人编辑采纳。可以预先确定的阶段由 Workflow(固定流程)组织,需要调查和修订的局部交给 Agent。

下面同一张图逐步增加工具、反馈、固定阶段和运行底座。它解释本案例要求怎样增加;与前面的模型技术历史分开阅读。实现依据见 案例说明。

增加组件也增加接口、维护和运行成本。只需一次调用的任务可以到此为止;简单固定流程也可以用普通程序表达。企业 Runtime 在这里承担跨用户任务承接与运行管理,不能只用一个“记忆”盒子代替。

ONE CANVAS · GROW WITH THE REQUIREMENTS

一份经营报告,架构怎样长出来

同一张图,5 步展开。完整图是本案例的职责全貌;每一步都是需求选择,并非行业能力排名。

案例事实 2026-09-08 · 教学拆解 · 当前单机实现

实线 → 请求、反馈或交付 · 虚线 ⇢ 流程控制或运行约束 · 双向箭头 ⇄ 请求与返回

窄屏可左右滑动图;下方正文和关系表也可独立阅读。

1 / 直接调用模型

业务要求: 给定材料,写一段分析。

新增能力: 应用将材料发给模型,返回文字供人阅读。适合输入齐全的简单任务。

代价与边界: 材料之外的数字和解释不能凭空当作事实。这是教学拆解,不是项目最初版本的历史声明。

2 / 接上受控工具

业务要求: 分析必须找到允许使用的业务证据。

新增能力: 模型提出调用,程序检查范围并执行,将证据返回模型。双向箭头表示请求与反馈,不是模型直接访问数据库。

代价与边界: 要维护接口和证据范围;一次工具调用不自动构成自主 Agent。当前助手读取冻结证据包,不开放生产库、任意 SQL 或 shell。

3 / 形成反馈循环

业务要求: 草稿不合格时,根据具体反馈继续修订。

新增能力: Pi 组织模型、工具和观察的循环;提交工具检查草稿并返回错误。通过才结束,超出轮数、工具次数或时长也会停止。原理见 Agent Loop。

代价与边界: 多轮增加耗时与费用。当前禁用 Pi 通用内置工具,只开放读取证据、提交草稿;这不等于强操作系统沙箱。

4 / 固定流程包住循环

业务要求: 必须先起草,再经过独立校验和存档,不能由模型跳过验收。

新增能力: LangGraph 编排起草与校验两个固定阶段,Pi 位于起草阶段内部。工具反馈帮助修改,交付前的程序复核决定能否保存可交付结果。

代价与边界: 普通代码也能表达这个简单流程;使用框架应衡量收益和成本。当前没有启用 LangGraph 持久检查点恢复。原区域报告的四阶段是另一应用,不能混画。

5 / 接入业务运行底座

业务要求: 不同员工发起自己的任务,能查询、取消、主动重试,结果按权限返回业务系统。

新增能力: Task Hub 统一用户与应用授权、个人凭证、持久队列、执行尝试和产物访问。调用与交付持续检查权限;人工采纳和定稿留在经营观察。Runtime 与 Harness 的职责可能交叠,按实际承担者理解。

代价与边界: 当前单机、单 Worker 串行;重启把遗留执行标为中断,主动重试创建新的尝试,不承诺无缝恢复。完整图是本案例的完整职责,不是最强或唯一架构。高可用、强隔离、多智能体和长期记忆需另行论证。

完整架构的文字关系与深入入口
从哪里含义到哪里
受控业务工具读 / 返回业务证据
业务入口任务固定业务流程
固定业务流程起草智能体循环
智能体循环调用 / 输出大模型 API
智能体循环工具调度 / 观察反馈受控业务工具
智能体循环研究结果草稿验证
受控业务工具检查 / 反馈草稿验证
草稿验证通过交付结果与人工判断
固定业务流程控制:必须复核后存档(控制)草稿验证
业务运行底座 · Task Hub调用前校验权限(控制)受控业务工具
业务运行底座 · Task Hub执行记录 / 产物归属(控制)草稿验证
业务入口冻结汇总业务证据
04

沿经营报告看失败与交付

一次草稿失败,怎样修订与交付?

草稿不合格时,谁发现、谁反馈、谁修改、谁决定停止?沿回放看经营报告怎样起草、修订和交付。

已有试跑曾因修订耗尽时长或轮数;后来开发者改进工具参数与错误反馈,在未延长预算的条件下完成后续实测。回放综合这些记录,展示修订机制,并非一条原始运行日志的逐字复现。

这里区分两种变化:开发者跨次修改系统;Agent 在一次运行中根据反馈修改草稿。前者不能被说成后者自动学会。公开数据与步骤经过教学编排,实际边界见 案例说明。

FOLLOW THE EVIDENCE

经营报告:从证据到人工采纳

合成数据 · 基于项目记录的教学回放 · 非单次原始日志 · 不调用模型

01 / 目标

提出任务

人和业务系统: 选择一份合成报告,明确关注点,期望得到七章草稿及已有规则异常的解释,最终由人采纳。

回放综合既有实现与多次验证记录,步骤经过教学编排,不是原始轨迹逐字复现,也不现场调用模型。

02 / 上下文

准备证据

业务系统: 冻结数据并计算指标,只传入本报告允许的汇总证据。用户补充背景仍是自述,不升级为事实。

运行底座: 核对用户、应用授权与凭证,创建任务,由 Worker 执行。

03 / 工具

读取与起草

Pi 和工具程序: 读取允许的证据,提交结构化草稿。数字使用证据标识占位,由程序插入冻结数值;没有依据的章节说明缺口。

本案例指标计算发生在业务系统中,模型不新增计算,也不联网调查原因。

04 / 失败分支

证据不足或草稿不合格

检查程序: 未读取引用、缺失字段或不合规数字都会阻止通过。Pi: 收到反馈后在剩余预算内修订;无证据的原因保留为假设或交给人核实。

既有试跑发生过反复修订耗尽时长和轮数。失败保留为失败,不以假模型替代,也不自动新开付费任务。

05 / 观察反馈

改进反馈并修订

开发者在不同试跑之间: 把字符串草稿参数改成明确对象结构,批量返回数字问题与具体字段诊断,支持批量读取证据。这不是 Agent 在一次运行中自主修改自身代码。

Pi 在后续任务内: 根据反馈修订草稿。四轮、八次工具调用、三分钟限制没有延长,后续记录出现完整成功。这个观察说明工具与反馈值得优化,不构成单因素因果实验。

06 / 验收

验证与人工采纳

程序: 独立复核章节、异常覆盖、引用和数值占位符,保存草稿与检查结果。人: 看依据、编辑并逐段采纳,业务系统记录来源,形成报告修订。

结构和数值引用通过不证明因果正确。AI 不改指标,也不自动定稿。

07 / 运行状态

中断与下一步

运行底座: 支持取消与主动重试,每次尝试保留产物。已发出的请求可能仍收费;中断状态不等于自动恢复推理现场。

业务判断: 新增并发要求查队列与 Worker;解释缺依据查证据与人工复核;工具频繁报错查接口与反馈。先定位瓶颈,再决定换模型或增加组件。

案例事实日期 2026-09-08。失败与成功来自多次验证;教学步骤不构成成功率、因果正确性或生产可靠性证明。

05

理解新名字的位置

Skill、MCP、Memory 和多 Agent 怎么放?

Skill 提供任务方法与资源;MCP 连接工具与资源;Memory 涉及信息保留与召回;多 Agent 涉及任务拆分与协作。它们补充循环的不同部分,当前经营报告案例没有把这些扩展全部启用。

先定位失败来自数据、工具、上下文、预算还是验证,再决定增加什么。具体扩展与长任务机制在 Coding Agent 篇 展开。任务怎样进入公司流程,见 业务接入篇。

把理解带走

把理解带回自己的问题

Agent 让模型参与下一步行动,Harness 管理循环,Workflow 组织确定的阶段,企业 Runtime 承接运行管理。它们可以组合;选择依据是任务要求、代价与可验证的结果。

试着用自己的话解释

如果草稿数字正确但原因解释错了,该换模型、补资料、改验证还是请业务人员复核?如果十名员工同时提交任务,单 Worker 底座又会遇到什么限制?在图中指出受影响的位置。

文档预览