AI助手和AI智能体不是同一物种——Perplexity与哈佛的对比实验揭示了什么

2026-06-11 16 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:11 分钟

你问ChatGPT"帮我分析这份财报",它给你一段文字摘要和几条建议。你还得自己打开Excel、拉数据、做图表、写邮件。但如果换成一个真正的AI智能体,它会把财报下载、解析、制图、起草邮件,最后把成品推到你面前——你只需要说"发送"。

Perplexity与哈佛商学院研究团队的最新论文,首次在实际部署场景中对这两种模式做了全面比较。研究对象是Perplexity Computer——一个通用AI Agent编排器,能调用浏览器、代码执行器、文件系统等工具链完成端到端任务。对比对象则是传统搜索助手(包括Perplexity自身的搜索模式)。结论很直接:助手和智能体之间的差距,不是"更好一点",而是"完全不同的工作方式"。

助手回答问题,智能体交付成果

论文对两类系统做了清晰的职能划分:

维度 AI助手 AI智能体
核心动作 回答、解释、建议 规划、执行、交付
用户角色 决策者+执行者 审批者
工作流 人→助手→人→工具→人 人→智能体→工具链→成品→人
交付物 文字/建议 文件/图表/代码/邮件

关键差异在于执行闭环。助手给出建议后,闭环断开——人必须自己接手。智能体则把建议直接转化为行动,闭环始终闭合。

研究中的定量数据佐证了这一点:在需要多步骤操作的任务(如"对比三家公司近四个季度的毛利率并生成可视化报告")上,智能体的任务完成率显著高于助手模式,因为助手模式在每一步都需要人工介入,而任何一步的放弃都会导致整个任务失败。

Perplexity Computer的编排逻辑

Perplexity Computer的核心不是某个单一模型,而是编排层。它的工作方式可以拆解为三步:

  1. 意图解析与任务拆分——把用户的自然语言请求分解为可执行的子任务序列。
  2. 工具调度——根据子任务类型选择浏览器、代码运行环境、文件操作等工具,按依赖关系编排调用顺序。
  3. 结果聚合与交付——将各子任务的输出合并为用户可直接使用的成品。

这和传统RAG+聊天模式的区别,类似于"参谋"和"参谋+执行部队"的区别。参谋给出方案,但没有部队,方案永远停留在纸上。

从助手到智能体:一个可运行的编排原型

理解概念不如动手搭一个最小原型。下面的Python示例用openai SDK实现一个极简的两步智能体编排器——先搜索信息,再生成可视化报告,直接交付PNG文件。你可以在此基础上扩展更多工具节点。

"""
minimal_agent_orchestrator.py
一个极简AI智能体编排器:搜索→分析→交付成品
依赖:pip install openai matplotlib
运行前设置:export OPENAI_API_KEY="sk-..."
"""

import openai
import matplotlib.pyplot as plt
import json, os, re

client = openai.OpenAI()

# ---------- 工具定义 ----------
TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "模拟网页搜索,返回关键词相关的摘要数据",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "搜索关键词"}
                },
                "required": ["query"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "save_chart",
            "description": "将数据保存为柱状图PNG文件",
            "parameters": {
                "type": "object",
                "properties": {
                    "title": {"type": "string"},
                    "labels": {"type": "array", "items": {"type": "string"}},
                    "values": {"type": "array", "items": {"type": "number"}},
                    "filename": {"type": "string"}
                },
                "required": ["title", "labels", "values", "filename"]
            }
        }
    }
]

# ---------- 工具实现 ----------
def web_search(query: str) -> str:
    """模拟搜索——实际生产中替换为真实搜索API"""
    # 这里用硬编码数据演示;生产环境接入 Perplexity API / SerpAPI 等
    mock_data = {
        "毛利率": {"公司A": [32, 34, 31, 36], "公司B": [28, 30, 29, 33], "公司C": [41, 39, 42, 44]},
        "营收增速": {"公司A": [12, 15, 8, 18], "公司B": [20, 22, 19, 25], "公司C": [5, 7, 6, 9]}
    }
    for key, val in mock_data.items():
        if key in query:
            return json.dumps(val)
    return json.dumps(mock_data["毛利率"])

