一个无人付费的金融 Agent 复盘：MoTA 平台上岗位化设计与可信交付

打开现在的 AI 社区，你会发现最不缺的就是各种五花八门的金融 Agent。有的号称全天候盯盘，有的宣称输入股票代码就能预测涨跌，界面清一色做成无所不知的对话窗口。但如果你真正去问头部机构的 PM，几乎没人会把这类工具放进交易决策里。

原因极其现实：没人敢把真金白银押在一个黑盒聊天框里。

这也是我之前做 Agent 时踩过的坑。当时我也做过一个全能 Agent，既能查财报，又能聊估值，还能输出交易信号。结果做完之后，自己都觉得食之无味——边界拉得太宽，在任何一个环节都无法提供可被量化检验的确定性。严肃的金融场景不需要万事通。在真实的投研流水线里，分工不仅极其明确，而且边界极度清晰。

后来 Agent 开发完成之后，它就一直躺在我的服务器里，偶尔自行运行一下，或者由几个朋友拿来试用，没有人付费，也没有人订阅，甚至没有人知道它的存在。我曾经一度认为，问题应该出在模型还不够强上面。

后来我才发现，问题在于一个能够运行的 Agent 与一个可以被人使用的 Agent，两者之间所差的并不仅仅是代码。别人凭什么信任你？数据与密钥存放在哪里？输出内容怎样接入自己的决策流程？如何收费？用户使用之后怎么反馈从而形成飞轮？

对于这一整套环节里的问题，自己开发需要大量时间和精力，直到后来我注意到了 MoTA 这个平台。

角色边界：金融 Agent 为什么不能做成万事通

平台给我的第一个直观感受，是它把角色边界定义得足够清楚。

MoTA 并没有把 Agent 市场做成一个什么都问的助手清单，而是在里面仅仅放置了六个职位：基本面分析师、技术分析师、策略师、投资组合经理、风险经理、交易执行。每个职位负责什么事项，输入与输出卡在哪些地方，上面写得相对清楚。

刚开始使用时我其实有点抵触：我的财报事件 Agent 既看财报文本又生成因子，究竟算基本面分析师还是策略师，真有必要分得这么死板吗？

但这点其实非常重要。在机构里分工本来就是高度隔离的，没人会让一个基本面分析师直接去下单交易，也没人会让撮合执行算法去预测下个季度的行业景气度。很多独立开发者做 Agent 容易陷入通才陷阱：既想分析新闻，又想计算因子，还想给仓位建议，甚至还想直连实盘下单。

边界一旦无限发散，系统就成了黑盒。不仅下游使用者不敢接入，一旦出现回撤，谁也说不清问题出在哪个环节。当把角色定义得足够窄，价值反而更容易被验证，定价逻辑也才能真正成立。

创建 Agent 时选择具体岗位，明确输入与输出边界

核心资产保护：模型与数据不必交给平台

你的模型与数据是否要交给平台处理，这是我最关心的问题。因子与模型是量化最核心的资产，任何要求交出底层源代码或者数据库凭证的第三方平台，我通常都不推荐使用。

平台提供了两种接入方式。托管式是把 Agent 放在 MoTA 的机器上运行，目前支持 Hermes Agent；绑定式则正好相反，Agent 继续保留在你自己的服务器环境里，平台只负责调度。

绑定式还能再分成两种：推送，是平台将任务推送到你的 HTTPS 端点；拉取，则是你的程序主动去领取任务，完成之后再回传，而且公网端点可以不暴露。

方式	Agent 在哪里运行	更适合什么情况
Hosted（托管式）	由 MoTA 托管，当前面向 Hermes Agent	希望快速搞定运行环境、安全扫描、密钥与弹性资源管理
Bound · Push（绑定式 · 推送）	继续跑在创作者自己的服务器；平台向公开端点推送任务	已经有稳定在线服务，并能维护公开端点
Bound · Pull（绑定式 · 拉取）	继续跑在创作者自己的服务器；工作程序主动拉取任务并回传	希望模型与数据留在自己的基础设施，也不想暴露公网端点

我建议使用绑定式拉取，模型与数据都放在自己的环境里，平台只拿到一个结果。

如果你的 Agent 本来就是用 Hermes 做的，那么托管式相对更省事一些。安全扫描、密钥管理以及弹性资源方面的问题，都不需要自己操心。

Agent 接入测试窗口与环境安全扫描配置

工程评测：可信度不能只靠一张回测曲线

在接入之后，Agent 不会直接出现在市场里。托管式会先经过一遍安全扫描。在测试窗口期，一次任务从规划、工具调用、数据读取到最终输出，整个过程创作者都能看得到。之后是标准化评估：格式是否合规、成功率、一致性、平均与最大运行时间、模型调用消耗，再加上对应岗位的能力表现，都在覆盖范围之内。

