第 3 章 · 02 四大专家 Agent

第 3 章 · 02 四大专家 Agent

本节摘要:本节精读 Director 通过 handoffs 调度的四个专家 Agent——情绪(Sentiment)、量化(Quant)、风控(Risk)、执行(Execution)。它们是 Orchestrator-Worker 模式里的「Worker」,各司其职。本节逐个拆解 workers.py 里这四个 Agent 的实例化代码:模型选型(情绪用便宜的 gpt-4o-mini,其余三个用 gpt-4.1)、工具(只有情绪 Agent 带 exa_search)、output_type="str"、max_loops=1、context_length=16000,以及它们各自被追加的「结构化输出约定」(risk/quant/execution 都在 system_prompt 后补了一段「当收到消息时,它包含…请提供…」)。读完本节,你理解了 AutoHedge 的「专业分工」如何落到代码,以及为什么这样配置。

内容来源:原项目源码 autohedge/workers.py、autohedge/prompts.py、autohedge/tools/exa_search_tool.py,精读并套用体系化模板。

学习目标

阅读完本节,你应当能够:

1. 逐行读懂四个专家 Agent 的实例化代码。
2. 说清每个 Agent 的模型选型与理由(gpt-4o-mini vs gpt-4.1)。
3. 解释为什么只有情绪 Agent 带 tools。
4. 描述四个专家各自被追加的结构化输出约定。
5. 理解 output_type="str"、max_loops=1、context_length=16000 的统一含义。

一、四个专家的全景对照

先看 workers.py 第 26-69 行四个专家的定义,一张表对照:

四个都设 max_loops=1、verbose=True;后三个还设了 output_type="str" 与 context_length=16000。注意 ALL_AGENTS 列表的顺序是 [sentiment, risk, execution, quant]——这不影响 handoffs 行为(handoffs 不依赖顺序),只是定义时如此。

二、情绪 Agent:唯一带工具的专家

workers.py 第 26-33 行:

sentiment_agent = Agent(
    agent_name="Sentiment-Agent",
    system_prompt=SENTIMENT_PROMPT + _SYSTEM_SUFFIX,
    model_name="gpt-4o-mini",
    verbose=True,
    max_loops=1,
    tools=[exa_search],
)
​

逐项解读:

• agent_name="Sentiment-Agent":handoffs 时 Director 用它识别目标。
• model_name="gpt-4o-mini":四个专家里唯一用 mini 的。情绪分析的核心是调 exa_search 读新闻再打分,LLM 主要做「读 + 总结 + 打 0~1 分」,轻量任务,用便宜的 mini 省钱。
• tools=[exa_search]:唯一带工具的专家。exa_search 来自 autohedge.tools.exa_search_tool,调 Exa API 联网搜新闻(第 2 章讲过需要 EXA_API_KEY)。
• max_loops=1:单轮——读新闻、打分、输出,不迭代。
• 注意它没有 output_type 和 context_length——用 swarms 的默认值。这是定义上的小不一致(其他三个都显式设了)。

exa_search 的签名(exa_search_tool.py):

def exa_search(query: str) -> str:
    """Exa Web Search Tool ..."""
    api_key = os.getenv("EXA_API_KEY")
    ...
​

它接受一句自然语言 query,返回 JSON 格式的搜索结果字符串。swarms 会把这个函数作为 function calling 工具暴露给 LLM,LLM 自己决定何时调用、传什么 query。

💡 核心心法:情绪 Agent 是「LLM + 联网」的典型组合——LLM 负责理解任务、生成搜索词、解读返回;工具(exa_search)负责突破 LLM 的「知识截止」局限。这种「LLM 当大脑,工具当手脚」的模式,是 Agent 区别于 Chatbot 的根本。

三、风控 Agent:严格结构化输出

workers.py 第 35-45 行:

risk_agent = Agent(
    agent_name="Risk-Manager",
    system_prompt=RISK_PROMPT.strip()
    + "\n\nWhen you receive a message, it will contain:\nStock, Thesis, Quant Analysis.\n\nProvide risk assessment including:\n1. Recommended position size\n2. Maximum drawdown risk\n3. Market risk exposure\n4. Overall risk score"
    + _SYSTEM_SUFFIX,
    model_name="gpt-4.1",
    output_type="str",
    max_loops=1,
    verbose=True,
    context_length=16000,
)
​

关键差异:

• system_prompt 是拼接三段:RISK_PROMPT.strip()(基础角色) + 一段「当收到消息时…请提供…」(结构化输出约定,第 4 章第 2 节专讲) + _SYSTEM_SUFFIX(时间注入,第 4 章第 3 节专讲)。
• 追加的约定明确告诉它:收到的消息含「股票/假设/量化分析」三段,要产出 4 项编号清单(仓位/最大回撤/风险敞口/风险评分)。这是为了让下游(执行 Agent)能解析。
• output_type="str":强制返回纯字符串(而非 dict/list)。
• context_length=16000:把上下文窗口设为 16000 token——因为风控要读量化 Agent 长长的数值分析,需要足够上下文。

风控 Agent 不带工具——它不联网、不查价,只基于上游(量化)传来的输入做推理。这是有意的设计:风控应该是「审视」而非「采集」,信息源越单一越好审计。

