不做排行榜，先分清“通用执行”与“领域合同”
在金融研究场景里，Agent 的难点正在从“能不能调用工具”转向“如何承担业务责任”。一篇发布于掘金的工程文章，以同一项基金研究任务为切口，对比了 Pi、Claude Agent SDK、LangGraph 与 ETF Agent 的职责边界。文章给出的核心判断并非谁是更强框架，而是把可复用的通用执行能力与必须定制的金融领域规则拆开：前者可以持续接受成熟框架检验，后者则需要由垂类系统长期承担。
这篇素材明确表示，比较不是在相同模型、资料窗口、预算和题集下完成的横向实测，因此不能给出胜率、金融准确率或成本排名。它的参照系只有两个：通用框架官方提供的机制，以及 ETF Agent 已核对实现与原始验收能够支持的具体行为。
在已核对的私有实现中，ETF Agent 的对话研究由自有 Native ModelTurn 循环驱动，模型网关接入多个协议与供应商适配，工具由服务端宿主管理。素材提醒，代码中出现 Claude、Pi 或兼容扩展概念，并不意味着核心执行自动由相应 SDK 接管。因此，把 ETF Agent 简单理解为“Claude SDK 加金融插件”，会低估其在协议、资源、恢复和交付上的投入；把它描述成全面替代三个框架，又会超出现有证据。
文章还区分了私有 ETF Agent 与公开教学实现 Open ETF Agent：前者是持续演进的研究应用，后者的可复现入口固定在 v0.15.2 对应提交，两者不能互相代替。
金融垂类真正要守住的，是权限、来源和结果身份
素材反复强调，金融研究不能只靠工具调用堆砌。真正需要垂类系统负责的，是金融方法、事实与权限关系、研究结果身份以及可核对交付。文章把这类约束称为“领域合同”，并提到账户、scope、来源范围、内容身份、预算和显式取消都应按原合同执行。
在权限生命周期上，当前实现中，Host 已授予的权限在同一 Run 及其恢复中持续有效，不因外部权限表变化重新撤销；新 Run 独立准入。历史撤权案例用于解释当时的问题，不代表当前 Run 内重新授权机制。
这种设计价值在异常分支中更明显。比如底层资料缺失时，系统仍可以确认 A、B 的基准重复和现金约束，但不能编造精确公司级重合度；用户改变新增资金来源时，原现金算式需要重新确定；账户授权撤回后，后续读取和计算应在原权限入口受到限制。素材认为，这类限制只应影响真实依赖，不能把独立成立的分析全部清空。
- 来源不合格时，应在输入接缝阻止其进入计算，而不是让占位内容继续参与分析。
- 报告结果应能表达已知值、缺失条件和局部不足，而不是伪造全通过。
- 恢复机制应围绕承诺的用户结果，而不是把每一次内部状态都原样复活。
自研运行时不是目的，维护成本必须被算清
对于是否需要自有运行时，素材没有给出“必须自研”的结论。相反，它提出自研代码存在，并不是必须永久存在的理由。ETF Agent 的自有执行内核应持续接受 Pi、Claude Agent SDK 和 LangGraph 的替代性检验。
三个通用框架各有可复用位置：Pi 提供轻量和扩展空间，Claude Agent SDK 提供成熟执行能力，LangGraph 提供有状态编排。它们都能承载金融领域逻辑，而不是需要被金融框架整体替代。会话消息、图状态、报告文件和来源版本各有生命周期；当框架已经提供合适存储接缝时，应优先接入，而不是在旁边再建一个竞争的状态真值。
在交付验证上，已核对的受控验收展示了一条链路：合成组合来源经原 MCP 接缝送入真实 Python 方法和渲染器，再通过原 Artifact 仓库保存 HTML，最后经实际 HTTP 处理入口读回相同字节与哈希。素材同时强调，该验证使用合成数据，且未完成完整自然任务的独立金融审查，不能因此宣称私人账户研究已经可用。
这为行业提供了一个更务实的评估方式：判断垂类 Agent 是否值得投入，不是看它拥有多少模块，而是看运行时更换后金融语义是否仍然清楚，专家能力关闭后研究是否仍有可靠基线，报告受到质疑时来源、计算和交付是否能够逐项检查。对金融 Agent 落地而言，这种分层比单纯追求自动化更关键。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/etf-yan-jiu-agent-de-xuan-xing-ti-zhi-xing-ceng-ke-fu-yong
