1. 项目概述：一次真实的AI代理工程实验

最近在AI圈子里，一个标题为“An AI Agent Spent $39 and Earned $0. The Engineering Was Real”的实验引起了我的注意。乍一看，这像是一个失败的商业尝试，但真正吸引我的是后半句——“The Engineering Was Real”。这背后不是一个简单的“AI烧钱”故事，而是一次关于如何构建、部署和监控一个真正能自主行动的AI代理的深度工程实践。我花了些时间，结合自己的经验，把这个实验的思路、架构和踩过的坑彻底拆解了一遍。

简单来说，这个实验的核心是： 用39美元的成本，让一个AI代理去尝试执行一个能产生收入的任务，最终它花光了预算却一分钱没赚到。 听起来很挫败，对吧？但关键在于，整个工程的搭建过程——从任务分解、工具调用、状态管理到错误处理——是完整、可复现且极具学习价值的。它不是为了炫技，而是为了验证在现有技术条件下，构建一个能处理复杂、开放式任务的AI代理，到底需要克服哪些工程难题。这非常适合那些对AI应用开发、自动化流程感兴趣，或者想了解智能体（Agent）技术实际落地难点的开发者和产品经理。

2. 实验目标与核心架构设计

2.1 实验目标的深层解读

这个实验的目标表面上是“赚钱”，但其真正的工程目标是 测试一个AI代理在有限预算和完全自主条件下的任务完成能力 。这里的“赚钱”只是一个具体、可量化的目标函数，用来驱动代理的一系列决策和行动。选择这个目标很有讲究：首先，它需要代理进行多步骤规划（比如选品、建站、营销）；其次，它涉及与外部系统的交互（支付接口、电商平台API）；最后，结果（收入）是清晰、客观的，便于评估代理的成功与否。

实验设定了39美元的预算上限，这是一个非常巧妙的约束。它足够小，使得实验成本可控，但又足够让代理执行一些有意义的操作（比如购买一个域名、使用云服务API调用）。预算耗尽是实验的终止条件之一，这模拟了真实商业场景中的资源限制。最终收入为0的结果，恰恰揭示了当前AI代理在解决开放式、创造性商业问题时的局限性，这比一个偶然成功的案例更有价值。

2.2 系统核心架构拆解

要实现这样一个自主代理，其系统架构必须包含几个关键模块，我根据实验描述和常规实践，将其重构如下：

1. 大脑（核心决策引擎） 这通常是基于大语言模型（LLM）的模块。它接收来自“感知”模块的环境信息（任务状态、预算、工具执行结果），进行分析和规划，然后决定下一步调用哪个“工具”。这里的关键是 提示词工程 。你需要给LLM一个清晰的角色定义（例如：“你是一个致力于用最小成本在线赚钱的自主AI创业者”）、任务目标、可用工具列表以及严格的约束（如“总预算仅39美元，必须在预算耗尽前产生收入”）。

2. 工具集（行动执行器） 代理不能空想，必须能“动手”。工具集是代理与外部世界交互的桥梁。在这个实验中，可能包括：

• 浏览器自动化工具 ：如Playwright或Selenium，用于模拟人类浏览网页、填写表单、点击按钮。这是访问电商平台、社交媒体、网站建设工具的主要手段。
• API客户端 ：用于调用特定的服务，比如域名注册商的API、虚拟主机服务的API、支付网关的沙箱API等。
• 文件操作系统 ：用于读写项目计划、记录日志、保存截图等。
• 代码解释器 ：一个可以执行Python等代码的沙箱环境，用于处理数据、生成简单图片或进行数学计算。

每个工具都需要被封装成LLM可以理解和调用的格式，通常是一个带有名称、描述和参数定义的函数。

3. 工作流与状态管理（记忆与协调） 这是工程上最复杂的一环。代理需要记住自己做过什么、当前进展如何、下一步该做什么。这涉及到：

• 任务分解与规划 ：LLM需要将宏观目标“赚钱”分解为子任务，如“研究低竞争产品关键词”、“寻找廉价域名”、“搭建简易登录页”等。规划可能是树状或链式的。
• 状态跟踪 ：系统需要维护一个持续的“状态”，包括剩余预算、已完成的任务列表、收集到的数据（如选中的产品名）、产生的中间产物（如网站URL）等。这个状态需要在每次决策循环中被更新和传递给LLM。
• 循环控制 ：一个主循环不断运行：感知状态 -> LLM决策 -> 执行工具 -> 更新状态 -> 检查终止条件（预算耗尽、时间到、任务完成）。循环中必须有健全的错误处理机制，当工具调用失败或LLM输出不合理时，系统能回退或尝试替代方案。