四、执行 Agent:订单结构生成器

workers.py 第 47-57 行:

execution_agent = Agent(
    agent_name="Execution-Agent",
    system_prompt=EXECUTION_PROMPT.strip()
    + "\n\nWhen you receive a message, it will contain:\nStock, Thesis, Risk Assessment.\n\nGenerate trade order including:\n1. Order type (market/limit)\n2. Quantity\n3. Entry price\n4. Stop loss\n5. Take profit\n6. Time in force"
    + _SYSTEM_SUFFIX,
    model_name="gpt-4.1",
    output_type="str",
    max_loops=1,
    verbose=True,
    context_length=16000,
)
​

结构与风控 Agent 完全对称——三段拼接的 system_prompt、gpt-4.1、output_type="str"、context_length=16000。差异只在追加的约定:它要求产出 6 项订单字段(订单类型/数量/入场价/止损/止盈/有效期)。

⚠️ 现实澄清:执行 Agent 名字叫「Execution」,但它只生成订单结构文本,不真的下单——股票端没有任何券商 API;Solana 端的下单在另一套工具(ultra_tools.py,第 8 章)。README 说的「完全自主交易」在股票端是夸大的,执行 Agent 实为「订单草拟 Agent」。

五、量化 Agent:数值指标生成器

workers.py 第 59-69 行:

quant_agent = Agent(
    agent_name="Quant-Analyst",
    system_prompt=QUANT_PROMPT.strip()
    + "\n\nWhen you receive a message, it will contain:\nStock and Thesis from your Director.\n\nGenerate quantitative analysis with: ticker, technical_score (0-1), volume_score (0-1), trend_strength (0-1), volatility, probability_score (0-1), key_levels (support, resistance, pivot)."
    + _SYSTEM_SUFFIX,
    model_name="gpt-4.1",
    output_type="str",
    max_loops=1,
    verbose=True,
    context_length=16000,
)
​

同样三段拼接。它追加的约定最有「结构化数据」味——明确要求产出 ticker、technical_score (0-1)、volume_score (0-1)、trend_strength (0-1)、volatility、probability_score (0-1)、key_levels (support/resistance/pivot) 这一串字段。

⚠️ 现实澄清:这里有个重大设计缺陷——量化 Agent 要求产出 0~1 的 technical_score 等指标,但它没有任何工具去算真实的技术指标。它不带 tools=[...],也就是说这些数值是 LLM 凭空生成的,不是从行情算出来的。项目里有 yfinance 依赖,但 workers.py 的 Agent 并未挂载任何取行情/算指标的工具。这是「营销说自主量化,实则 LLM 瞎编数字」的典型——第 10 章会专门批判。

六、统一参数:max_loops / verbose / context_length

后三个专家都设了这三项,逐个说清:

context_length=16000 是个有意思的选择——gpt-4.1 实际支持更大的窗口(128K+),但这里主动设小到 16K。可能意图:限制上下文 = 限制单次成本,同时避免长输入让 LLM 分心。教学项目这样设无伤大雅。

💡 核心心法:注意情绪 Agent 没设 output_type 与 context_length——这是定义上的不一致,大概率是作者写到情绪时漏了。功能上能用(走默认值),但能看出代码不够规整。

七、分工与数据流

把四个专家与 Director 串起来,数据流(逻辑上,实际由 Director 自由决定):

Director 接到任务
   │ handoff(股票 + 假设)
   ▼
情绪 Agent ──(联网搜新闻)──► 情绪打分
   │
量化 Agent ──(基于假设)──► 技术指标(注:无真实工具)
   │
风控 Agent ──(假设+量化)──► 仓位/回撤/敞口/评分
   │
执行 Agent ──(假设+风控)──► 订单结构 6 字段
   │
   ▼
Director 综合产出
​

注意:这只是逻辑流,实际 Director 是否按此顺序、是否全叫、是否重复叫,全靠 LLM 自己判断(handoffs 是隐式的,第 3 节详讲)。

本节要点回顾

1. 四专家对照:情绪(gpt-4o-mini,带 exa_search)/风控(gpt-4.1)/执行(gpt-4.1)/量化(gpt-4.1);后三个无工具。
2. 模型分层:情绪用 mini(轻量省钱),其余三个用 gpt-4.1(需推理);与 Director 同样的分层思路。
3. 唯一带工具:情绪 Agent 的 exa_search——「LLM 当大脑,工具当手脚」的典型,突破知识截止。
4. 结构化约定:risk/execution/quant 各自被追加「当收到消息时…请提供…」的编号清单约束,方便下游解析(第 4 章第 2 节专讲)。
5. 统一参数:max_loops=1(单轮)、verbose=True(打日志)、context_length=16000(限上下文降本);情绪漏设 output_type/context_length 是不一致。
6. 重大缺陷:量化 Agent 要求 0~1 指标但无真实工具,数字是 LLM 凭空生成;执行 Agent 只生成订单文本不下单——营销与现实的落差。

下一节,我们看 Director 与这四个专家之间的「handoffs」到底是什么机制——它如何决定交接、交接后控制流怎么走、与工具调用有何区别。