Multi-Agent 工程实战与 Persona 设计
一个 7 人 AI 团队全自动炒股一个月的工程经验复盘——重点不是”赚没赚到钱”,而是 Persona 文件怎么写、Agent 协作怎么设计、纯脚本与 AI 怎么分工、踩了哪些坑。
看完这篇你能：理解 Persona 是什么、为什么多 Agent 比单 Agent 更难、四大可复用工程原则、三个典型踩坑、自己上手时从哪起步。
阅读指南
- 只想搞懂 Persona 是什么 → 跳【一】+【六 术语速查】
- 想复用工程原则 → 看【三】(四大原则) +【四】(踩坑)
- 完全没做过 Multi-Agent → 按顺序读
- 想看案例细节 → 看【二】(7 人量化团队)
一、Persona 文件：Agent 的”角色说明书”
1.1 一句话讲清楚
Persona 文件 = 给 Agent 写的岗位说明书 + SOP + 性格设定。
它的作用是把一个通用大模型变成专门干一件事的 Agent。同一个 GPT-5,加载”研究官 Persona”就变研究员,加载”风控官 Persona”就变风控员。
1.2 词源:从面具到 AI 人设(顺便记单词)
Persona 来自拉丁语,原意是古罗马戏剧中演员戴的面具。
| 拆解 | 含义 |
|---|---|
per- | 通过 / 穿过(through) |
-sona | 声音(sound,同源 sonic / sound) |
| 合起来 | ”声音穿过面具传出来”——演员戴上面具,变成另一个角色 |
演化路径(理解这条线,就忘不掉这个词):
拉丁语 persona (面具)
↓
英语 person (人) ← 同源,人就是"戴上人格面具"的存在
↓
心理学 persona (荣格:外在人格)
↓
产品/营销 user persona (用户画像)
↓
AI 工程 agent persona (Agent 人设)
一句话记忆法:“Persona = 面具,戴上就变身。” 演员戴上面具变角色,Agent 加载 Persona 文件变研究官。
1.3 一份典型 Persona 文件长什么样
# 研究官 Persona 示例
name: 研究官
role: 量化研究员
identity: |
你是团队的研究官,负责发现可落地的 Alpha 因子。
你只研究,不交易;只提假设,不下定论。
schedule: "每日 06:00" # 何时被调度
input_sources: # 从哪里获取信息
- arXiv (quant-ph, q-fin)
- GitHub trending (crypto/quant)
- 机构研报(高盛、摩根)
output_format: # 输出契约
- hypothesis: 因子假设
- feasibility: 可执行性评估(1-10)
- expected_improvement: 预期改进指标
decision_framework: | # 决策准则
- 这能让持续盈利更近一步吗?是→执行,否→毙掉
- 不确定时,做最小可行版本
sop: # 标准作业流程
1. 扫描信息源
2. 筛选与当前策略可组合的方向
3. 写成结构化假设推给回测官
4. 一句话日报到飞书1.4 Persona 与 System Prompt 的关系
很多人会问:Persona 文件就是 System Prompt 吗?
答案是:Persona 是 System Prompt 的”加强结构化版本”。
| 维度 | System Prompt(裸提示词) | Persona 文件 |
|---|---|---|
| 形态 | 一段自然语言 | 结构化(YAML/JSON)+ 自然语言 |
| 内容 | 通常只有身份说明 | 身份 + 调度 + 输入 + 输出 + 决策框架 + SOP |
| 复用 | 散落在代码里 | 独立文件,版本化管理 |
| 适用 | 单次对话 | 长期运行的 Agent |
| 对比 | ”你是个研究员” | 完整岗位说明书 |
关键点:Persona 不只是”告诉 AI 它是谁”,更重要的是告诉它”什么时候醒、读什么、输出什么、怎么决策”——这是 Agent 能长期自动运行的前提。
💡 在 Claude Code 生态里,Persona 思想体现为 Skill 文件(参见 Claude Code 扩展生态.md)。
二、实战案例:7 人量化交易团队
2.1 案例来源与定位
来源:LINUX DO 论坛文章《我组了一个 7 人 AI 团队,全职替我炒股——而且我不用管它们》(作者 @Oking,2026-05-17 发布)。
定位:这是工程实践经验,不是投资建议。作者本人在文末明确说:“这套东西离稳定盈利还有很长距离——我们正在优化的那条策略年化只有 14%,离 50% 目标还很远。” 我们关注的是架构和工程方法,不是策略本身。
2.2 团队架构:7 个角色 + 1 个队长
每个角色都是一个独立 Agent,有清晰的分工和触发节奏:
| 角色 | 职责 | 工作时间 |
|---|---|---|
| 🔬 研究官 | 扫描 arXiv、GitHub、机构研报,找可落地的 Alpha | 每日清晨 |
| 🧪 回测官 | 验证研究官的想法,跑两轮牛熊回测 | 按需触发 |
| 🎯 参谋官 | 跟踪市场动态,分析 BTC 多空比、资金费率 | 每日 2 次 |
| 🧠 策略官 | 统筹整个 R&D 流水线,团队大脑 | 每日下午 |
| 🛡️ 风控官 | 6 条风控红线,守住风险底线 | 每日 3 次 |
| 💼 实盘官 | 记录交易、生成日报 | 每日 2 次 |
| 📊 复盘官 | 汇总一周数据,生成周报 | 每周 |
关键设计:策略官是”研发队长”——形成一条 R&D 流水线:
研究官(发现 Alpha)
↓
策略官(调度)
↓
回测官(验证)
↓
风控官(审核)
↓
实盘官(灰度上线)
↓
复盘官(反馈)
↓
循环迭代
这不是一个单次执行的工作流,而是一个每天自动运转的 R&D 流水线。
2.3 R&D 流水线的精确时间表
作者的系统按”接力棒”方式跑日频策略:
06:00 ──→ 12:00 ──→ 18:00 ──→ 次日 09:00
研究官 回测官 风控R&D 实盘部署
每一站都有清晰的输入/输出契约(这就是工程化 Multi-Agent 的核心):
| 角色 | 时间 | 输入 | 输出 | 核心职责 |
|---|---|---|---|---|
| 研究官 | 06:00 | arXiv 论文 + 知识花园 + 开源社区 | 可测 Alpha 因子假设 | 每条带”可执行性评估”和”预期改进指标” |
| 回测官 | 12:00 | 研究官的假设 | 回测报告 + 参数敏感性 + 过拟合检测 | 用历史数据验证,通不过=否决 |
| 风控 R&D | 18:00 | 回测报告 | 签字 / 否决 / 有条件通过 | 满足风控红线(5 大项) |
| 实盘部署 | 次日 09:00 | 风控签字方案 | 灰度上线 + 部署记录 | 把过审策略推上线 |
2.4 真实部署细节(读者关心的”具体怎么跑”)
作者展示的系统真实部署在 Linux 服务器,关键组件:
| 组件 | 用途 |
|---|---|
| 部署目录 | /root/quant-trading/(Linux 服务器) |
| Agent 框架 | 通用 Agent 框架 + Persona 文件 |
| 调度 | cron 管理所有 Agent 的运行时间 |
| 协作 IM | 飞书(“油焖小龙虾”群),既做通知也做交互入口 |
| 共享上下文 | /root/quant-trading/data/daily_context...(每小时打包) |
| 日志格式 | JSON Lines(便于结构化分析) |
| 可替代方案 | 作者提到 “换成 OpenClaw 也没有问题”(参见 Agent 安全攻防.md 中的 OpenClaw 提及) |
整套架构分为三个 Pillar + 复盘体系:
高频基础设施(纯脚本,无 AI 消耗)
┌──────────────────────────┐
│ 看门狗 / 数据采集 / 报告 / 调优 │
└──────────────┬───────────┘
│
┌────────────────────┼────────────────────┐
Pillar 1 Pillar 2 复盘体系
新策略研发(日频) 实盘优化(高频) 事后分析(周)
其中”高频基础设施”是关键的无 AI 层:
| 任务 | 触发频率 | 职责 |
|---|---|---|
| 看门狗 | 每 3 分钟 | 健康检查,bot 挂了自动平仓 |
| 开仓监控 | 每 5 分钟 | 检测新开仓,推送飞书 |
| 小时盈亏 | 整点 | 生成 SL/TP 持仓明细 + 收益快照 |
这一层不调用 LLM——0 token 成本。这就引出了下一章的核心原则:任务二分法。
三、四大工程原则(可直接复用到任何 Multi-Agent 项目)
3.1 原则一:不问只做(Decision Loop 收窄)
痛点:多 Agent 系统最容易出现的死锁是”等用户批准”——研究官产出假设后等用户拍板,然后等用户告诉回测官跑哪个……结果整个团队卡死。
解决:给每个 Agent 一个统一的决策准则——遇到任何决策,先问自己一个问题:
“这能让目标更近一步吗?”
- 是 → 直接执行,事后一句话报告
- 否 → 分析原因,毙掉
- 不确定 → 做最小可行版本(MVP),让数据说话
效果:团队永远不会停下来等批准。研究官发现新论文 → 直接写假设 → 推给回测官。回测官发现没回测引擎 → 直接写引擎 → 重新跑回测。风控官发现回撤超红线 → 直接退回。全程零人工干预。
⚠️ 注意边界:这个原则适用于”信息收敛型决策”(数据能给答案),不适用于”涉及真金白银的关键执行”——后者仍需 HITL(Human in the Loop,详见 程序员黑话速查 · HITL)。
3.2 原则二:任务二分法(纯脚本 vs AI)
这是全文最重要的工程认知:
不是所有任务都需要 AI 参与。纯工程任务由脚本做,AI 只做需要推理的事。
| 任务类型 | 特征 | 方案 | Token 消耗 |
|---|---|---|---|
| 确定性任务 | 固定格式、无推理(数据采集、收益报告、状态检查) | 纯脚本(no_agent) | 0 |
| 推理任务 | 需要判断 / 决策 / 创造(研究、回测分析、策略评估) | AI Agent | 按需 |
作者原话:
我最初让 AI 每小时写一次报告——后来发现完全是在浪费 token。0 token 能解决的事,为什么要花 10000 token?
类比:这就像餐厅的分工——洗碗用洗碗机(机械,确定性),炒菜用厨师(需要判断火候)。如果让厨师洗碗、让洗碗机炒菜,前者浪费,后者出事。
典型分配:
| 任务 | 归属 | 原因 |
|---|---|---|
| 数据采集 / API 调用 | 脚本 | 确定性接口调用 |
| 收益报告生成 | 脚本 | 固定模板填值 |
| 风控状态检查 | 脚本 | 阈值比对 |
| 研究 / 回测分析 | AI Agent | 需要推理 |
| 策略评估 | AI Agent | 需要判断 |
| 复盘归因 | AI Agent | 需要创造性分析 |
3.3 原则三:模型分级(算力按需配置)
不同任务用不同强度的模型——不是所有任务都需要最强模型。
| 任务类型 | 模型档位 | 例子 |
|---|---|---|
| 复杂推理(策略评估、风控审核) | 顶级模型 | Claude Opus / GPT-5 级 |
| 执行型(研究扫描、回测运行) | 快速模型 | Claude Sonnet / Haiku |
| 纯确定性任务 | 0 token,脚本搞定 | 看门狗、报告生成 |
省钱效果:每天几十个自动化任务,token 开销只来自真正需要推理的那几个。
3.4 原则四:共享真相源(Single Source of Truth)
踩坑场景(作者原文最血泪的一段):
早期每个 Agent 自己读交易所数据,导致同一时间点不同角色看到的持仓不一致——实盘官说亏 2%,风控官说亏 5%。原因只是 API 请求时间差了 3 秒。
解决方案:
交易日志(JSON Lines)
↓
每小时自动打包
↓
共享上下文文件
↓
所有 Agent 读同一份
↑ ↓
└── 闭环反馈 ←── 新交易 ←── 参数调优 ←── 策略覆盖
类比:这就像公司开会,所有人看同一份 PPT,不能各自带自己的版本来吵——否则讨论的根本不是同一回事。
实现要点:
- 每个 Agent 不直接调用外部 API,统一从快照文件读
- 快照由一个”数据采集脚本”统一维护(确定性任务,无 AI 消耗)
- 时间戳明确,确保所有 Agent 看到的是”同一时刻”的状态
🔗 这条原则与 Harness 工程与 Agent 解剖.md 的”五层架构”中的记忆层思想一致——记忆/状态必须有统一管理。
四、三大踩坑教训(都是 Multi-Agent 系统的典型雷区)
4.1 教训一:数学错误能毁掉一切
Bug 描述:最早的回测引擎手续费按”总权益”收,而不是按”仓位价值”收。
后果:500 笔交易多扣 36% 手续费,所有回测结果作废。修复后,之前看着赚钱的策略变成了亏损。
教训:
- AI 不会算数(精度问题),关键计算必须人工审计
- 一个数学 bug 可以让整个团队做两周无用功
- 回测引擎的每一行代码都需要单元测试
💡 这也是为什么原则二:任务二分法中”数学计算”必须归脚本而非 AI。
4.2 教训二:本地状态 ≠ 真实执行
Bug 描述:写了止损 / 止盈 / 追踪止的逻辑,但退出路径从未真正调用交易所的平仓 API——只更新了本地状态和日志。
后果:所有声称的平仓在交易所上从未执行。本地账本和真实持仓出现”鬼影”差异。
发现方式:对账——检查交易日志 vs 实际持仓,发现不一致。
教训:
- 本地模拟和真实执行之间有一条鸿沟
- 每个关键的 side-effect(副作用)操作都要写
"actually calling API"之类的确认日志 - 必须有定期对账机制(本地账本 vs 真实账户)
改写成通用规则:
🚨 关键执行操作必须留下”我真的执行了”的物证——不只是写”已执行”日志,而是写”调用了哪个 API、收到什么响应、外部状态变成了什么”。
4.3 教训三:多 Agent 数据漂移
Bug 描述:见原则四:共享真相源 的引子——每个 Agent 独立读 API 导致 3 秒时间差让风控数据漂移。
通用化教训:
- 多 Agent 系统必须有统一的状态快照机制
- 不能让每个 Agent “用自己的眼睛看世界”——它们的眼睛会因为网络延迟、API 限流等原因看到不同的世界
- 这条与单 Agent 系统完全不同——单 Agent 只有一个时间线,Multi-Agent 必须显式同步
五、给 Multi-Agent 开发者的 5 条建议
来自作者的实战总结,经过我们的讨论提炼:
5.1 先有工程基础,再上 AI
交易系统是工程问题。数据采集、订单执行、风控基础设施搞不定,加再多 AI 也没用。
通用化:**Multi-Agent 项目 80% 的工作量在工程,20% 在 AI 调优。**先把脚本层、日志层、状态层搭好,再考虑往哪里塞 Agent。
5.2 Persona 文件决定一切
团队好不好,核心看每个角色的 Persona 定义够不够清晰——
- ❌ 模糊版:“帮我做研究”
- ✅ 工程版:“每天 06:00 扫描这些源,输出这个格式,按这个决策框架判断”
参见一、Persona 文件的 YAML 模板。
5.3 别高估 AI 的能力
AI 擅长推理和决策,但完全不会:
- ❌ 执行交易(有延迟和精度问题)
- ❌ 算数(浮点精度、累加误差)
- ❌ 记账(状态保持)
让 AI 做它擅长的事,其他交给脚本。
5.4 从最简单的闭环开始
不需要一开始就 7 人团队。
推荐起步路径:
- 先让一个研究 Agent 每天产出简报
- 把简报手动喂给回测脚本
- 等跑通了再加第二个 Agent
- 等协作稳定了再加自动化调度
💡 这与 Eval 测评体系.md 的”小白第一周落地路径”思想一致——能跑的最小闭环 > 设计完美的大系统。
5.5 日志就是一切
没有结构化日志的系统是不可调试的。
| 必须记录 | 用途 |
|---|---|
| 每笔交易 | 对账 / 复盘 |
| 每个决策 | 归因分析(为什么 Agent 做了这个选择) |
| 每个错误 | 故障排查 |
| 每次 API 调用 | 验证真实执行 |
后续的分析、调优、归因全靠日志。建议用 JSON Lines 格式——既便于程序读,也便于人扫一眼。
六、术语速查
| 术语 | 英文 | 一句话解释 |
|---|---|---|
| Persona | Persona | ”角色面具”——给 Agent 写的岗位说明书 |
| Persona 文件 | Persona File | 结构化的 Agent 定义(身份 + 调度 + 输入 + 输出 + SOP) |
| System Prompt | System Prompt | 系统提示词,Persona 的简化版形态 |
| 不问只做 | Decision Loop Closure | 给 Agent 收窄决策权,避免”等批准”死锁 |
| 任务二分法 | Task Bifurcation | 确定性任务→脚本,推理任务→AI |
| 模型分级 | Tiered Model Routing | 不同任务用不同强度模型 |
| 共享真相源 | Single Source of Truth | 多 Agent 读同一份状态快照 |
| R&D 流水线 | R&D Pipeline | 研究→回测→风控→实盘的接力工作流 |
| 灰度上线 | Gradual Rollout | 新策略小仓位试运行,而非一次性切换 |
| Pillar | Pillar | 系统支柱,本案例分新策略研发与实盘优化两根 |
| HITL | Human In The Loop | 人在环——关键操作仍需人工确认 |
| Side Effect | Side Effect | 副作用,指会改变外部世界状态的操作(如下单) |
七、与本知识库其他章节的关联
本文档与已有笔记形成的知识网:
- 什么是 Agent.md § 8.2 — 给出了”单 Agent vs 多 Agent”的抽象对比;本文是该节的实战延伸,展示多 Agent 真正长什么样。
- Harness 工程与 Agent 解剖.md § Agent 五层架构 — 编排层 / 记忆层 / 大模型 / 执行层 / 反馈层,本文的”共享真相源”对应记忆层,“任务二分法”对应执行层与大模型的分工。
- Agent 发展轨迹四阶段.md — 多 Agent 协作是第四阶段 Harness Engineering 的高级形态,本文是该阶段的具体落地例。
- Eval 测评体系.md — 7 人团队里的”复盘官”实际上就是在做 Eval 工作(LLM-as-Judge + 离线 Eval)。
- Agent 安全攻防.md — 案例中提到的 “OpenClaw” 在该笔记中作为安全测试工具被提及;此外”原则四 共享真相源”也是防”数据投毒”的基础设施。
- Claude Code 扩展生态.md — Persona 思想在 Claude Code 生态中以 Skill 形态实现,可对比阅读。
- 10_AI 应用架构.md § 10.6 — 介绍了 CrewAI / AutoGen 等多 Agent 框架,本文是”框架背后真实工程实践”的补充。
八、素材评分与可商榷之处(法则 8 自检)
来源
- 原文:LINUX DO 论坛《我组了一个 7 人 AI 团队,全职替我炒股——而且我不用管它们》
- 作者:@Oking
- 发布时间:2026-05-17
- 整合时间:2026-05-19(本笔记沉淀日)
评分:8 / 10
说对了什么(可吸收):
- ✅ 任务二分法(脚本 vs AI):这是工程级洞察,大多数 Multi-Agent 教程不会强调
- ✅ Persona 文件结构化思想:把”system prompt”升级为”岗位说明书”,可复用
- ✅ 共享真相源:多 Agent 数据漂移是真实坑,值得专题讨论
- ✅ 三大踩坑:每一个都是工程师会犯的真实错误,警示价值高
- ✅ 真实部署证据(Linux + cron + 飞书 + JSON Lines):不是 PPT 项目
可商榷之处(部分吸收 / 加批注):
- ⚠️ “年化 14%“作为成功标志被高调宣传:但回帖里有读者指出”巴菲特长期年化 19.9%“,且作者自己也承认”离 50% 目标还远”——这是工程项目,不是投资业绩,读者要区分。
- ⚠️ “AI 自主发现基础设施缺陷”被神化:作者描述”研究官发现新思路 → 回测官发现缺引擎 → 策略官决定造引擎”听起来很厉害,但这套行为是 Persona 文件里写好的决策规则触发的,不是 LLM 自主”涌现”出来的。读者别被表述带偏。
- ⚠️ 回帖中网友的质疑值得记下:“AI 做不了决策,他只能负责提供信息,让人去决断”——这是一个对立观点,本文倾向于”AI 可以做信息收敛型决策,关键执行仍需 HITL”,与该网友的立场是程度差异,不是非黑即白。
不收录的部分:
- ❌ 文章中”策略代码细节”(永续合约做市、基差交易等)——属于量化金融领域,不属于本知识库的 Agent 工程范围
- ❌ 具体收益数字(已模糊化)——隐私
九、下一步可继续方向
- 找一个开源的 Multi-Agent 量化框架(如 FinGPT、Qlib + Agent),对照本文原则做代码级 review
- 实操写一个最小 Persona 文件(单 Agent 起步),跑通”日志 → 状态快照 → 决策”闭环
- 整理”对账机制”专题——多 Agent 系统怎么定期验证本地状态 vs 外部真实状态一致
- 与 Eval 测评体系 联动:复盘官的 Eval 流程能否抽出可复用模板
- 调研 Claude Code 扩展生态 中的 Skill 文件与本文 Persona 的对应关系
最后更新:2026-05-19