4. 监控与日志（实验的可观测性） 为了事后分析为什么赚不到钱，详尽的日志至关重要。需要记录每一次LLM的思考过程（Chain-of-Thought）、每一次工具调用的请求和响应、系统状态的变化、以及所有产生的费用。可视化日志或一个简单的仪表盘可以帮助开发者实时了解代理的“心路历程”和行动轨迹。

注意 ：这个架构听起来简单，但每个模块的稳定实现都充满挑战。例如，LLM的决策可能不稳定，工具执行可能因为网站反爬或API变动而失败，状态管理在复杂任务中容易混乱。这个39美元实验的价值，就在于真实地暴露了这些挑战。

3. 关键工程实现细节与工具选型

3.1 大脑模块：LLM的提示词设计与思考控制

选择哪个LLM作为大脑是第一个决策点。实验很可能使用了GPT-4或Claude等高级模型，因为它们在复杂推理和指令遵循上表现更好。对于成本敏感的实验，也可以混合使用：让GPT-4负责高层规划和关键决策，让更便宜的模型（如GPT-3.5 Turbo）处理简单的信息提取。

提示词的设计是灵魂。它不能只是一个简单的指令，而需要是一个完整的“操作手册”。一个有效的提示词可能包含以下部分：

• 身份与目标 ：明确代理的角色和终极目标。
• 约束条件 ：预算（39美元）、时间、道德与合规边界（禁止违法操作）。
• 可用工具 ：以结构化列表描述每个工具的功能、输入和输出。
• 行动格式 ：严格要求LLM以指定的JSON或特定文本格式输出其决策，例如 {"thought": "...", "action": "tool_name", "action_input": {...}} 。这便于程序解析。
• 反思机制 ：要求LLM在每次行动后，基于结果评估进展，并调整后续计划。例如，“上次购买域名的尝试因价格超预算失败，现在应该寻找免费的子域名或更便宜的顶级域名”。

为了提升决策质量，可以采用以下技巧：

• 少样本示例 ：在提示词中提供一两个正确的决策示例，引导LLM遵循正确的格式和逻辑。
• 逐步推理 ：强制要求LLM在输出行动前，先输出它的“思考”过程，这不仅能提高结果质量，也为日志分析提供了宝贵材料。

3.2 工具集实现：让AI拥有“手和脚”

工具的实现必须 鲁棒 。一个脆弱的工具会导致整个代理链条崩溃。

浏览器自动化工具选型 ：Playwright是目前的首选，因为它支持多浏览器（Chromium, Firefox, WebKit），API现代，且自动等待机制能更好地处理动态加载的网页。相比Selenium，它通常更稳定且速度更快。关键实现点包括：

• 智能等待 ：使用 page.wait_for_selector 或 page.wait_for_function 等待关键元素出现，而不是固定的 time.sleep 。
• 错误恢复 ：工具函数内部要有try-catch块。如果点击失败，可以尝试滚动到元素位置再点击，或者刷新页面重试。失败的截图应自动保存到日志。
• 反反爬策略 ：使用真实的用户代理（User-Agent），添加随机延迟模拟人类操作，避免短时间内发出过多请求。

API工具封装 ：对于域名注册、云服务等，优先寻找官方API。如果没有，则可能需要通过模拟HTTP请求与官网交互，但这比使用标准API更脆弱。封装时，要处理好认证（API Key）、参数校验和响应解析。对于付费API，每次调用前必须检查剩余预算。

一个工具函数的示例框架：

