Agent 开发与后台开发有什么不同：从一次请求到长期个人助手
如果已经做过后台应用，第一次接触 Agent 往往会觉得熟悉：接收请求、查资料、调用接口、保存结果，再返回给用户。把模型放在中间，似乎就是一个带自然语言入口的业务系统。
真正的变化出现在运行过程中：下一步做什么，不再全部由开发者提前写好，而可能由模型根据刚刚看到的材料临时决定。 这个决定还会受到上下文、工具描述、历史摘要和用户偏好的影响。
因此，Agent 工程是在成熟的后台工程基础上，接纳一个具有语义不确定性的决策环节。开发者既要让它能探索，也要让每次行动有范围、每次中断能解释、每份成果能取得。到了个人助手阶段，还要让这些约束跨越时间与用户的变化。
本文沿一个教学任务展开：先比较两份基金披露并生成报告，随后把需求扩展为“以后继续帮我关注，有重要变化再告诉我”。前半篇讨论已经可以观察的工程机制，后半篇推演长期个人助手的设计。合成案例不代表真实投资研究或自动交易能力。
公开实现以 2026 年 11 月 3 日核对的 Open ETF Agent v0.19.0 为基线，主流体系采用同日查阅的官方资料。Open ETF Agent 是适合拆解机制的本地教学项目；Claude Agent SDK、Codex、OpenAI Agents SDK 和 LangGraph 则提供不同层次的运行能力。它们在本文中承担比较坐标，不构成产品排名。版本与源码入口
一、从同一个任务，看见控制方式的变化
假设用户说：“比较这两份基金材料，告诉我发生了什么变化，附上来源，保存一份报告。”
规则明确时，后台程序完全可以完成它：读取指定文件，校验日期和字段，执行固定计算，再套用报告模板。遇到缺字段就返回错误，遇到需要人工确认的情况就进入审批流程。这种方案容易测试，也便于复算。
但开放任务可能在读完材料后才暴露真正的问题：两份文件的统计时点不同，某个表格只披露部分项目，所谓“增长”使用了不同的分母。系统需要决定：补读原文、寻找可比口径、换一种分析方法，还是只给出有条件的结论。
这里才出现模型的价值：它可以根据观察提出新的研究动作。与此同时，模型也可能误判缺口、选择错误工具，或者在没有足够依据时写出流畅结论。
| 工程问题 | 规则驱动的业务路径 | 引入模型决策之后增加的责任 |
|---|---|---|
| 下一步怎么选 | 代码、规则、工作流规定分支 | 校验模型临时提出的动作，并观察是否推动任务 |
| 输入怎样影响行为 | 字段及业务状态进入明确逻辑 | 自然语言资料、摘要和工具结果也会改变决策 |
| 状态要保存什么 | 业务对象、事务与流程进度 | 还要保存实际模型输入、原提案、原结果和未知效果 |
| 调用失败怎么办 | 按接口语义重试、补偿或转人工 | 先区分未派发、已完成与结果未知，再决定是否继续 |
| 如何判定完成 | 满足明确业务条件 | 同时检查执行事实、答案质量与用户实际取得的成果 |
| 如何控制成本 | 请求、资源、队列和配额 | 还要约束搜索、摘要、子任务和复核带来的累计开销 |
这些不是两个互斥世界。工作流引擎早已支持动态分支、异步和长期任务，Agent 也完全可以嵌在一条固定流程中。变化在于：部分控制决策由模型产生，而模型的判断条件本身也在不断变化。
二、最小 Agent 是一个观察循环，工程难点在循环之外和交接之中
一次模型请求可能返回答案，也可能返回工具调用提案。运行时接住提案，校验后调用工具，把真实结果放进下一次模型输入。新观察再次改变后续选择，直到交付、等待或停止。
Claude Agent SDK 已把 Claude Code 使用的循环、工具和上下文管理提供给应用；OpenAI Agents SDK 的 runner 也会围绕工具调用、交接和最终输出继续运行。这说明今天未必需要自己从零写一套循环，但仍须理解它把哪些责任交给了应用。Claude SDK · OpenAI runner
以 Open ETF Agent 为例，模型可以提议读取某页、执行计算或保存报告。工具宿主会检查工具范围、文档范围和参数，运行时记录实际派发及结果。模型说“已经保存”，和宿主留下可回读的文件回执，是两种不同的证据。公开运行时与工具实现
工具接口不仅供程序调用，也在教模型如何行动
普通接口的调用方通常按照既定契约编程。模型调用工具时，还会根据工具名称、参数说明和返回格式推断用途。一个叫 query 的万能工具，可能把资源范围、分页、时间口径和失败语义都留给模型猜。
更好的工具表面会让关键区别直接可见。例如“读取已授权文档的某一页”，就比“读取任意路径”更容易限定范围；返回文档版本、页码和完整性信息，也比只返回一段字符串更容易支持后续核查。
Open ETF Agent 的 read_result 回读已经取得的原始结果，而不是悄悄获取同一位置的最新内容；绑定来源的计算保留输入引用，CSV 可以继续消费同一个计算结果。这样，报告中的数字、附件中的数字和当时读到的依据才有机会对上。工具合同
Skill、MCP 与权限回答的是不同问题
Skill 适合封装一种可复用的方法：先查什么、如何比较、遇到缺口怎样处理，以及必要的模板和资源。MCP 提供外部工具与数据接入的协议。它们能改善 Agent 的工作方式，却不自动证明某个动作已经获得当前用户的授权。
这里也不能把某一项目的规则说成所有平台的共同规定。Open ETF Agent 中，Skill 不自行扩大原授权；Claude SDK 则允许宿主根据受信项目或个人 Skill 的 allowed-tools 配置预批准工具，并受组织设置约束。决定权限的是宿主接受的可信配置和策略，外部资料正文不能凭一句指令取得相同地位。Claude Skill 机制
Codex 对另一组区别的表达很直观：沙箱限定执行时可接触的文件、网络等资源，审批策略决定什么时候需要进一步批准。审批通过与执行隔离各有作用，不能用更聪明的模型替代其中任何一项。Codex 执行边界
三、开发者要管理两类状态：系统发生了什么，模型现在看到了什么
后台工程师习惯把数据库当作事实来源。Agent 还多出一份有限的“工作视图”：这次模型请求真正收到的上下文。
某份资料已经存入数据库，不代表模型已经读到它；模型读过某个片段，也不代表之后每一轮都还能看到；摘要中写着“已经验证”，更不能代替原始验证结果。
理解这一区别，可以先分清四种信息，而不急着创建四套服务：
| 信息 | 在任务中的作用 | 不能替代什么 |
|---|---|---|
| 原始证据 | 当时读取的文档、页面、版本与计算依据 | 模型生成的归纳不能反过来充当原文 |
| 执行事实 | 提案、派发、回执、剩余额度与终态 | 聊天摘要不能决定某个操作是否已经发生 |
| 当前上下文 | 本轮模型需要的目标、材料、进展和未解问题 | 它容量有限，不是全部历史的唯一副本 |
| 跨任务记忆 | 以后仍有价值的偏好、事实与经验 | 它不能代替当前指令或操作授权 |
上下文工程由此变得具体：不是把能找到的材料都塞进去，而是选择对当前判断有用、仍然有效、来源清楚的内容。需要时能回读原文，不需要时可以省略。
这也解释了为什么“把上下文窗口做大”不是唯一答案。更大的窗口可以保留更多材料，却不会自动解决内容之间的冲突、旧偏好失效、工具结果诱导或重复研究。选择什么进入下一次请求，本身就是应用行为的一部分。
LangGraph 将线程内的 checkpoint 与跨线程 store 分开；Claude SDK 也明确区分会话历史和文件系统状态，会话恢复或分叉不会自动复制、回滚文件。不同体系的实现不同，但共同提醒我们：恢复对话、恢复计算位置和恢复外部工作成果，不能混用同一个“恢复成功”。 LangGraph 持久化 · Claude 会话
四、任务越长，越要承认“我还不知道发生了什么”
用一个普通后台开发也熟悉的例子：某个获准操作已经发往外部系统，对方可能已经完成，本地却因为断网没有收到回执。
如果它只是查询，重新读取也许可以接受，但新结果仍可能对应另一时点。如果它是发邮件、建订单或修改日历，重新执行就可能制造第二份效果。模型重新“想一遍”解决不了这一信息缺口。
关键分界在派发之前与之后。派发前明确被拒绝，可以在条件允许时修正参数或重试；派发后有可靠结果，就按原结果继续；派发后没有可靠结果，应保留未知，而不是把本地超时翻译成远端失败。
Open ETF Agent 从持久恢复设计开始，就把原 Run 的提案、工具派发、结果提交和结果消费分别记录。完整提案已经保存时，可以继续消费原提案；工具已经派发而结果未知时，不能重新执行来假装恢复。只有明确支持核对的适配器，才可以查询原操作是否完成。原授权、预算和截止时间也不会随着重启刷新。恢复设计 · 运行时恢复分支
这不是通用的外部“恰好执行一次”保证。数据库状态与外部动作通常不在同一个事务里，还需要业务幂等键、结果查询或明确的人工核对路径。LangGraph 官方也提醒：恢复 interrupt() 所在节点时可能重新运行代码，即使副作用放在审批之后，写入已成功、节点尚未完成时的故障仍可能导致重复写入。LangGraph 中断与副作用
对 Agent 来说，这类问题格外容易被“自主重试”的直觉遮住。一个好的运行时有时应该阻止模型继续行动：它需要先把原操作核对清楚，而不是给模型另一次机会猜测。
五、v0.19 的一个真实教训：辅助模型的工作，也会成为失控来源
上下文变长后，常见做法是请另一次模型调用生成摘要，让主任务继续。听起来，摘要只是内部优化。
Open ETF Agent v0.19 的真实验证记录保留了一个反例：报告已经保存，主 Agent 尚未结束，系统又反复生成托管摘要。后续摘要触及本地角色额度时，原请求已经进入 Admission 的派发记录；普通异常不足以证明远端没有发生，因此未知状态仍需保留。保留的失败与设计调整
问题不只是“额度太小”。如果摘要不断处理相同材料，放大额度只是让重复工作持续更久。修复需要回答两个更具体的问题：这份摘要覆盖了哪些原始内容？从上一次摘要到现在，是否真的增加了值得再次处理的证据？
当前实现会保留并校验摘要覆盖范围、原始内容身份，以及来源和 Memory 依赖；没有新证据时可以复用仍有效的工作投影。摘要尝试次数绑定原 Run，并在下一次预约模型之前检查上限。触顶后尝试使用已有有效投影或有界上下文回退；未知结果和有副作用的调用组不会被随意压缩掉。组合合同与摘要实现
这个例子的启发可以迁移到检索、评审和子 Agent：支持主任务的工作，也必须计入同一项任务的责任与资源。 只限制主对话轮数，却让摘要和专家调用无限扩展，仍然可能无法收敛。
Open ETF Agent 当前根预算控制的是模型和工具调用额度，不是已经完备的 token 或货币账本。生产应用还应结合实际提供方用量、时间和费用处理预算；不能把“设置了调用次数”写成“成本已经精确受控”。
六、完成有三个层面，Agent 测试也需要三种观察
对开头的报告任务，至少有三个不同问题：流程是否正确结束，结论是否站得住，用户是否拿到了可读的成果。
工具成功读取文件，只说明文件读到了；保存报告成功，只说明某些字节保存了；报告引用了真实页面，也不能自动证明每句话都由该页面支持。Open ETF Agent 的运行结果保留 semanticStatus: unreviewed，就是把执行完成与语义评审分开。结果与回读说明
因此，传统测试仍然有明确位置：权限、参数、计算、事务、恢复和产物完整性，需要确定性的断言。模型引入的新问题，则要用任务样本检查它有没有找对依据、识别不可比条件、解释不确定性，并在证据不足时适当停止。
最后还要回到用户侧：报告能不能打开，附件与正文是否一致，中途失败后已经保存的阶段成果能否继续阅读。一个界面显示“已完成”，却下载不到文件，依然没有完成交付。
对研究任务，评测不宜机械要求唯一工具顺序。只要许可和业务约束相同，模型可能用不同路径找到相同依据。反过来，轨迹非常漂亮、工具调用很多，也可能没有解决原问题。应把目标完成、依据质量、执行可靠性和成本放在一起观察，避免只优化其中最容易计数的一项。
七、主流 Agent 给出的共同启发：复用运行能力，保留业务责任
看过这些机制之后，再比较框架会更有意义。问题可以从“谁功能多”改成“这项责任由谁承担”。
| 体系 | 本文借它观察的工程选择 | 应用仍要回答的问题 |
|---|---|---|
| Open ETF Agent v0.19 | 用可检查的原始结果、Run 状态和有限组合展示研究执行 | 哪些组合真实支持，哪些只是未来设计；报告是否有业务价值 |
| Claude Agent SDK | 复用 Claude Code 的循环、工具、会话、权限与子 Agent | 如何托管进程、绑定业务身份、接入领域工具并检验结果 |
| Codex | 在实际工作区中执行任务，区分执行边界与审批策略 | 哪些改动符合需求，什么验证足以支持交付，何时允许发布 |
| OpenAI Agents SDK | 在应用内组织模型、工具、交接与最终输出 | 如何保存应用状态、约束外部动作、管理任务级生命周期 |
| LangGraph | 用图状态、checkpoint 与中断组合确定性节点和模型判断 | 哪个节点可安全重做，外部副作用如何去重，业务状态如何演进 |
表中的具体能力来自前文链接的官方资料和固定公开代码；右列是据此提出的工程判断，不代表框架刻意不支持这些方向。
子 Agent 也应放在这个尺度上理解。它可以带着较小的上下文调查一个独立问题，使用专门方法和工具，再向主任务返回结果。Claude SDK 明确提供这种独立上下文；Open ETF Agent 则实现了受限的单层来源核对子任务，保留父级授权与共享根预算。Claude 子 Agent · 公开 Child 实现
并发读取两个文件，用普通并发函数就可能足够。只有子问题需要独立调查、专业方法或明显的上下文隔离时，额外 Agent 才可能值得。增加一个模型角色，也增加了交接、费用和分歧处理；主任务仍需判断它返回的意见是否有依据、是否真的被最终报告采用。
八、从任务型 Agent 到个人助手，变化发生在“以后”两个字里
现在，把最初的请求延长一点：
“以后每周五帮我看看这两份材料有没有更新。优先告诉我会改变原判断的变化，报告短一点，保留来源；没有重要变化就不用打扰我。”
前一个任务的终点是一份报告。这个请求却建立了一段持续的委托：系统需要记住目标，在合适的时间重新工作，理解用户的表达偏好，并判断是否值得通知。
我在本文中把这种服务称为个人 Agent（personal agent）：它围绕同一个人的目标和约束，在多次交互、多个任务和不同时间之间保持连续性。一个保存聊天记录的机器人，或者一个每天执行固定脚本的定时器，都只能覆盖其中一部分。
个人 Agent 需要的连续性至少有三种：执行连续性让系统知道过去发生过什么；理解连续性让它使用当前有效的个人信息；委托连续性让它知道未来还被允许替用户做什么。这是理解职责的三个视角，不要求新建三个独立模块。
接纳长期委托时，自然语言应落到可以检查和修改的约定。下面是教学示意，表示应用在确认相应范围后保存的记录，不是 Open ETF Agent 的现成 API，也不表示模型输出这些字段就能授予权限：
{
"goal": "持续比较两份已选资料的变化",
"schedule": { "timezone": "Asia/Shanghai", "rule": "每周五 09:00" },
"allowedActions": ["read_selected_sources", "save_report"],
"delivery": {
"channel": "in_app",
"notifyWhen": "出现足以影响既有判断的新证据"
},
"preferenceRef": { "id": "research-style", "revision": 3 },
"status": "active"
}“报告短一点”改变呈现；“只看这两份材料”限定来源；“每周五”定义触发；“可以保存”对应动作范围。通知沿用户确认的应用内交付方式发送，通知条件不会给模型开放任意消息渠道。至于“什么变化值得通知”，还需要用户能理解、能调整的判断标准。把这些全部塞进一段越来越长的系统提示词，既难修改，也难解释某次行动依据了什么。
长期目标可以持续，单次执行仍应有边界
一个长期目标可能产生很多次执行，每次执行又包含多次模型请求。三者的寿命不同：目标可能持续数月，一次执行可能持续几分钟或等待一段时间，单次模型请求只处理当前有限上下文。
等待新披露、等待用户补充、等待下一次获准执行的时间窗口时，通常没有必要让模型一直思考。系统可以保存状态，释放执行资源，等待获准事件再次唤醒。持久性的重点是保留责任、原始事实和继续工作的条件。
同时，恢复原执行与新一轮研究要分开。原任务尚未过期且恢复条件满足时，重启进程可以继续原执行；下周收到新资料，往往应该产生关联的新执行，使用新的证据版本和本轮预算。不能通过无限延长同一个 Run，让旧授权和旧截止时间永远有效。
Open ETF Agent 的 Worker 驱动原 Run；普通回复机制保存待回答问题后可以退出驱动；Schedule 则支持确认后的显式唤醒，再交由原 Worker 执行。它们提供了具体的积木，但 v0.19 没有后台常驻调度服务，Response 与 Schedule 也尚无可任意组合的联合等待协议。组合支持边界
这个缺口值得认真看待。支持“到点执行”与支持“等你回答”，并不自动得到“到点开始、遇到问题等待、回复后继续、期间还可取消”的完整生命周期。真正的组合还要处理重复事件、过期回复、撤销和恢复先后顺序。
面向用户的产品已经在呈现相邻能力。ChatGPT 的 Tasks 提供一次性或周期任务以及受支持的事件触发，并允许管理和暂停任务；连接应用本身不会自动创建触发器。这个例子说明长期委托需要明确的触发和管理界面，不能只依赖模型记得一句“以后”。Tasks 官方说明
九、个性化的难点，是用户改变主意以后系统能不能跟上
“记住我喜欢短答案”，是个性化最容易展示的部分。但一个长期助手更常遇到的是变化：用户换了项目、取消了计划，或者只是在这一次希望看到完整推导。
系统应当区分稳定偏好、阶段状态、当前要求和执行授权。偏好可以提供默认值，当前明确要求可以覆盖默认值；阶段状态应有适用范围和失效条件；授权则必须从可信入口取得，不能靠画像推断。
例如，“我一般只看摘要”不意味着用户永远不要细节；“我关注过某个主题”不意味着它值得永久跟踪；“我偏好积极尝试”也不意味着助手可以替用户购买服务或发送消息。
记忆需要来源、范围和可纠正性
个人信息可能来自用户明确陈述，也可能只是一次行为观察或模型推断。这几类信息的可信程度不同。一次点击不宜直接沉淀成“用户长期偏好”，模型推断也不宜在反复转述后变成“用户亲口说过”。
一个有用的设计方向是：让重要记忆能回答“从哪里来、用于什么场景、什么时候更新、是否仍有效”。用户应能查看并纠正它，当前任务也应能选择暂时不用它。不是所有聊过的事情都值得进入长期记忆。
ChatGPT 的官方 Memory 文档已经提供查看、更正和删除相关记忆的说明，也明确区分记忆与原聊天：删除聊天不一定会删除独立保存的记忆。这里说明的是产品中实际存在的管理需求；具体可用能力仍随账户和设置不同。Memory 官方说明
遗忘是一条后续消费链，不能只看数据库里少了一行
假设用户为某个项目保存过“简短报告”的偏好，后来明确把这个项目的偏好更正为“保留完整推导”。即使记忆库已更正，旧偏好仍可能藏在历史工具结果或“用户习惯”的摘要里，再次进入下一轮模型请求。
Open ETF Agent 对带类型的 Memory 身份与版本做了一个有意义的处理：构造后续模型输入时过滤失效内容，并让依赖旧记忆版本的工作笔记失效。它并不只是检查“检索接口这次返回了什么”，还检查旧内容是否从其他已知依赖路径重新进入工作上下文。Memory 投影实现 · 实际输入验证
这里的边界同样具体：已导出的报告仍是历史产物，已经发给模型的字节无法撤回，程序也不能保证自动识别任意自然语言中的所有旧偏好残留。依赖失效是一项可实现的机制，不等于彻底消除所有语义影响。
这正是个性化比“加一个向量数据库”更深的地方。检索解决“找到可能相关的过去”，应用还要决定“这段过去今天是否仍适用”。个人助手越长期，后一个问题越重要。
十、主动性要服务用户的进展，也要保护用户的注意力
一旦允许定时或事件触发，Agent 很容易显得勤奋：每天一份报告，每次变化一条通知，每个模糊问题都来问一次。
但用户委托的是事情，不是接收更多消息。对于开头的任务，如果资料没有更新，重复生成相似报告可能没有价值；如果变化无关紧要，立即推送反而打断用户；如果确实需要决策，只发送一句“有新情况”又把研究负担交了回来。
因此，主动性至少包含三个不同判断：有没有新事实，这个事实是否影响当前目标，以及是否值得现在打扰用户。能够做出建议，也不意味着可以未经相应授权执行建议。
OpenAI 在 2025 年发布 Pulse 时，就展示了根据记忆、反馈和连接应用开展异步研究、再提供个性化更新的方向。本文引用的是这一产品设计，不沿用当时的预览资格来推断今天的可用范围。它提出的工程问题很清楚：过去的兴趣怎样持续服务当前目标，而不是生成永远追着旧项目跑的建议。Pulse 发布说明
一次长期委托，可以由许多安静而有界的执行组成
这个循环可以先用很朴素的技术实现。定时器唤醒任务后，先检查资料版本，以及目标和适用条件是否变化；都没有变化时可以直接等待。有变化再选取必要上下文，请模型处理新的问题。只有达到约定的重要性条件，才生成需要用户阅读的更新。
遇到材料缺失，可以等待来源补齐；遇到必须由用户决定的问题，可以把具体候选和取舍整理好再提问；遇到已派发但结果未知的动作，必须先核对原结果。不同停顿都有真实原因，不应统一变成一个无限旋转的“正在思考”。
用户改变目标时，助手也不能只把新要求追加到聊天末尾。尚未派发的工作应按当前条件重新判断；必要时停止旧任务、建立新的执行。已经发生的效果和未知回执要继续如实处理，不能因为用户说“算了”就从记录中消失。
对这样的个人助手，我更关注几类指标：用户是否少重复交代，重要变化是否被及时发现，交付是否可用，纠正能否影响后续行为，以及无效通知是否减少。这些是本文提出的产品评价方向，不能用单次演示或调用数量来证明。
十一、未来的工程重心，会从运行一个模型扩展到维护一段委托
下面是基于前述机制的判断和展望，不是 Open ETF Agent 已完成的路线承诺，也不是所有厂商都会遵循的统一架构。
软件入口可能更多地围绕目标组织
今天，很多工作需要用户在资料、日历、文件和消息之间搬运上下文。个人 Agent 的一个值得期待的方向，是让用户持续面对同一个目标：打开它，就能看到发生了什么变化、哪些结论需要更新、还差哪项决定。
例如，一个持续研究任务可以在新材料出现后准备差异，在用户回来时提供可核查的更新，再把下一步安排成明确候选。用户主要参与目标调整与关键取舍，工具之间的机械衔接由系统承担。这里是产品设想，不是本文案例已经完成的跨应用能力。
这也意味着应用开发的重点可能变化：除了设计供人点击的页面，还要提供 Agent 能准确使用的业务能力，以及人能理解、能干预的执行记录。界面仍然重要，它承担澄清目标、比较候选和收回委托的职责。
通用运行能力会更容易复用，领域责任仍需要有人承担
当前官方文档已经提供了具体信号：OpenAI Agents API 将 Codex harness 作为托管能力，管理会话、编排、上下文压缩和恢复；Claude 则区分在应用进程中运行的 Agent SDK 与托管的 Managed Agents。OpenAI Agents API · Claude 运行方式对照
据此推断，团队越来越可能复用通用循环、执行环境和持久化基础设施，把更多精力放在“什么才算正确的业务动作”。但托管不等于责任转移：哪些资料可以读取，哪些变化值得提醒，报告采用什么口径，错误结果怎样纠正，仍取决于具体产品。
选型时可以直接问三件事：状态由谁保存，外部效果由谁负责，成功由谁判定。回答清楚，比把框架名称换一轮更能减少后续返工。
用户模型会从自由文本走向可解释、可修订的工作资料
个人 Agent 可能越来越了解用户，但“了解”不宜是一份无法查看的隐形画像。对于会影响重要行为的信息，我更倾向于保留来源和版本，让用户能知道它为什么被使用、怎样纠正、在哪些任务中不应适用。
这不意味着所有偏好都必须建一张复杂关系图。简单助手可以先有几个显式设置；只有当跨任务记忆确实减少重复劳动，并且团队能够处理更正和退出时，再引入更自动的沉淀机制。
反馈也需要谨慎解释。“这次答案太长”可能只针对本次；“这条建议不对”可能是来源问题、方法问题或目标已经改变。不能把每次反馈都直接升级为永久偏好，更不能把一次满意评价当作系统可以自行扩大行动范围的依据。
模型与工具会升级，旧委托却不能被随意改写
长期个人助手可能比某一版模型和工具接口活得更久。系统升级之后，旧任务当时接受的范围、已经发生的效果和尚欠的结果仍然存在。
Open ETF Agent v0.19 的升级规则已经触及这个问题：原运行定义绑定版本；不兼容的旧读取器拒绝新定义；原 PDF 恢复材料需要保留字节与页面，仅保存摘要或 hash 不足以重新得到原现场。读取旧成果与继续旧执行，也有不同要求。升级说明
更长期的产品可能需要让旧任务完成后再切换、保留有限的兼容执行环境，或进行有记录的显式迁移。迁移若改变了任务范围，就要重新取得适用授权。不能把模型升级当作自然语言层面的“意思差不多”，然后默默重解释以前的承诺。
更成熟的自主性，也应包括适当的停止与退出
一个助手可以更主动地寻找资料，也应更容易暂停；可以更准确地使用偏好，也应允许导出、纠正和删除；可以长期追踪目标，也应知道目标已经完成或不再重要。
这会改变产品界面。用户需要看到的不只是对话，还包括当前委托、下一次触发、正在等待什么、已经交付什么，以及怎样修改或结束。对开发者而言，界面本身就参与任务控制，不能只在服务端做完一套机制，再用聊天气泡把所有状态混在一起。
我更倾向于认为，个人 Agent 的成熟标志是有分寸地兑现长期委托：能独立推进的就推进，没有新价值时保持安静，需要用户判断时带来具体材料；用户改变主意后，后续工作也随之改变。
十二、如果今天开始做，哪些能力值得先有，哪些可以等
回到最初的两份材料比较。不要因为未来想做个人助手，就在第一版搭起调度、长期记忆、多 Agent 和自动学习的全套系统。
| 当前真实需求 | 可行起点 | 什么时候值得增加机制 |
|---|---|---|
| 输入固定、规则明确 | 普通服务加确定性工具，必要时只让模型解释结果 | 执行中需要识别未知缺口、选择方法或补充调查 |
| 一次开放任务 | 单 Agent、少量受控工具、明确预算和可回读产物 | 任务跨进程、等人或涉及不能随意重做的效果 |
| 多次交互重复使用偏好 | 先用显式设置与有限范围的记忆 | 自动记忆能带来实质价值，且可以纠正、失效与退出 |
| 有明确独立子问题 | 先验证单 Agent 与普通并发是否足够 | 独立上下文或专门方法确实改善整体交付 |
| 持续关注某个目标 | 明确委托、事件触发、有界执行、通知条件 | 已能可靠完成单次任务，且新一轮确有新增信息或价值 |
所有阶段都需要守住权限和外部效果；它们不能被当作“等产品成熟再补”的可选项。可以延后的，是尚未产生价值的复杂度。
如果想把本文与代码对上，可先按 v0.19 的文档运行离线合成材料比较。需要 Node.js 26.8.1–26.x；下面是该版本文档所列入口，不是本文新增的真实模型实验：
git clone --branch v0.19.0 --depth 1 https://github.com/hpoenixf/open-etf-agent.git
cd open-etf-agent
npm ci --ignore-scripts --no-audit --no-fund
npm run build
npm run demo -- --case document-compareCLI 会输出运行目录，文档约定其中保存 report.md、manifest.json 和 run.jsonl。观察重点可以很具体：报告引用了什么，实际文件能否回读，某一步失败后留下了哪些事实。默认使用脚本化模型 fixture，不需要模型密钥；它适合理解工程链路，不是评估真实模型研究能力。固定版运行说明 · 当前项目入口
当用户只需要一份报告，先把这一份报告交好。当用户说“以后持续帮我关注”，再把目标、记忆、触发和授权延伸到时间里。这样增加的每一项机制，都能回答一个真实的用户问题。
后台工程的积累会继续发挥作用：状态、事务、队列、隔离、幂等、可观测和交付都没有消失。新的挑战，是让一个会根据语言和上下文改变下一步的系统，始终能够解释自己的行动，并跟上用户今天的目标。
延伸阅读与交流
继续沿具体机制阅读，可以选择六层调用全景、超长研究全景、上下文治理行动篇与客户端交互全景。它们分别展开请求交接、持续研究、记忆消费和用户控制；本文的比较与展望可独立阅读。
English edition · 全景系列。如果这些文章与可运行示例对你有帮助，欢迎给 Open ETF Agent 或工程文集一个 Star，也欢迎用具体场景讨论不同的工程选择。