Agent 自主规划与工具开发：反应式、深思熟虑式与混合式架构实践

写在前面

Artificial Intelligence Agent，人工智能智能体（AI Agent）的核心不是把 Large Language Model，大语言模型（LLM）放进循环，而是让模型在明确目标、状态和权限范围内决定下一步行动，并通过工具获得环境反馈。一个可用的 Agent 至少包含规划、状态、工具、反馈和终止条件。缺少其中任何一项，都可能退化为普通对话或不可控的循环。

这个项目实现了三种具有代表性的架构。

反应式私募基金问答助手根据当前问题选择关键词检索、类别检索或直接问答工具，通过观察结果继续决策。深思熟虑式智能投研助手按感知、建模、推理、决策和报告五个阶段生成研究报告。混合式投顾助手先判断问题类型，再把简单查询送入工具调用循环，把复杂配置问题送入数据收集、分析和建议链路。

三种架构解决的不是同一个问题。反应式适合步骤短、结果可立即观察的任务；深思熟虑式适合能够分解为多个分析阶段的任务；混合式适合简单查询与复杂决策并存的系统。文章先建立三种模式的关系，再分别拆解状态、工具和执行过程，最后说明当前实现距离生产系统还缺少哪些环节。

项目概览

当前项目主要验证架构和调用流程。私募基金知识库只有少量示例规则；行情、新闻和部分投研数据为模拟数据；生成报告没有接入权威数据源和自动事实核验。因此，文章讨论的是 Agent 规划与工具工程，不把输出内容作为法律或投资依据。

一、三种规划模式解决什么问题

图 1：反应式、深思熟虑式和混合式 Agent 的任务路径。三条路径最终都必须进入结果验证，而不是以模型生成文本作为完成条件（图由AI辅助绘制）。

Anthropic 将 Agentic System 区分为 Workflow 和 Agent：Workflow 由代码预先规定执行路径，Agent 则由模型动态决定过程和工具使用。官方建议从最简单的方案开始，只在复杂度能够带来可测量收益时增加多步系统。[^1]

这个区分对理解当前项目很重要。

反应式问答助手更接近典型 Agent，因为模型能够动态选择检索工具。深思熟虑式投研助手虽然包含多阶段推理，但 LangGraph 中的五个节点按照固定边连接，更准确地说是深思熟虑式工作流。混合式投顾助手在入口处引入动态路由，并在反应式分支中保留工具循环，因此同时包含确定性工作流和模型驱动决策。

二、Agent 工程的四个基础组件

2.1 状态决定系统能记住什么

LangGraph 的 StateGraph 通过共享状态连接节点。状态不是简单的聊天记录，而是任务执行过程中需要持续保存的结构化信息。官方文档将节点定义为读取状态并返回状态更新的函数，边负责决定下一步运行哪个节点。[^2]

投研助手的状态包含输入、中间分析和最终输出。

class ResearchAgentState(TypedDict):
    research_topic: str
    industry_focus: str
    time_horizon: str

    perception_data: Optional[dict]
    world_model: Optional[dict]
    reasoning_plans: Optional[list[dict]]
    selected_plan: Optional[dict]

    final_report: Optional[str]
    current_phase: str
    error: Optional[str]

这个设计使每个阶段只依赖明确的前置结果。感知阶段产生 perception_data，建模阶段将其转换为 world_model，推理阶段基于世界模型生成候选方案，决策阶段选择方案，报告阶段整合所有结果。

状态字段越清晰，节点间的隐式依赖越少。相反，如果所有内容都塞进一段自然语言历史，后续节点很难判断字段是否缺失、格式是否正确，也无法对中间结果进行独立验证。

2.2 节点负责单一处理阶段

节点应解决一个明确问题，并返回最小状态更新。例如混合投顾中的 assess_query 只判断查询类型和处理模式，不直接生成投资建议。深度分析由后续节点完成。

def assess_query(state: WealthAdvisorState) -> dict:
    result = assessment_chain.invoke({
        "user_query": state["user_query"],
    })

    return {
        "query_type": result["query_type"],
        "processing_mode": result["processing_mode"],
    }