def search_product_on_amazon(product_keyword: str, max_price: float) -> dict:
    """
    在亚马逊上搜索产品，返回前几个结果的信息。
    参数:
        product_keyword: 搜索关键词
        max_price: 最高价格限制
    返回:
        dict: 包含产品列表的字典，每个产品有名称、价格、链接。
    """
    # 记录工具调用开始
    log.info(f"Searching Amazon for '{product_keyword}' under ${max_price}")
    
    try:
        # 1. 使用Playwright打开亚马逊
        # 2. 处理可能的登录/验证码（这是一个难点！）
        # 3. 输入关键词搜索
        # 4. 解析搜索结果页面，提取信息
        # 5. 过滤超过max_price的产品
        # 6. 返回结构化的数据
        
        # 模拟返回
        results = [
            {"name": "Example Product A", "price": 12.99, "url": "https://..."},
            {"name": "Example Product B", "price": 24.50, "url": "https://..."},
        ]
        log.info(f"Search successful, found {len(results)} items.")
        return {"status": "success", "data": results}
        
    except Exception as e:
        # 捕获所有异常，记录详细错误信息
        log.error(f"Amazon search failed: {str(e)}")
        # 保存当前页面截图，便于调试
        save_screenshot(page, "amazon_search_error.png")
        return {"status": "error", "message": str(e)}

3.3 工作流与状态管理的工程实践

状态管理我推荐使用一个简单的键值存储，比如一个Python字典或是一个小型的数据库（SQLite）。这个状态对象在每个循环中被读取和更新。

主循环伪代码逻辑：

state = {
    "budget_remaining": 39.00,
    "phase": "market_research",
    "discovered_products": [],
    "selected_domain": None,
    "website_url": None,
    # ... 其他状态
}

while state["budget_remaining"] > 0 and state.get("revenue", 0) == 0:
    # 1. 构建当前上下文信息
    context = f"""
    剩余预算: ${state['budget_remaining']:.2f}
    当前阶段: {state['phase']}
    已发现产品: {state['discovered_products'][:3]}  # 只显示前几个
    任务目标：在预算耗尽前创造收入。
    """
    
    # 2. 调用LLM进行决策，传入当前状态和上下文
    llm_response = call_llm(prompt + context, tools_descriptions)
    
    # 3. 解析LLM的响应，得到要执行的动作
    action, action_input = parse_response(llm_response)
    
    # 4. 找到对应的工具函数并执行
    tool_func = get_tool(action)
    result = tool_func(**action_input)
    
    # 5. 根据工具执行结果更新状态
    update_state(state, action, result)
    
    # 6. 记录本次循环的完整信息（思考、行动、结果）
    log_cycle(llm_response, action, result, state)
    
    # 7. 检查是否进入新阶段或满足终止条件
    if check_phase_transition(state, result):
        state["phase"] = new_phase

print(f"实验结束。最终状态: {state}")

更新状态 是一个需要精细设计的函数。例如，如果工具是 register_domain ，并且执行成功，那么 state[“budget_remaining”] 需要减去域名费用， state[“selected_domain”] 需要被设置， state[“phase”] 可能要从 “domain_registration” 切换到 “website_building”。

4. 实验过程推演与失败根因分析

基于39美元预算和零收入的结局，我们可以合理推演代理可能尝试的路径及其失败点。这比成功的路径更能揭示问题。

4.1 路径一：尝试电商代购或 dropshipping

代理可能行动序列：

1. 市场研究 ：使用浏览器工具搜索“low cost high demand products 2024”、“cheap products to sell online”。
2. 选品 ：尝试访问阿里巴巴、亚马逊等网站，筛选价格极低（如1-2美元）且有潜力的商品。
3. 搭建销售渠道 ：尝试用免费或极低成本平台（如Carrd, Gumroad免费版）创建一个简单的产品展示页。
4. 营销尝试 ：可能在社交媒体（如Twitter, Reddit）的相关板块发布产品链接。
5. 处理订单 ：假设有人下单，代理需要处理支付（可能尝试集成Stripe或PayPal沙箱）并通知供应商发货。

失败关键点分析：

• 选品质量差 ：LLM基于文本模式匹配选出的“热门产品”，很可能缺乏真正的市场洞察，是过时或竞争激烈的。它无法理解产品的实际价值、用户体验或真实需求。
• 建站与支付门槛 ：创建一个看起来可信的电商页面，需要设计、文案、支付集成等多方面能力。免费建站工具有诸多限制（如自定义域名需付费），而支付网关（如Stripe）的集成需要企业信息和银行账户，这对一个匿名AI代理来说几乎不可能完成验证。
• 零流量困境 ：在没有任何预算用于广告的情况下，仅靠发几个帖子几乎不可能带来真实流量。代理缺乏内容创作、社区运营或SEO等需要深度理解和创造力的获客能力。
• 合规与验证 ：在大多数平台，批量注册或自动化发布内容很容易触发反垃圾机制，导致账号被封禁，链路中断。