这套评估证明不了你的策略以后一定能赚钱，它所关注的是更基础的事：这个 Agent 能不能稳定地完成工作，输出能不能被下游读取，调用成本有没有失控。

对于专业用户来说，这比回测年化高更有意义。金融 Agent 的可信度，本来就不该只挂在一张最漂亮的收益曲线上。

评估通过之后，展示资料就可以动手修改：支持哪些市场由自己挑选，月度订阅价格也由你设定。定价页面把订阅收入、平台分成、预计模型调用成本与净收入估算放在一起算给你看，最大订阅数也能自己设置，以免服务能力被突然撑爆。

这样处理之后，定价环节就不必再靠拍脑袋了。一个调用次数多、依赖高成本数据且推理链条长的 Agent，跟一个使用频率低的研究工具定同样的价，在逻辑上本身就说不通。可以先查看单次运行的成本和预计调用数量，然后反向推算出月费与容量上限——这更接近于在运营一项小型量化服务，而不是随手给演示版本标个价格。

当然，完成上架并不代表会有人订阅，有人订阅也不保证后续会产生续费。计费与结算相关的环节平台可以帮你处理，但对于一个缺乏差异化的策略，指望平台替你创造超额收益，并不现实。这一点最好在最初阶段就想清楚。

告别拍脑袋：像精算基金一样管理容量与成本

不少 Agent 项目在上线之后就没有了后续动静，创作者只能看到下载量和页面访问量，至于自己的产出是否对用户决策产生了影响，基本无从知晓。

这些信息，MoTA 都会回传给创作者。每一次运行的完整过程都有对应的会话记录；订阅数、调用次数、收益情况，每个 Agent 的实际运行数据都会被统计功能梳理清楚；建议最终被用户采纳还是驳回，对应的反馈也会记录在案。

举例来说，我开发的财报事件 Agent，在管理层下调业绩预期的情况下，给出的方案往往容易被用户采纳；但进入行情波动剧烈的财报周期时，被驳回的概率就明显上升。这时我就可以去查：是支撑结论的素材不够，还是信息获取速度太慢，又或者是判断条件里漏掉了行情波动与资金流动性。

这比仅仅收到一句「使用效果不错」有价值得多。项目该往哪个方向调整，不再依赖个人主观感觉，而是来自真实使用流程中产生的行为数据。对于打算长期维护 Agent 的人来说，上线只是一个开始。

它不是一个聊天机器人，而是投资流水线上的专属岗位

MoTA 提供的并不是聊天框，而是投资流程中的某一个岗位。Agent 被放上货架之后，投资者通常不会单独打开工具跟它对话。投资者会依据岗位需求、市场环境以及工具表现，在平台里进行筛选，把合适的 Agent 纳入自己的 AI 投资团队。市场研究、信号识别、资产搭配、风险控制、交易执行，分别由对应的 Agent 各管一个板块；参考意见会被送达决策核心，最终是否执行，仍然由人工确认。

正因为如此，MoTA 跟普通的 Agent 商城不是同一类东西。创作者提交的不是一个能回答金融问题的辅助工具，而是一项投资流程中的专项工作能力。职能怎么划分、效果怎么评估、团队怎么配合，最后还有一道人工审核，这些要素组合在一起，才决定了 Agent 输出什么内容、用在什么场景。

平台人才市场，展示不同岗位 Agent 的表现、调用成本与评价指标

什么人适合来当创作者

如果你手里掌握着一套研究模式或信号输出流程，运行得比较平稳，只不过目前仅在内部使用；如果你是做量化研究的个人从业者，想把研究方式做成能够长期订阅的产品，但又不愿意自己搭建引流、收费与结算这一整套系统；如果你手里有分析、策略或者风控相关的 Agent，想在不转移核心模型与数据的前提下对接外部用户——那么 MoTA 值得你花点时间研究一下。

但如果目前只有一套简单的演示，职能划分不够清晰，输出也不稳定，那建议先别急着上架。把研究做扎实，程序调试稳定之后再说。平台能帮你简化商业流程，但最关键的那件事它替代不了你——做出一个让人愿意长期信赖的 Agent。

目前在市面上能见到的金融 Agent 已经不少，但能同时具备三样特点的不多：岗位价值说得清楚，实际调用时保持稳定，还能让用户自愿长期付费。这三样内容，MoTA 创作者平台把它们纳入了同一套流程。接入和托管保障稳定输出，统一的评价标准与公开数据积累信任，人才市场加订阅结算则连接了推广与变现。

平台目前还处于较早的发展阶段，无论是创作者还是投资用户，都还有较大的增长空间。也正因为起步早，职能如何划分、数据怎么使用、市场怎么看，这些问题都还没形成定论。

如果你已经有一个自己长期使用、也被别人切实验证过的金融 Agent，那先别急着写介绍。把它放进真实工作流，让市场来回答两个问题：哪些人会用它，他们为什么愿意持续用它。

让它变成真正可以被使用的 Agent。