将分类、数据收集、分析和响应拆开后，每个节点都可以单独测试。若路由分类不稳定，不需要同时修改资产配置提示；若报告结构有问题，也不应回到入口分类器调整。

2.3 边定义确定性与自主性的边界

普通边表示固定顺序，条件边表示根据状态动态路由。LangGraph 官方建议同一节点选择一种主要路由机制，避免普通边和条件边混用导致多个路径同时执行。[^2]

workflow.add_conditional_edges(
    "assess",
    lambda state: (
        "reactive_agent"
        if state["processing_mode"] == "reactive"
        else "collect_data"
    ),
    {
        "reactive_agent": "reactive_agent",
        "collect_data": "collect_data",
    },
)

这段路由代码是混合架构的核心。协调层不负责解决问题，只负责判断后续需要快速工具调用，还是需要多阶段分析。系统的自主性集中在这个决策点和反应式工具循环中，其余流程仍由代码约束。

2.4 工具把模型连接到真实环境

工具至少需要名称、用途说明、输入模式、执行逻辑和返回结构。模型只产生工具调用请求，程序负责执行和返回观察结果。

@tool
def query_portfolio_allocation(asset_type: str) -> str:
    """查询客户投资组合中指定资产类别的配置比例。"""
    allocations = {
        "股票": "40%",
        "债券": "30%",
        "现金": "10%",
        "另类投资": "20%",
    }
    return allocations[asset_type]

这个示例验证了工具调用接口，但数据来自内存字典。生产工具应连接真实账户服务，并返回数据时间、客户标识、数据来源和错误状态。工具名称看起来像实时查询，并不意味着结果真实或实时。

三、反应式案例：私募基金规则问答

3.1 为什么使用反应式架构

私募基金问答的目标是从有限规则库中找到与问题相关的内容。用户可能直接询问合格投资者标准，也可能给出机构净资产并要求判断资格。检索路径无法完全通过固定条件覆盖，但每次行动都很短：选择工具、观察结果、决定是否继续搜索或回答。

项目准备了一个精简规则库，每条记录包含规则编号、类别、常见问题和答案。Agent 可以使用三种工具。

工具注册完成后，create_agent 将模型、工具和系统约束组合起来。

tools = [
    search_rules_by_keywords,
    search_rules_by_category,
    answer_question,
]

agent = create_agent(
    ChatTongyi(model="qwen-plus"),
    tools,
    system_prompt=system_prompt,
)

系统提示要求知识库没有答案时明确说明边界，并区分规则库内容与模型补充知识。这个约束对法律和金融问答很重要，因为模型的流畅表达不能替代法规来源。

3.2 一次工具选择过程

图 2：针对净资产 800 万元的机构投资者问题，Agent 选择关键词检索工具，取得合格投资者规则后生成结论。来源：项目早期运行记录。

这个案例体现了反应式架构的基本循环。模型先判断需要确认机构投资者资格，再调用关键词工具检索净资产和资格要求；工具返回规则后，模型据此判断 800 万元低于示例规则中的 1000 万元门槛。

结果能够说明工具选择流程有效，但不能直接作为合规意见。项目规则库仅包含三个示例条目，没有法规版本、发布日期、适用基金类型和原始条文链接；监管要求也可能变化。真正的合规助手必须以权威文件为数据源，保存生效时间和引用位置，并对涉及资格认定的问题设置人工复核。

3.3 当前检索方法的局限

关键词工具使用字符串包含判断，适合少量规则。answer_question 使用空格分词后计算集合交集，但中文问题通常没有空格，因此匹配效果不稳定。规则规模增大后，应改为分词检索、Okapi BM25 概率相关性检索或向量检索，并增加重排和引用返回。

三个工具之间也存在能力重叠。关键词检索和直接问答都在做相似度匹配，模型可能难以判断差别。更清晰的设计是保留一个统一检索工具，参数中显式提供 query、category、top_k 和生效日期；回答逻辑由 Agent 在取得证据后完成。

四、深思熟虑式案例：五阶段智能投研

4.1 为什么拆成五个阶段