4.2 路径二：尝试提供微型数字服务

代理可能行动序列：

1. 技能定义 ：LLM决定提供“AI生成logo”、“数据清洗脚本”、“简易网站调试”等服务。
2. 服务展示 ：快速生成一个服务描述页面，列出价格（如5美元/次）。
3. 渠道推广 ：在Fiverr、Upwork等自由职业平台或相关论坛发帖。
4. 服务交付 ：如果有人下单，尝试用代码解释器生成一个Logo，或写一段脚本。

失败关键点分析：

• 平台准入与竞争 ：在Fiverr等成熟平台，新卖家需要时间积累信誉和评价。一个由AI运营、零历史、零评价的“卖家”很难获得第一个订单。平台也可能有防止自动化注册的机制。
• 服务交付质量 ：用AI生成的Logo可能千篇一律且缺乏独特性；写的数据清洗脚本可能无法处理客户的特殊需求。缺乏与客户的实时沟通来澄清需求，交付物很可能不符合预期，导致退款或差评。
• 交易闭环困难 ：即使获得了订单，如何安全地接收小额支付并确认交付，对于自动化系统来说也是一个复杂的协调问题。

4.3 路径三：尝试内容创作与流量变现

代理可能行动序列：

1. 内容定位 ：选择一个小众话题，如“室内盆栽养护”。
2. 内容生成 ：利用LLM生成几篇博客文章或社交媒体帖子。
3. 平台发布 ：自动发布到免费博客平台（如Blogger）或社交媒体账号。
4. 尝试变现 ：在内容中插入广告联盟链接（如Amazon Associates）或寻求捐赠。

失败关键点分析：

• 内容质量与原创性 ：纯AI生成的内容在深度、独特性和SEO价值上往往不足，难以在信息海洋中脱颖而出。它可能陷入通用表述，缺乏真正的洞察力。
• 流量积累是长期过程 ：通过内容获得可持续流量需要数月甚至数年的持续投入和优化。在39美元预算和短时间内，几乎不可能看到成效。
• 变现门槛 ：广告联盟（如Amazon Associates）通常有审核期和最低流量要求，新站几乎无法立即获得批准。捐赠更依赖于已有的粉丝基础和信任。

预算消耗分析 ：39美元很可能主要消耗在以下几个方面：

1. LLM API调用费用 ：尤其是使用GPT-4进行复杂规划和内容生成，多次调用后成本不菲。
2. 云服务与API费用 ：如果代理尝试使用了需要付费的云函数、数据库或特定API（如某些数据抓取服务、图像生成API）。
3. 域名注册费用 ：最便宜的顶级域名年费通常在10美元左右，这是一笔显著的固定支出。
4. 潜在的错误操作成本 ：例如，由于网页元素定位错误，重复提交了某个付费表单。

5. 从失败中提炼的工程经验与避坑指南

这次实验虽然以“零收入”告终，但其工程实践的价值远超一个简单的成功demo。以下是我总结的关键经验和避坑点：

5.1 设计层面：为AI代理设定合理边界

• 经验一：任务必须结构化、可观测 ：不要让AI代理处理过于开放和模糊的目标（如“赚钱”）。应该将其分解为一系列定义清晰、结果可验证的子任务。例如，“在预算内找到一个价格低于X美元、搜索量大于Y的实体产品”比“找一个好卖的产品”要好得多。
• 经验二：预算分配需要硬约束与熔断机制 ：不要只给一个总预算。应为不同类型的操作设置子预算。例如：市场研究（5美元）、基础设施搭建（15美元）、营销测试（15美元）、应急（4美元）。当某项支出超支时，代理应被强制切换到备用方案或终止该分支。
• 经验三：工具设计要追求“高成功率” ：优先为代理提供成功率高、接口稳定的工具。例如，调用一个返回结构化数据的公开API，远比让代理去解析一个随时可能改版的电商网站HTML要可靠。如果必须使用不稳定的工具（如网页自动化），必须配备强大的错误检测和恢复逻辑。

5.2 实现层面：提升系统的稳健性

