解析Agent的 Harness设计逻辑（国标制定思路解析之三）
原创 标准编制核心组 2026-11-05 10:28 浙江
Harness设计哲学
关于智能体，本公号发表过以下文章：
第二篇从六项功能、三类执行路径及控制、持续、协作与部署四个方面，梳理了 Agent 的运行架构。本篇沿着一项上海差旅委托这个例子，进一步说明这些架构安排如何落到具体任务中，以及工具、规划、状态、权限和分工上的选择，怎样形成不同的设计取向并影响数据处理。
逻辑出发点：让人工智能推荐几趟去上海的航班，与让它把整趟出差安排妥当，对应着两个不同层级的系统要求。
在前一种要求下，模型根据时刻表输出一份备选名单，即可完成交互。在后一种要求下，系统需要将任务持续推进至交付：核对用户的日历空档与公司差旅标准，完成比价、订座与酒店预订，并将确认单写入日程；次日收到航空公司航班取消的通知后，还需在酒店免费取消截止期限前调整住宿、处理原机票退改并另行预订高铁票，同时通知会议主办方更新预计到达时间。
从“给出一次判断”到“将一项委托持续办妥”，中间需要一整套工程与运行机制的衔接。设想用户提出这样一项日常委托：“帮我安排下周二去上海开会的差旅，控制在公司差标内；如果路上航班有变动，随时帮我调整交通、酒店和日程。”
面对这项委托，大模型自身提供的是在特定信息输入下的理解、推理与判断能力。要把委托真正办成，系统首先得知道要达到什么结果、现在是什么情况，才能判断下一步做什么；有了判断，还得能够执行；执行之后，还得查明发生了什么，再据此决定继续、调整还是停止。任务拖到第二天，进度要接得上；工作复杂起来，需要考虑如何分工；而在整个过程中，行动都要受到相应权限和规则的约束。
围绕大模型把这些安排组织起来的底层运行支撑，通常称为 Harness〔1〕。下文回到这趟上海差旅的起点，从模型的第一个判断出发，逐一阐明这套运行架构如何建立闭环、在各个环节面临何种取舍，又如何由此分化出不同的设计取向。
一、从判断到行动：通过工具接口改变或感知外部环境
回到差旅任务的起点。模型读取会议通知后，作出第一个判断：“先查询下周二上午的日程空档，再检索当天中午前抵达上海的航班。”
这个判断指明了方向，但模型本身既翻不开用户的日历，也连不上航空公司的售票系统。要让工作往前推进，系统必须能够读取日程、查询余票、提交预订并在需要时修改日程。这就需要工具（Tools）。
工具是将模型提出的操作意图转化为外部实际执行的接口。模型输出“查询下周二日程”的请求，日历工具读取日程库并返回空闲时段；模型发起订座请求，票务工具向预订系统提交指令。在模型与底层工具之间，一套运行程序负责识别调用请求、传递参数、接收返回数据，并处理网络超时或余票不足等异常情况。哪怕只是“读取日历”或“查询票价”，在运行系统里也属于实质性行动——向外部系统发起请求并查明事实，直接改变了系统所掌握的信息基础。
怎样给模型配备工具，构成了运行架构的第一项基础抉择：是提供边界明确的专用工具，还是提供可自由组合的通用工具？
专用工具围绕特定业务动作定制而成，例如预先定义“查询指定日期日历”“按航班号提交订座”“提交差旅审批单”三个接口，并规定每一项接口的输入参数、输出格式与操作对象。这种设计使操作的业务含义与参数范围十分清楚，便于运行系统在调用发生前检查参数、实施拦截与记录日志；但一旦遇到没有预先封装的需求——例如某家协议酒店要求在网页弹窗中手动登记随行车辆牌照——专用工具就无法直接处理，需要增加或修改相应接口。
通用工具则向模型开放代码执行器、命令行终端或浏览器操控能力，由模型自行编写脚本处理数据，或像人一样在网页界面中搜索、点击与填写表格。这种设计依托模型的组合能力处理事先未封装的任务，同时也使具体操作效果更依赖模型生成的脚本或操作序列，要求运行系统更加细致地管理它能够接触的资源与产生的影响〔2〕。
即便同样采用专用工具，接口参数怎样设计，也会直接改变数据的流转范围。以提交机票预订为例，开发者可以采用两种不同的接口安排：一种预订接口要求模型在参数中直接填入乘机人的姓名与身份证号；另一种接口则只要求模型传入乘机人档案标识（如 passenger_id），由获得授权的预订组件在后台读取证件信息并向票务系统提交订单。两种安排都能完成订座，但原始证件信息是否进入模型调用窗口却截然不同。这就区分出了三个不能混同的数据范围：业务系统持有哪些数据、工具执行时使用哪些数据，以及模型判断时实际看到哪些数据。
因此，工具的设计粒度与参数结构同时影响两件事：模型通过何种方式表达并组合行动，以及运行系统能够在什么位置、以何种粒度识别并控制行动与数据接触面。
二、从行动到闭环：以核验后的环境反馈更新工作状态
工具发出操作指令后，运行系统紧接着面临第二个问题：怎样解释外部环境的返回结果，并将其转化为下一次判断的依据。
假设票务工具返回了十趟可选航班，预订接口也返回了成功状态码。这时候，差旅安排是否已经取得了进展？还要看返回的具体内容。返回十趟航班，需要核对其中有没有符合公司差标、又来得及赶上会议的班次；收到预订接口的成功回执，则需要按具体协议和接口约定解释其业务含义，区分“请求已受理”“预订记录已建立”与“电子客票已实际出票”〔3〕。系统通过票务服务提供的有效订单状态，核对乘机人、行程及出票情况，再判断相关操作是否完成。
把目前查到的航班与酒店信息、已建立的预订记录、尚未确认的审批和正在等待的外部事项组织起来，就形成了系统的工作状态（State）。它相当于这趟差旅的实时工作账本，其中的每一项记录都带着依据和确定程度：查到某趟航班有余票，记为“已查询”；预订记录已生成但尚未付款出票，记为“待出票”；核实有效票号并与日程完成核对，才记为“已确认进展”。模型做下一次判断时，只有以这份状态账本为依据，才能接上前一次行动。
知道目前发生了什么之后，系统还要将工作状态与用户的任务目标（Goal）持续对照。假设查询结果显示，下周二上午飞往上海的航班全部售罄。单看“周二早班机”这一条路径，原计划受阻了；但只要用户的目标是“周二下午两点准时出现在上海会场”，模型据此转向查询周一晚间航班或周二清晨的高铁班次，同样是在朝着目标推进。
至此，支撑 Agent 持续运行的四个基本要素就连接成了反馈闭环：目标规定要达到什么结果；状态说明目前掌握什么信息、做到了哪一步；思考与决策对照目标与状态选出下一步动作；行动通过工具把选择落实到环境中，其结果再经过观察和核验，更新状态账本，进入下一轮判断。
只要行程尚未配齐，这个闭环就继续运转；需要本人确认付款，就保存状态并暂时挂起；机票、酒店与日程全部核对无误，即可交付预订成果。需要注意的是，此时完成的是预订阶段的交付；由于用户委托中包含“如果路上航班有变动，随时帮我调整”，只要航变处理仍在委托范围和有效期内，系统在交付预订结果后仍需继续保存必要状态，等待后续可能出现的航变事件。如果遇上台风全线停运等客观阻碍无法按时抵达，系统也要明确交代停留在哪一步，并给出备选方案。
人们常说的 Loop（执行循环），指的就是这种依据行动反馈不断修正后续判断的运行机制。循环怎样选择下一步，可以由程序规则决定，也可以由模型判断；同时，系统还需配置明确的完成标准、资源上限与最大迭代次数等停止条件，以防范错误在循环中累积或陷入无效空转〔4〕。
到这里，从单次判断到持续行动的基本闭环已经建立起来了。但要把一趟真实的差旅从头办到尾，光把闭环连起来还不够——系统接下来必须依次解决：循环启动前怎样划清目标与底线（第三节）、推进路线怎样形成与调整（第四节）、跨轮次与跨天的状态怎样接续（第五节）、动手那一刻的权限边界怎样卡死（第六节），以及最终成果怎样核验与分工（第七节）。
三、起跑线上的界定：明确底线条件与目标完成标准
闭环要可靠运行，首先要在起跑线上处理好目标与边界的界定。
用户在用自然语言交办任务时，通常只表达期望得到的结果，不会事先穷尽所有具体情形和操作禁区。“把去上海的差旅安排好”指明了方向，却留下一连串直接影响操作的问题：只坐经济舱，还是允许坐高铁一等座？会场在虹桥还是浦东？为了省钱能不能订“不可取消”的特价房？不同理解会带来不同的工作范围与操作后果。
把所有问题都留到执行中去试探，可能买下不可退的机票造成直接损失；反过来，要求用户在开口委托前填完二十道偏好问卷，又会让代办变得繁琐。这就需要在事前澄清成本与事后返工及越界代价之间作出权衡。合理的安排，是在动手前先明确足以影响整体方向、资金安全和权限边界的事项，把局部实现方法留给运行过程。例如，差旅预算上限、准时抵达会场的截止时间、能否预订不可退改产品，应当在启动前明确；至于先查机票还是先查高铁、用什么排序条件筛选酒店列表，则可以交由模型根据实时查询结果自行决定。如果某个细节歧义只影响草稿阶段的备选行程单，先做出两套合规方案请用户挑选，往往比事前反复追问更有效。
完成标准的设定同样需要服务于真正的交付目标。如果把完成标准简单写成“成功生成一张机票订单和一张酒店订单”，形式上极易由程序自动检查；但一旦系统订了降落浦东机场的航班，而会场位于虹桥且中间只留出四十分钟地面车程，形式上的“订单齐备”并不能满足准时参会的要求。细化完成条件，必须守住用户真正在意的交付结果。
因此，起跑线上的要求需要分别确定两类条件：一类是运行中必须遵守的底线条件，包括已确认的任务范围、资源权限、禁止事项、预算上限和核心交付要求，它们负责划定允许选择的方案范围；另一类是可以权衡的优化目标，如更快、更省、更少打扰人、更能适应变化与更容易核查，用于在底线范围内比较不同方案的得失。调用次数或预算额度用完，可以成为系统停止运行的理由；但只有真正达到交付要求，才有依据宣布任务完成。
四、推进路线的生成：衔接设计期预设流程与运行期动态规划
目标与底线明确之后，系统需要组织从当前状态通往终点的执行路线。
安排一趟常规差旅，核心步骤往往比较固定：先查日历空档，再核对差旅标准，接着预订往返交通和酒店，最后把确认单写入日程。如果一类任务经常重复、关键步骤已经清楚，开发者可以在设计期把它们直接写入程序，并预设分支与异常处理规则：例如预算超标时转入审批环节，遇到无法处理的情况时交给人决定。
即便是预设异常处理规则，也需要结合具体操作的性质来安排。比如遇到接口请求超时，对于“查询余票”这类可安全重复的操作，程序可以直接按策略自动重试；但对于“创建订单”或“扣款支付”这类操作，请求超时可能只是客户端没有收到回执，订单在服务端实际上已经生成。在再次提交之前，系统必须先核对前一次操作的结果或借助防重复执行机制，确认不会重复买票或重复扣款后，再决定重试还是转交人工处理〔5〕。
当任务路线取决于执行途中的新发现时，死板的预设顺序就会受阻，需要为运行时判断留出空间。假设模型在查票时发现，下周二上海有台风预警，上午航班大面积取消，且周二清晨的高铁车票已经售罄，只剩周一晚上的班次。这时，原定的“订周二早班机 → 订周二当晚酒店”路线已经走不通了。系统需要允许调整计划：改为查询周一晚上的高铁、将酒店入住时间往前增加一晚，并回头检查用户周一傍晚是否有其他日程冲突。
规划（Planning）就在这里发挥作用：把目标与当前情况联系起来，安排若干后续步骤。计划可以由人或程序预先给定，可以由模型在运行中形成，也可以在拿到行动反馈后修改。单次需要规划多远，取决于当前信息能够确定多少后续步骤。在还没查清周二上午有没有交通票之前，先花力气去排周二晚上的市内接驳路线并没有实际用处；先走完查票这一步，拿到余票结果后再排后续步骤，更加切合实际。
这也决定了每一步推进中，什么时候应该继续内部推理，什么时候应该立即采取行动。判断依据在于当前的不确定性来自哪里：如果航班时刻表、酒店位置和会场地址都已经拿到手，只是还没算出哪套组合最省时间，继续通过模型推理和比较有助于理清关系；如果根本不知道高铁还有没有余票，在原地反复推测“应该还有票”无法产生新事实，必须先调用查询接口获取外部信息。ReAct 模式强调的正是推理与行动交替进行：利用当前信息作出判断，采取行动取得新信息，再据此生成、跟踪和修改计划〔6〕。
在工程实现上，Graph（图结构）常被用来表达和组织这些处理环节及其衔接关系。图里的节点可以是查询交通、可行性判断、预订酒店或人工确认，连接节点的边可以规定固定顺序、条件分支和退回路径。在 LangGraph 等框架中，节点和衔接逻辑既可以采用普通代码，也可以包含模型判断〔7〕。例如，一张图可以规定“查询交通”节点之后必须回到“可行性判断”节点，再由模型根据余票和天气结果决定下一步是走向“预订酒店”、退回“检索其他出行日期”，还是转交人工确认。图结构搭起了阶段骨架，具体走哪条路线仍在运行中动态形成。
比较工作如何推进，关键就在于看清哪些选择已经交给程序预先固定，哪些选择留给模型在运行时作出，以及模型可以在什么范围内改变既有安排。
五、跨周期的信息与状态管理：调配上下文、恢复挂起任务与沉淀方法
顺着路线往下推进，系统很快会遇到信息调配与跨天接续的问题。
为了挑出合适的住宿，系统在前几步里连续查询了二十家酒店的价格、位置、房型、取消政策和住客评价，积累了几万字的返回记录。到了下一步准备提交机票订单时，这一轮模型调用应该看到什么？
如果把二十家酒店的全部详情原封不动地重新输入模型，大量无关信息可能增加处理负担、推高调用成本，并干扰关键条件（如“下午两点前必须抵达会场”“酒店免费取消截止时间”）的使用，具体效果取决于模型能力、信息组织和调用方式；反过来，如果只留一句过于简略的摘要，万一后面因为航班变动需要更换酒店，又可能找不到此前已经比好价的备选名单。
因此，系统需要分开处理三件事：从外部取回哪些信息、向本次模型调用提供哪些信息，以及为了后续工作保存哪些信息。一种安排是由程序提前整理好当前步骤所需的材料；另一种安排是给模型目录索引和读取工具，由它在需要时按需调取。二者可以结合使用：只把当前选定的酒店和核心时间约束放进当次模型调用，同时把二十家酒店的完整比价记录保存为上下文窗口之外的笔记或索引，等后续需要重选酒店时再按需读取〔8〕。这与第一节讨论的订票接口设计一脉相承——如果底层预订组件能够根据乘机人档案标识直接调取证件号完成订座，那么不仅无关的酒店详情不必塞进上下文，连用户的原始身份证号也无需进入每一次模型推理窗口。
到了第二天上午，时间跨度进一步拉大：航空公司发来一条航变通知——“您预订的 MU5101 航班因天气原因取消”。
此时，前一天订票时的对话早已结束。系统要兑现“有变动随时调整”的承诺，需要两项机制配合：一是将前一天的目标、已出票的订单号、酒店免费取消截止时间及会场日程保存为脱离单次对话的独立任务状态；二是配置能够接收外部通知或定时检查的事件触发机制。模型无需在等待期间一直运行，保存必要状态与接收触发事件共同支持任务在中断后恢复。
任务恢复是否正确，还取决于记录是否完整、如何识别已执行操作，以及怎样核对外部环境在挂起期间发生的变化。例如，前一次操作可能已经在服务端执行成功，只是回执尚未保存；或者收到航班取消通知后，用户已经顺手在手机软件上自行办理了机票退票并买好了下午的高铁，又或者主办方因为台风已经把会议改到了线上。如果系统恢复运行时直接照着昨天的旧记录重做，就可能造成重复购票或产生不必要的退改费用。因此，系统在重新执行写操作前，需要依据可取得的最新订单与日程信息更新状态，并识别尚未确认的事项；由于查询之后外部情况仍可能继续变化，执行关键操作时仍需结合具体接口状态加以核实。
等整趟上海差旅办理完毕，系统留下的信息积累还可以区分为两类：
•一类是当前任务的进度状态（如“本次上海出差已办理原 MU5101 航班退票，并另行预订 G115 次高铁”），用于支持本次委托的接续与核查；
•另一类是以后处理同类工作可复用的方法（如“遇到虹桥机场大面积延误且当日下午有会议时，如何同步核查高铁余票、原机票退改条件与酒店免费取消时限”），用于支持跨任务的经验复用。
保存合适的方法可以减少后续同类任务的重复摸索；保存未经验证或已经过时的方法，则可能把错误带到以后的任务中。为此，系统需要建立针对技能来源、适用条件与使用反馈的审查和版本更新机制，以降低错误或过期方法被持续采用的可能。
六、行动边界的落实：访问隔离、操作控制与可逆性考量
在退改与重订方案形成、准备动手修改订单和支付票款时，运行架构必须确保行动边界在操作发生的那一刻真正生效。
随着接入的工具增加，差旅 Agent 能做的事情越来越多：它可以读日历、查航班、提交订座，也可以调取企业支付接口、退订酒店、给外部联系人发邮件。但用户交办的这项差旅任务，只需要其中一部分能力。模型如果算出购买六千元的头等舱时间最宽裕，就会提出“购买头等舱”的行动理由；但这项操作在实际运行中能否发生，取决于系统的权限配置与运行限制。
在工程实现上，限制措施可以部署在不同位置：
1.工具调用层参数检查
调用程序直接检查操作对象和参数，对超出差标上限或不属于获准舱位的请求予以拒绝；
2.运行环境层访问隔离
通过容器、进程隔离、文件系统权限和网络访问控制，限定当前执行环境能够接触的资源〔9〕；
3.数据服务与业务系统鉴权
日历与票务等底层服务根据访问身份决定放行范围，例如日历服务只返回指定时段是否空闲，不返回其他会议的涉密内容；
4.执行前审批与确认
对需要特定主体决定的事项，在执行前暂停并等待确认。
配置这些限制时，必须检查它们能否覆盖实际可用的操作路径。例如，仅在工具列表里禁用一个名为“写文件”或“支付票款”的专用工具，如果仍然允许模型通过命令行终端任意改写文件，或者操控一个已经登录企业支付账户、开通了免密支付的通用浏览器去点击付款按钮，系统就没有形成完整的限制边界。OpenClaw 的官方文档即分别配置可用工具、执行位置和命令执行审批：执行位置可以是主机、沙箱或节点；是否需要批准，由相应策略决定〔10〕。配置者需要检查这些控制组合能否覆盖实际可用的操作路径。
此外，操作后果的可逆程度也是安排控制方式的重要考量。在本地修改行程单草稿，或者在票务服务支持短时免费锁座的条件下先行锁座，即便后续需要调整，通过回滚本地文件版本或释放锁座即可恢复它们所覆盖的状态（已经发生的其他关联影响仍需分别处理）；而支付不可退改的机票款、在免费取消期过后退订酒店、或向会议主办方发出取消参会的正式邮件，一旦执行就会产生资金扣减或外部业务后果，无法仅靠恢复本地记录来消除。
这里需要把可逆性与授权范围区分开来：可撤销的操作也可能超出既有授权（例如未经允许读取并修改其他项目的本地草稿），难以撤销的操作也可能已经获得明确的事先授权（例如用户在委托时已明确授权在差标内直接出票）。是否允许自动执行或要求再次确认，需要结合授权范围、操作影响、当前证据和适用规则综合判断。
这也说明，工作路线的自主程度与实际操作的资源权限可以分别配置。一个 Agent 完全可以自主决定先查高铁还是先查飞机、如何组合换乘方案，同时在权限上被严格限定为只读指定日历、在未获授权条件下不得动用资金。
七、结果核验与任务分工：依据证据检查成果与组织多执行者协作
即使每项操作都在权限范围内，结果仍然可能不符合目标要求。系统还需要决定用什么证据检查成果，以及检查到什么程度。
如第二节所述，接口回执需要按照业务含义解释；系统据此核对预订、出票和其他相关状态，再判断哪些事项已经完成。在此基础上，将航班预计降落浦东机场的时间、市内交通预计耗时与虹桥会场的开会时间放在一起核算，则支持系统依据当前掌握的信息作出这趟行程是否可行的判断。不同检查覆盖不同层面的问题。Anthropic 对 Agent 评估的讨论，同样区分运行过程记录（Transcript）与环境中的实际结果（Outcome），并根据任务特点组合程序规则、模型评估和人工检查〔11〕。
检查的时机和强度，应根据错误会影响什么来安排。在初步比价阶段，某家备选酒店距离会场稍远，可以先标记为待核实事项继续比较；如果该方案即将进入最终付款和日程锁定，就需要在下单前核实交通耗时与退改条款，既防止错误演变成实际损失，也避免在草稿阶段反复做不必要的核验。
在组织核验时，如果由生成方案的原执行者在同一上下文中直接自检，容易沿用生成过程中的隐含假设。为减少生成过程中的假设对复核的影响，系统可以交由另一个执行者检查，并向其提供适当的证据和检查标准。不过，由于模型评估本身具有非确定性，且两个执行者仍可能使用相同模型或依赖同一份过时材料，复核的独立程度与有效性，取决于它实际使用的信息、标准和核验方法〔11〕。这也将我们带到了运行架构中的多执行者分工（Subagent，子代理）问题。
设想差旅任务扩展为“五天内连续走访上海、杭州、深圳三地，同时核查三地城际交通衔接、比选会场周边酒店并整理三场会议的背景资料”。如果让同一个执行者在同一上下文窗口中串行处理全部事项，几十份时刻表、酒店规则与会议文档堆在一起，既拉长处理时间，也容易增加跨城市信息的相互干扰。这时，主 Agent 可以将“三地交通衔接”“酒店筛选”“会议资料整理”分别委派给不同子代理并行处理，说明各自的任务范围、可用材料与交付要求，最后再把结果汇总为完整行程单。
在架构设计上，子代理分工可以用于并行处理、缩小上下文范围、划分权限和交叉核验，各项效果由任务划分与配套机制共同实现：
•并行推进多条相对独立的查询与整理任务；
•让负责比选酒店的子代理在自身上下文中处理二十家酒店的详细条款，只把筛选出的备选结果传回主 Agent，控制主上下文的信息范围；
•按职责分别配置资源权限，例如给负责“会议资料整理”的子代理分配文档读取权限，而不给它配置票务预订与支付权限；
•安排另一名执行者对照差标与会议时间表复核最终行程单。
分工同时会带来具体的交接与协调成本：主 Agent 委派任务要传递背景，汇总结果要统一口径；如果负责交通的子代理因为晚点把抵达车站调整到了上海松江，而负责订酒店的子代理没有及时收到这一变更，两边汇总时就会出现冲突。因此，是否采用分工，要看拆开后在效率、上下文管理、权限划分或复核上获得的收益，是否超过交接与协调成本。前后步骤紧密依赖的单城差旅，由单个执行者连续完成往往更容易保持全局一致。
八、从架构配置到设计哲学：基础抉择的取舍原则与产品侧重
走到这里，Harness 面临的基础问题已经全部浮现：目标如何明确，信息怎样提供，下一步由谁决定，状态怎样接续，行动如何受限，结果凭什么确认，以及哪些工作值得分给其他执行者。
这些问题之间彼此牵连。一项架构选择会改变系统能够取得的信息、产生的外部影响和核验结果的方式。设计者据此检查现有控制能否覆盖实际操作，并配置相应的访问限制、结果核验、恢复机制或人工决定。例如，决定让模型按需获取材料，就需要提供相应的检索或读取接口；决定让任务在次日收到航变通知时恢复，就需要保存必要进度，并在恢复时核对外部变化；决定开放更通用的操作能力，就需要检查访问隔离、状态恢复与审批机制能否覆盖实际操作路径。可逆性是其中的重要考量，授权范围与操作影响共同决定自动执行和再次确认的条件。
当设计者围绕“工作安排主要在设计时确定，还是主要在执行中形成”，对主要困难出现在哪里、由谁解决困难、愿意为此承担什么成本形成稳定的优先原则，就产生了不同的 Harness 设计哲学。
1.先组织好工作结构，再让模型补足判断
一种取向认为，许多业务要求和必要步骤可以提前明确。开发者先把工作阶段、输入输出、例外处理和检查条件安排好，再让模型承担其中需要理解和判断的工作。
用于差旅管理，系统可以先将材料登记、差标核对、交通与住宿检索、审批与预订等阶段组织起来，同时在检索或比选阶段允许模型自主选择查询方法。Dify 的经典 Agent 节点可以放进工作流的某个步骤，由模型在该步骤中反复决定何时使用哪些工具，体现预设工作结构与局部自主处理的结合〔12〕。这种取向把较多组织工作放在设计期，前期需要梳理业务、编写并维护流程；当任务重复发生、关键步骤稳定时，这些投入可以在多次执行中复用，使工作口径和衔接关系更加明确。
2.先明确目标和边界，再让模型组织求解
另一种取向认为，复杂任务的路线经常取决于中途发现。系统先给出目标、必要背景、可用工具和执行范围，再让模型依据环境反馈决定怎样推进。
用于同一趟差旅，当遇到天气原因停航、需要协调跨城交通与酒店退改时，模型可以根据实时查询结果调整计划重点，决定先处理哪一步以及是否需要拆分任务；系统则支持它取得信息、更新计划、保存进度，并根据证据判断何时交付。这种取向把较多组织工作留在运行期，愿意承担执行中的检索、推理、计划调整与核验成本，以适应难以提前穷尽的路线。Anthropic 的 Harness 设计文章体现了这一方向：随着模型能力提高，重新检查哪些外部预设安排仍有必要，同时继续配置交互、成本和安全边界〔2〕。
用同一趟差旅代办任务作为标尺，可以将这两种设计取向还原为两套可对照的典型配置：
这两套配置并非截然排斥，实际系统可以将二者结合起来：例如固定差旅的交付要求和付款审核阶段，同时允许模型在阶段内部自主探索出行与退改方案。它们的实质差别在于，系统默认按照已经明确的工作结构推进，还是默认由模型根据目标和反馈组织后续步骤。
3.不同产品围绕特定问题形成各自的投入重点
在这两种基本取向之外，不同产品还会根据所服务的场景，把更多工程投入放在闭环的特定问题上：
•Hermes 重视把做事方法留给后续任务（聚焦“工作怎样延续”中的方法复用）。 它提供技能管理工具，使 Agent 能够创建、更新和保存可复用方法，官方文档将这类技能称为程序性记忆〔13〕。如果将这一机制用于差旅场景，系统可以在处理完复杂的退改任务后，将核对退改条件与备选路线的有效步骤保存为技能供后续调用。它解决的是重复摸索问题，同时也使经验的筛选、修正和适时调用成为持续工作的一部分。
•DeepSeek 的 Super-agent 公开原型重视减少人持续照看的负担（聚焦“工作怎样延续”中的后台等待与状态恢复）。 其公开仓库说明提出少占用人的注意力，在成果可用、需要决定或无法完成时沟通；执行机制则安排后台工作、事件监听，以及任务会话、工作目录和待处理消息的保存与恢复〔14〕。如果将这种事件处理与任务恢复机制借鉴到差旅系统中，可以接入航变通知，在后台检索备选方案，并按授权条件向用户报告或请求决定。
•OpenClaw 把多项运行控制交给操作者分别配置（聚焦“工作怎样受约束”中的边界配置）。 系统分别配置可用工具、执行位置（主机、沙箱或节点）和命令执行审批，是否需要批准由相应策略决定〔10〕。这种安排让操作者能够根据场景确定实际操作范围，也要求配置者检查工具开关、执行位置与审批策略之间的衔接能否覆盖实际可用的操作路径。
•WorkBuddy 的 Buddy 应用机制重视提前组织行业经验（聚焦“工作怎样推进”中的能力与方法预置）。 行业伙伴可以把工作模式、提示词、技能、专家和连接器配置为专属工作台，底层复用统一的运行能力，开放平台将其定位为行业 Harness〔15〕。如果用于企业差旅或政企办公场景，伙伴可以将成熟的财务规范、审批制度和内部系统连接器预先配置到工作台中，供模型在具体任务中运用这些既定方法和业务连接。
通过“推进、分工、延续、受约束”这四个共同问题，就能把不同产品的特点放回同一套运行架构中看清全貌：它们把哪类困难放在优先位置，为此怎样组织闭环，又让开发维护、模型运行、环境控制或人工参与分别承担了什么成本。
九、工作怎样组织，也影响数据怎样被处理
回到开头的上海差旅任务。为了让系统协助完成机票预订、酒店安排与航变退改，相关流程涉及读取工作日历，使用姓名、身份证号、手机号、常旅客卡号与支付信息，并在行程调整时向酒店或会议主办方同步更新后的安排。
前文讨论的每一项运行架构安排，在组织工作的同时，也直接影响着主要数据流的去向与处理方式：
首先，工具接口设计与上下文准备方式，共同决定了系统取回的数据、工具使用的数据与进入单次模型调用的数据这三个不同范围。系统是要求模型直接读写乘机人原始身份证号，还是只让模型传递档案标识、由授权组件在后台读取证件完成订座；是仅向模型提供“下周二上午空档”等当前判断所需的信息，还是将大量历史日程与无关比价记录一并送入上下文窗口——这些选择直接划定了模型推理环节的数据暴露面。
其次，任务拆分与子代理分工方式，影响哪些信息被传递给其他执行者。乘机人证件信息与支付凭证是严格限定在预订执行环节，还是在委派任务时随上下文一并传给了负责整理会议资料或查询地面交通的其他子代理，取决于分工时的上下文切分与权限配置。
再次，状态保存、阶段交付与经验沉淀机制，影响哪些内容在单次调用之后继续留存，以及留存的数据如何被再次使用。在完成预订阶段交付后、等待可能发生的航变期间，系统在持久化状态里保存了哪些订单与行程细节，出差彻底结束后又何时清除；在沉淀跨任务技能时，系统保存下来的究竟是通用的退改办理方法，还是包含个人偏好与历史行程细节的记录——这些安排直接决定了数据的留存周期与二次使用边界。
最后，工具策略、访问隔离、状态恢复与结果核验机制，决定了数据处理路径如何受到限制与纠偏。这里同样需要区分两类机制的作用：工具参数检查、运行环境访问隔离、业务系统鉴权与执行前审批，用于在操作发生前限制越权读取、修改或外发；而草稿版本回滚或释放未付款锁座，则是操作发生后恢复局部状态的补救手段，无法替代事前的访问与外发控制。当模型判断失误或受到外部恶意内容诱导时，这些控制措施能否衔接严密、覆盖实际可用的操作路径，决定了安全边界能否真正落地。
当然，Harness 组织并影响着主要数据流，而数据的完整处理轨迹还受到底层模型服务商、工具提供方和外部业务系统自身的权限控制、日志记录与数据保留机制共同影响。看清 Agent 的运行架构怎样把模型推理转化为持续工作，正是接下来逐项辨认个人信息收集、流转、留存与访问控制边界的工程事实基础。
注释
〔1〕关于 Agent 运行支撑体系（Harness）的界定与组成，参见 Anthropic, Agent Harness Design: 3 Patterns for Harnessing Claude’s Intelligence，该文将围绕模型构建的执行循环、工具接口、上下文管理及运行约束统称为 Harness。
来源：https://claude.com/resources/articles/harnessing-claudes-intelligence
〔2〕参见 Anthropic, Agent Harness Design: 3 Patterns for Harnessing Claude’s Intelligence。该文专门讨论了通用工具与专用工具的取舍（通用工具有利于模型组合能力，而参数结构明确的专用工具能够为拦截、审批与审计日志提供明确位置），并提出随着模型自身规划与推理能力提升，应重新检视哪些外部预设安排仍有必要，同时保留对交互、成本与安全边界的控制。
来源：https://claude.com/resources/articles/harnessing-claudes-intelligence
〔3〕在通信协议层面，不同成功状态码代表不同处理阶段，例如 HTTP 200 OK 表示请求已成功处理，其具体含义取决于请求方法；而 HTTP 202 Accepted 仅表示服务端已接受请求但尚未处理完毕，参见 IETF, RFC 9110: HTTP Semantics, Section 15.3.1 & 15.3.3。在航空票务业务层面，创建旅客订座记录（PNR）与实际付款出票（Ticketing）同样属于分立的步骤与状态，需通过订单状态查询接口核实电子客票号是否生成及当前客票状态是否有效，参见 Amadeus for Developers 官方文档关于 Flight Create Orders 与 Flight Order Management 中订座记录与出票状态管理的说明。
〔4〕关于执行循环（Loop）中可能出现的错误累积问题，以及通过设置最大迭代次数、完成条件和资源上限等停止条件来控制运行风险的说明，参见 Anthropic, Building effective agents。
来源：https://www.anthropic.com/research/building-effective-agents
〔5〕在分布式系统与支付、票务接口调用中，网络超时不等于业务操作失败。对创建订单或扣款等非天然幂等操作进行重试，需配合幂等键（Idempotency Key，即由服务端识别多次请求是否属于同一笔业务操作以防止重复执行的机制）及订单状态回查，参见 Stripe API 官方文档 Idempotent requests 与 Error handling。
来源：https://docs.stripe.com/api/idempotent_requests；https://docs.stripe.com/error-low-level
〔6〕参见 Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023（arXiv:2210.03629）。该研究阐述了通过交替进行推理（Reasoning traces）与外部行动（Actions），使模型能够获取外部环境的新信息，并据此生成、跟踪与更新行动计划。
来源：https://arxiv.org/abs/2210.03629
〔7〕参见 LangGraph 官方文档（LangGraph Concepts: Nodes, Edges, and Conditional Edges）。图结构中的节点和路由边既可使用普通确定性代码逻辑，也可调用大模型根据当前状态决定后续流向。
来源：https://docs.langchain.com/oss/python/langgraph/graph-api
〔8〕参见 Anthropic, Effective context engineering for AI agents。该文总结了上下文窗口管理的核心策略，包括将预先注入必要背景与运行时按需检索（保留文件路径、链接等轻量级索引）相结合，以及利用压缩摘要和上下文窗口之外的结构化笔记维持长周期任务连续性。
来源：https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
〔9〕容器（Container）通过操作系统内核提供的命名空间（Namespaces）和控制组（cgroups）等机制实现进程与资源层面的软件隔离，多个容器共享宿主机内核，不同于虚拟机（VM）的硬件虚拟化隔离；同时，容器内进程实际能够接触的主机文件系统范围，直接受挂载配置（如 bind mounts）与进程权限影响。参见 Docker 官方文档 Overview of Docker containers 与 Docker security。
〔10〕参见 OpenClaw 官方文档关于工具策略（Tool Policy）、执行环境（Execution Environment：支持 Host 主机、Sandbox 沙箱或 Node 节点）与命令执行审批（Approvals）的架构说明。文档明确指出，在策略不要求批准的条件下命令可直接运行，同时强调仅禁用单一写入工具而保留不受限的通用命令执行接口，并不能使系统获得只读保障。
〔11〕参见 Anthropic, Demystifying evals for AI agents。该文区分了对执行过程记录（Transcript/Trajectory）的检查与对外部环境最终状态（Outcome）的检查，并指出引入大模型作为评估器（LLM-as-a-judge）具有非确定性，需配合客观程序校验并与人工评估进行校准，单靠引入另一模型评估不能自动构成正确性保证。
来源：https://www.anthropic.com/research/demystifying-evals-for-ai-agents
〔12〕参见 Dify 官方文档关于工作流（Workflow）与 Agent 节点的说明。经典 Agent 节点可嵌入工作流步骤内部自主决定工具调用；同时，现行版本亦支持通过输出路由（Output Routes）等机制由模型参与后续分支选择，因此工作流中预设结构与模型自主决策的具体比例取决于实际编排配置。
来源：https://docs.dify.ai/en/cloud/use-dify/nodes/agent
〔13〕参见 Nous Research, Hermes Agent Documentation 关于技能管理（Skill Management / Procedural Memory）的说明。系统支持在运行过程中创建、更新和保存可复用的方法技能，并在后续任务中按需加载。
来源：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
〔14〕参见 DeepSeek 公开原型仓库说明（GitHub: DeepSeek Super-agent Prototype README）。该原型定位为面向代码仓库的代理系统，监听 GitHub 与即时通讯事件，明确提出减少占用人类注意力的设计目标，并在底层实现了后台执行、事件唤醒以及任务会话、工作目录与待处理消息的持久化恢复机制；正文中的差旅航变监听与改签系将该架构机制迁移至差旅场景的示例说明。
〔15〕参见 WorkBuddy 开放平台文档关于 Buddy 应用体系与“行业 Harness”的架构说明。该机制支持行业伙伴将特定领域的工作模式、提示词、技能、专家及业务连接器预先组织并封装为专属工作台。
END
文章索引
数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过400人。关于DPO社群和沙龙更多的情况如下：
关于我国对人工智能技术和应用的监管发展，本公号发布过以下文章：
关于AI能力扩散议题，本公号发表过以下报告：
针对美国的人工智能监管政策发展，本公众号发表过如下文章：
关于我国《个人信息保护法》的立法、标准化和执法等内容，本公号发表的相关文章包括：
DPO线下沙龙的实录见：
域外数据安全和个人信息保护领域的权威文件，DPO社群的全文翻译：
传染病疫情防控与个人信息保护系列文章
关于数据与竞争政策的翻译和分析：
健康医疗大数据系列文章：
网联汽车数据和自动驾驶的系列文章：
网络空间的国际法适用问题系列文章：
《网络数据安全管理条例（征求意见稿）》系列文章：
《数据安全法》的相关文章包括：
赴美上市的网络、数据安全方面的两国监管乃至冲突方：
个性化广告或行为定向广告（behavioral targeting advertising）系列的文章：
内容安全方面的文章如下：
第29条工作组/EDPB关于GDPR的指导意见的翻译：
数字贸易专题系列：
关于中国数据出境安全管理制度的文章
美国方面的个人信息保护立法的文章：
关于印度的数据保护和数据治理政策和技术文件的文章有：
关于数据的安全、个人信息保护、不正当竞争等方面的重大案例：
关于保护网络和信息系统安全的相关文章包括：
围绕着TIKTOK和WECHAT的总统令，本公号发表了以下文章：
关于我国数据跨境流动监管体制变革的系列文章：
针对审计在数据安全、个人信息保护、AI安全的作用与落地实操，本公众号发布过的文章：
关于中国的网络安全审查制度，本公号发表过的文章：
关于个人信息安全影响评估的文章如下：
围绕供应链安全，本公众号发表文章：
关于AI与标准化工作，本公号发表的文章：
关于新加坡数字化（包括个人信息、网络安全、人工智能等）方面的改革，本公号发表的文章：
关于健康医疗数据方面的文章有：
关于欧盟技术主权相关举措的翻译和分析：
美国利用法律和政策工具单边化地维护或强化美国的安全和经济利益，本公众号曾发表文章：
关于AI技术的系列读书笔记：
本公号发表过的关于数据执法跨境调取的相关文章：
地缘政治与跨国科技公司运营之间的互动影响：
关于AI“情感交互”和“拟人化互动”，本公号发布过以下文章：
关于业务场景中数据跨境流动的文章如下：
关于欧洲的人工智能监管方面的立法、政策和实践方面的文章：
关于人工智能安全和监管，本公号发布过以下文章：
本公号曾发表的人脸识别系列文章：
通过技术增强对个人信息的保护，例如匿名化、假名化技术，隐私增强技术，以及通过技术手段或模式强化个人信息主体的权利实现和意思表达，越来越成为值得关注的主题。本公号曾经发表的文章包括：
关于域外在数据、电信、外国投资方面所建立的国家安全相关的审查机制，本公号发布过以下文章：
本公号发表过的关于数据要素治理的文章有：
关于数据抓取和公开数据保护，本公号发布过以下文章：
关于AI风险治理和数据保护的交叉，本公号发表过的文章：
本文转载自微信公众号「网安寻路人」，查看原文。版权归原作者所有，如有侵权请联系删除。