投资研究包含信息收集、状态判断、方案比较和报告组织。让模型一次完成所有工作，容易在同一上下文中混淆事实、假设和建议。项目将任务拆为五个连续阶段。

每个阶段通过独立提示调用模型，JavaScript Object Notation，JavaScript 对象表示法（JSON）阶段使用 JsonOutputParser，最终报告使用 StrOutputParser。Pydantic 输出模型进一步规定字段类型，使中间数据能够被检查，而不是只依赖自然语言格式。

workflow = StateGraph(ResearchAgentState)

workflow.add_node("perception", perception)
workflow.add_node("modeling", modeling)
workflow.add_node("reasoning", reasoning)
workflow.add_node("decision", decision)
workflow.add_node("report", report_generation)

workflow.set_entry_point("perception")
workflow.add_edge("perception", "modeling")
workflow.add_edge("modeling", "reasoning")
workflow.add_edge("reasoning", "decision")
workflow.add_edge("decision", "report")
workflow.add_edge("report", END)

这段代码清楚表达了阶段依赖，也说明它是固定工作流。节点内部由模型推理，但模型不能改变阶段顺序、增加调查步骤或在证据不足时主动返回感知阶段。若需要真正的自主规划，应增加计划对象、执行器、评价器和重新规划条件。

4.2 报告输出

图 3：五阶段流程最终生成新能源汽车行业研究报告，图片展示报告摘要和行业背景。来源：项目运行结果。

生成结果具备标题、摘要、行业背景、核心观点、风险和建议等完整结构。项目根目录还保存了一份更长的新能源汽车行业中期研究报告，说明流程能够持续传递状态并生成长文本输出。

这张图只能证明报告生成链路完成，不能证明报告中的市场数据、政策节点、收益率和风险参数正确。LangGraph 版本的感知阶段直接调用模型知识，没有配置网页搜索、行情接口、数据库或引用工具；混合投顾的深度分支也明确要求模型生成模拟数据。因此，报告中的具体数字属于待核验内容。

4.3 两种实现方式

项目同时提供 LangGraph 和 Qwen-Agent 两种深思熟虑式实现。

LangGraph 版本将每个阶段写成图节点，状态显式，适合观察和控制流程。Qwen-Agent 版本将感知、建模、推理、决策和报告写成五个注册工具，由 Assistant 决定调用工具。后者更接近模型驱动的工具编排，但会增加工具参数传递和会话状态管理复杂度。

Qwen-Agent 版本通过 _last_analysis_dict 保存会话中间结果。当前 get_session_id 使用消息对象的内存标识作为会话标识，适合单进程演示，不适合多进程、服务重启和持久化。生产环境应使用显式 Identifier，标识符（ID）和外部状态存储。

代码中还有一个配置不一致：系统提示要求优先调用 complete_analysis，但 function_list 只注册了五个分阶段工具，没有注册 complete_analysis。模型实际无法调用提示中声明的工具。解决方法只有两种：把工具加入注册列表，或从提示中删除该路径，不能同时保留互相矛盾的说明。

4.4 错误恢复仍需补全

LangGraph 版本定义了 router，节点出错时也会写入 error 和 current_phase，但构图时使用的是固定普通边，router 没有接入图中。这意味着错误状态不会按设计返回上一阶段，图仍可能继续进入后续节点。

更稳妥的方式是让每个节点之后进入条件边：成功时前进，缺少前置状态时回到对应阶段，达到重试上限时结束并返回错误。LangGraph 也支持用 Command 同时更新状态和决定下一节点。[^2]

五、混合式案例：投顾助手的动态路由

混合架构适合财富管理场景，因为用户请求的复杂度差异很大。查询指数、查看组合比例和获取市场新闻只需要短链路；应对经济衰退、退休规划和教育金方案则需要结合客户画像进行多阶段分析。

项目设置了两个示例客户画像，包含风险承受能力、投资期限、财务目标、投资偏好、组合价值和当前配置。协调节点首先把问题分为 emergency、informational 或 analytical，再选择 reactive 或 deliberative 模式。

5.1 LangGraph 执行图

图 4：协调层将问题送入反应式工具循环或深思熟虑式分析链路。图中的节点和边依据当前 hybrid_wealth_advisor_langgraph.py 重绘（图由AI辅助绘制）。