• 避坑一：忽视外部系统的不可靠性 ：互联网服务会变化、会有验证码、会封IP。你的代理不能假设每次工具调用都会成功。 关键操作必须添加重试机制和备用方案 。例如，注册域名失败，应有一个备选方案是使用免费的GitHub Pages子域名。
• 避坑二：LLM的“幻觉”导致无效操作 ：LLM可能会建议一些不存在的工具，或者对工具能力有错误理解。 必须在调用工具前进行参数验证和可行性预检查 。例如，在调用“购买广告”工具前，先检查剩余预算是否大于广告最低充值额。
• 避坑三：状态管理混乱导致代理“失忆” ：在长链条任务中，代理可能会忘记之前的关键决策。除了在提示词中不断注入关键状态信息，还可以考虑为LLM实现一种“长期记忆”机制，例如将重要的决策和结果向量化存储，在需要时进行检索召回（RAG for Agents）。

5.3 监控与调试：让黑盒变得可理解

• 实操心得：日志是你的生命线 。必须记录下每一次LLM的输入（完整的上下文）和输出（包括其思考过程），每一次工具调用的请求参数和返回结果，以及状态机的每一次变迁。这些日志是分析代理失败原因的唯一切入点。可以结构化成JSONL格式，便于后续分析。
• 实操心得：实现一个简单的实时仪表盘 。哪怕只是一个不断刷新的命令行输出，显示当前阶段、剩余预算、最近几次行动和结果，都能极大提升调试效率。如果能将关键操作（如网页交互）截图保存并关联到日志，那就更好了。
• 常见问题排查表：

问题现象	可能原因	排查与解决思路
代理卡在某个循环，不断重复相同操作	LLM基于当前状态做出了相同的决策；工具执行成功但状态未正确更新。	1. 检查日志中LLM收到的状态信息是否准确。2. 检查工具执行后的返回值是否被正确解析并用于更新状态。3. 在提示词中增加“避免重复最近已成功完成的操作”的指令。
工具调用频繁失败（超时、元素找不到）	目标网站结构变化；网络不稳定；反爬机制触发。	1. 增加工具函数内的等待时间和重试次数。2. 实现动态选择器策略（如同时用ID、Class、XPath定位元素）。3. 考虑使用更稳定的API替代方案，或引入代理IP池。
预算消耗过快，且未执行核心任务	LLM选择了成本高昂但不关键的操作（如频繁调用昂贵的图像生成API）。	1. 在每次涉及付费的工具调用前，强制LLM进行成本效益分析。2. 为工具设置更细粒度的成本预算。3. 在状态中突出显示“预算已消耗X%，核心任务Y尚未开始”，以警示LLM。
LLM输出格式错误，无法解析	提示词中对输出格式的约束不够强；模型“不听话”。	1. 使用更严格的输出格式描述，例如JSON Schema。2. 在代码中实现一个“格式修复”层，尝试对LLM的轻微格式错误进行自动校正。3. 如果多次失败，则回退到更简单的指令，或更换模型。

6. 超越实验：AI代理工程的实用化思考

这个39美元的实验是一个绝佳的“压力测试”沙盒。它将AI代理技术的浪漫想象拉回了工程现实的坚硬地面。对于想要真正应用这项技术的人，我的建议是：

不要一开始就追求完全自主的“通用赚钱AI” 。这是一个难度极高的研究性问题。相反，应该从 解决具体、封闭、高重复性的商业流程痛点 入手。

例如，你可以构建一个代理来自动化处理：

• 客户服务工单分类与初步回复 ：读取工单内容，分类（如“退款”、“技术问题”），并草拟一份包含关键信息的回复供人工审核。
• 内部数据报告生成 ：每天自动从数据库拉取数据，让代理分析关键指标变化，并生成一段文字摘要。
• 竞品信息监控 ：定期抓取指定竞品网站的价格、功能更新信息，并整理成结构化报告。

在这些场景中，任务边界清晰，工具稳定（内部API、数据库），成功标准明确。你可以先让人工在环路（Human-in-the-loop）中进行监督和纠正，逐步将越来越多的步骤交给代理自动化。

这个实验最深刻的启示在于： 当前AI代理的价值，不在于替代人类进行从0到1的创造性突破，而在于作为“超级助手”，将人类从定义清晰、流程固定的繁琐工作中解放出来。 工程上的挑战——可靠性、状态管理、成本控制——是通往实用之路必须攻克的山头。这次花费39美元、收入为零的实验，其产出的工程经验和失败教训，远比一个侥幸成功的噱头更有价值。它为我们描绘了一幅更真实的技术落地图景：道路曲折，但每一步都算数。