def save_chart(title: str, labels: list, values: list, filename: str) -> str:
    """生成柱状图并保存为PNG"""
    plt.figure(figsize=(8, 5))
    plt.bar(labels, values, color="#4C78A8")
    plt.title(title)
    plt.ylabel("百分比 (%)")
    plt.tight_layout()
    filepath = os.path.join(os.getcwd(), filename)
    plt.savefig(filepath)
    plt.close()
    return f"图表已保存至 {filepath}"

# ---------- 工具路由 ----------
tool_map = {"web_search": web_search, "save_chart": save_chart}

# ---------- 智能体主循环 ----------
def run_agent(user_request: str, max_steps: int = 5) -> str:
    messages = [{"role": "user", "content": user_request}]
    for _ in range(max_steps):
        resp = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=TOOLS,
            tool_choice="auto"
        )
        msg = resp.choices[0].message

        # 如果模型直接给出最终文本回复,闭环结束
        if not msg.tool_calls:
            return msg.content

        # 否则执行工具调用,把结果喂回模型继续规划
        messages.append(msg)
        for tc in msg.tool_calls:
            fn_name = tc.function.name
            fn_args = json.loads(tc.function.arguments)
            result = tool_map[fn_name](**fn_args)
            messages.append({
                "role": "tool",
                "tool_call_id": tc.id,
                "content": result
            })

    return "达到最大步数限制,任务未完全完成。"

# ---------- 运行 ----------
if __name__ == "__main__":
    # 对比:助手模式只会给你文字建议;智能体模式直接交付文件
    request = "对比公司A、B、C最近四个季度的毛利率,生成柱状图保存为 margin_chart.png"
    final_output = run_agent(request)
    print(final_output)

运行后你会在当前目录得到margin_chart.png——这就是"交付成品"而非"给出建议"的区别。

改造方向: - 把web_search替换为Perplexity API(https://api.perplexity.ai/chat/completions)或SerpAPI,获取真实数据。 - 增加send_emailwrite_docx等工具节点,让智能体完成更长的交付链。 - 加入错误重试和人工审批节点(如发送邮件前暂停等待确认),这就是论文中提到的"人作为审批者"模式。

智能体的真实边界

论文没有回避问题。智能体模式在以下场景仍然脆弱:

  • 高不确定性决策——当任务路径本身不清晰,拆分和编排都会出错。模型可能规划出一条看似合理但实际走不通的路径,而且每一步的误差会累积。
  • 工具调用失败——浏览器被反爬、API限流、代码运行环境崩溃,这些在助手模式下由人手动处理,在智能体模式下需要编排层自己诊断和重试,目前容错能力有限。
  • 信任与审核——智能体直接交付成品,但成品是否可靠?论文指出,用户对智能体输出的信任建立需要时间,尤其是在涉及财务、法律等高风险领域时,中间节点的可观测性和人工干预点不可或缺。

一个实用的折中方案是半自主模式:智能体规划并执行,但在关键节点(如发送外部邮件、提交代码到生产分支)暂停,等待人工确认后继续。这比纯助手模式高效,比全自主模式安全。

落地检查清单

如果你的团队正在考虑从助手模式迁移到智能体模式,先回答这几个问题:

  1. 任务是否有明确的交付物? 如果用户需求本身就是"聊一聊、了解一下",助手模式更合适。智能体适合有具体产出的任务(报告、文件、部署)。
  2. 工具链是否稳定可调用? 智能体依赖外部工具。如果你的API经常超时、数据源经常变动,编排层的可靠性会大打折扣。先加固基础设施。
  3. 是否需要中间审批点? 涉及对外动作(发邮件、改数据库、部署服务)的任务,建议在编排中插入人工确认节点,避免智能体"自信地犯错"。
  4. 可观测性是否到位? 智能体的每一步工具调用都应该有日志。出了问题,你需要能回溯到是哪一步规划失误或工具失败,而不是只能看到最终成品不对。
  5. 成本模型是否清晰? 智能体一次任务可能触发5-10次模型调用+多次工具调用,token消耗和API费用远高于单轮助手对话。先算清楚单位任务成本。

助手和智能体不是"升级"关系,而是"分工"关系。快速问答用助手,端到端交付用智能体,高风险环节加人工审批——这才是论文真正建议的混合工作流。


相关推荐