反应式分支将三个工具绑定到模型。若模型返回 tool_calls，ToolNode 执行工具，并把 ToolMessage 追加到消息状态；随后流程回到模型，直到模型不再请求工具，再提取最终回答。官方 LangGraph 文档同样将 ToolNode 定义为执行模型工具请求的预构建节点，并通过条件边构造模型与工具之间的循环。[^3]

workflow.add_node("reactive_agent", reactive_agent)
workflow.add_node("tools", ToolNode(tools))

workflow.add_conditional_edges(
    "reactive_agent",
    should_continue_tools,
    {
        "tools": "tools",
        "end": "extract_response",
    },
)

workflow.add_edge("tools", "reactive_agent")

深思熟虑分支不调用 ToolNode，而是依次执行 collect_data、analyze_data 和 generate_recommendations。这个分支更可控，但数据来源和步骤由代码固定。

5.2 路由到深思熟虑分支

图 5：经济衰退下的组合调整问题被识别为分析型任务，协调层选择深思熟虑模式，并进入数据收集、分析和建议三个节点。来源：项目运行结果。

运行记录显示，分类器将问题标记为 analytical，处理模式为 deliberative。随后执行 collect_data -> analyze_data -> generate_recommendations。这个结果验证了条件路由与节点顺序，但没有验证分类器在更大问题集上的准确率。

路由器是混合系统最关键的单点。如果复杂任务被误判为反应式，系统可能在证据不足时给出过度简化的答案；如果简单任务被误判为深思熟虑式，则会增加延迟和成本。项目后续需要用标注问题集计算路由准确率和各类错误比例。

5.3 资产配置输出

图 6：系统基于 150 万元平衡型客户画像，生成股票、债券、现金和另类投资的调整建议。来源：项目运行结果。

输出将股票从 40% 调整为 30%，债券从 30% 调整为 40%，现金从 10% 调整为 15%，另类投资从 20% 调整为 15%。金额合计仍为 150 万元，说明结果在基本算术上保持一致。

这个案例只验证输出组织和状态传递。市场数据由模型模拟生成，工具中的上证指数、新闻和组合数据也是代码内固定值；系统没有计算组合波动率、最大回撤、相关系数、税费和再平衡成本。因此，配置比例不能被解释为经过量化优化的投资建议。

六、工具开发的核心不是函数数量

Anthropic 将工具接口称为 Agent-Computer Interface，智能体—计算机接口（ACI），并强调工具定义应像面向开发者的接口一样清楚，包括示例、边界和不易出错的参数设计。[^1]

项目中的工具能够演示调用机制，但从工程角度还需要五项约束。

工具描述还要让模型知道什么时候不应调用。例如 query_shanghai_index 应明确市场、交易日、数据延迟和返回币种；知识检索工具应说明数据截止日期和无结果语义；投资组合工具必须从可信会话上下文取得客户 ID，不能让模型自由生成客户标识。

工具输出是 Agent 获得环境真实反馈的主要渠道。若工具本身返回模拟值或过期值，后续规划越复杂，错误传播越严重。工具可靠性通常比增加推理步骤更重要。

七、如何把自主规划做得更完整

7.1 从固定阶段升级为计划、执行和重规划

当前五阶段投研流程适合任务结构稳定的场景。若研究对象差异较大，可以让规划器先输出结构化计划。

{
  "goal": "评估新能源汽车行业中期投资机会",
  "steps": [
    {"id": "s1", "tool": "search_policy", "status": "pending"},
    {"id": "s2", "tool": "query_market_data", "status": "pending"},
    {"id": "s3", "tool": "compare_companies", "status": "pending"}
  ],
  "success_criteria": [
    "关键数字均有来源",
    "至少比较三种候选策略",
    "风险结论与数据一致"
  ]
}

执行器逐步调用工具，评价器检查证据是否覆盖成功条件。若信息不足，则重新规划；若达到最大步骤数、预算上限或需要高风险操作，则暂停并请求用户确认。这样才形成计划、行动、观察、评价和重规划闭环。

7.2 把事实核验放在报告生成之前

投研报告的问题不在文字结构，而在事实来源。感知阶段应连接行情、公告、政策和新闻工具，每条数据保留来源链接、发布日期和查询时间。建模和推理阶段只能使用已验证证据，报告阶段再检查所有数字是否能够回溯到来源。

可以增加一个 verify_evidence 节点，对关键陈述逐条输出：

未经验证的数字应从报告中删除或明确标注为假设。金融场景不能把模型置信度当作事实正确率。

7.3 建立可量化评估

项目目前主要展示单次输入输出，缺少系统级评估。后续可以建立覆盖三类任务的测试集。

Agent 评估不能只检查最终文本。还要检查执行轨迹：是否选择正确工具、是否重复调用、是否在信息不足时停止、是否违反权限，以及中间错误是否被后续步骤放大。

7.4 增加停止条件和人工确认

反应式循环应设置最大工具调用次数、超时和成本预算。深思熟虑式流程应在关键证据缺失时终止，不应继续生成报告。涉及投资交易、客户数据和法律判断时，应加入 Human-in-the-Loop，人在回路（HITL）确认节点。

2026 年 Anthropic 对可信 Agent 的总结同样强调人类控制、透明性、安全交互和隐私保护；Agent 的自主性越高，越需要让用户能够理解、暂停和修改其行为。[^4]

八、复现方式与版本边界

三个案例都通过 DASHSCOPE_API_KEY 连接通义千问模型。依赖版本分别固定在 LangChain 1.0.3、LangGraph 1.0.2 和 Qwen-Agent 0.0.25 附近。不同版本的 Agent 创建接口、消息类型和工具调用格式可能变化，复现时应使用项目目录中的依赖文件。

$env:DASHSCOPE_API_KEY = "本机环境变量中的密钥"

python .\CASE-私募基金运作指引问答助手（反应式）\fund_qa_langchain.py
python .\CASE-智能投研助手（深思熟虑）\deliberative_research_langgraph.py
python .\CASE-投顾AI助手（混合式）\hybrid_wealth_advisor_langgraph.py

运行前需要明确两点。第一，项目代码中的行情和新闻工具返回模拟值，不能用来查询实时市场。第二，部分截图来自较早的运行版本，当前源码已经调整了 Agent 创建方式和个别函数名称；博客的架构分析以当前源码为准，截图只用于展示当时的执行过程。

九、项目结果、限制与工程启发

项目完成了三种规划架构的最小验证。反应式问答助手能够根据问题选择检索工具；深思熟虑式投研助手能够在多个阶段间传递结构化状态并生成长报告；混合投顾助手能够根据问题复杂度选择不同处理路径，并在反应式分支中形成模型与工具的循环。

项目最有价值的结论不是某份报告或某组配置比例，而是三种架构的适用条件。规则清晰、反馈及时的任务应优先使用反应式工具循环；阶段能够预先定义的复杂任务可以使用多步工作流；只有简单与复杂任务并存，且路由能够稳定分类时，才需要混合架构。

当前限制也很明确：数据主要是示例和模拟值，缺少权威来源与时间戳；深思熟虑式流程没有动态重规划；错误恢复路由没有真正接入；Qwen-Agent 工具声明与注册列表存在不一致；系统没有任务集、轨迹指标和安全测试。

这些问题并不否定原型价值，反而给出了下一步开发顺序：先替换真实数据工具并建立引用，再完善条件路由和错误恢复，随后增加任务评估、调用预算和人工确认，最后才考虑更复杂的多 Agent 协作。

小结

Agent 自主规划不是单一架构，而是一组不同程度的决策权分配。

反应式架构把决策权放在每次观察后的工具选择上；深思熟虑式架构把复杂任务拆成可检查的阶段；混合式架构通过协调层决定使用哪一种处理路径。LangGraph 负责状态与控制流，LangChain 和 Qwen-Agent 负责模型及工具接入，但框架本身不会自动带来可靠性。

真正决定系统质量的是工具能否返回可信数据、状态能否被验证、错误能否被恢复、路径能否被评估，以及高风险操作是否保留人工控制。自主性应建立在这些工程约束之上。