大模型经营柠檬水摊：一套可复制的AI Agent决策评测框架

把一个只会在对话框里聊天的大模型，扔到一间真实经营的柠檬水摊前，让它连续经营七天，最后看谁赚到的钱多。这件事听起来像是一段娱乐视频，但它背后其实是一个非常值得开发者复刻的 AI Agent 评测实验。

很多人把 GPT 和 Claude 当成“问答机器人”，只在聊天窗口里问它怎么写代码、怎么翻译文本。但真正有价值的问题是：当模型被放进一个“观察状态、做出决策、接受反馈、调整下一步行动”的闭环里，它还能不能做出理性判断？柠檬水摊就是一个绝佳的场景：规则简单，状态清晰，但包含库存采购、定价、天气预测、现金流约束和多天累计收益。小，但五脏俱全。

这篇文章不打算只停留在“谁家 AI 更聪明”的娱乐结论上。我会把整个实验按照工程方式拆开：如何搭建一个柠檬水摊模拟环境，如何通过 API 接入 GPT 和 Claude 作为决策代理，如何让它们连续跑多天经营决策，如何用累计利润、库存浪费和决策合理性来评估结果，最后再总结 Agent 开发中真正容易踩坑的地方。读完你会得到一套可复制的 LLM 决策评测 Demo，也能更清楚地判断：一个大模型“会聊天”和“会做运营决策”之间，到底差了多少。

1. 这篇文章真正要解决的问题

先说结论：柠檬水摊实验不是一个游戏，而是一个压缩过的决策智能测试床。它把 LLM 评测从“静态问答”推向“动态决策”，这是当前 Agent 开发中最值得关注的方向之一。

传统的大模型评测通常围绕“正确答案”展开：给一个数学题、一段翻译、一个代码题目，看模型的输出是否匹配标准答案。这类评测能反映模型的记忆和理解能力，但很难反映它在真实业务中的价值。真实业务有一个共同特征：今天的决策会影响明天的状态。你采购了太多柠檬，明天的现金就变少；你把价格定得太高，今天的销量就下滑；你没有做广告，下雨天的客流就更惨。这些约束在一个静态问答测试里根本不会出现。

柠檬水摊正好把这类运营决策压缩到很小的空间里：

• 决策变量：进货柠檬数量、进货糖包数量、进货纸杯数量、每杯售价、是否打广告。
• 状态变量：现金、库存、天气预告、前一天售价、累计利润。
• 约束条件：现金不足不能采购，每杯柠檬水需要消耗一个柠檬、一份糖、一个纸杯，库存卖不掉不产生收入。
• 随机因素：当天天气可能与预报不一致，客流本身也有波动。

所以这篇文章真正要回答的问题是：GPT 和 Claude 这类通用大模型，能不能在连续多天的经营模拟中表现出“会做生意”的能力？它们是否懂得控制库存、调整定价、应对天气变化？更重要的是，如果我们要把大模型接入生产系统做自动决策，应该用什么样的工程框架去约束它、验证它、保护它？

如果你正在做 Agent 开发、做 LLM 工具调用、或者想把大模型接入业务决策流程，这篇文章的示例和排错思路可以直接借鉴。

2. 核心概念与场景设定

在写代码之前，先把实验涉及的核心概念说清楚。很多新手在接触 Agent 开发时，会被“工具调用”“Function Calling”“多智能体”这些词吓到，但柠檬水摊实验不涉及这些复杂机制，只需要理解最基础的闭环。

2.1 LLM 作为决策器

在这个实验里，大模型不是一个聊天对象，而是一个“决策器”。每天开始时，程序会告诉它当前的现金、库存、天气预告等信息，它需要输出一个经营决策：买多少原料、卖多少钱、是否打广告。程序拿到这个决策后，根据模拟规则计算当天的销售结果，再把新的状态反馈给模型。第二天，模型会基于新的状态重新决策。

这是一个典型的闭环：

状态输入 -> LLM 决策 -> 环境执行 -> 结果反馈 -> 新状态

这种结构和真实 Agent 任务是一致的。区别只在于，真实 Agent 的环境可能是电商系统、运维平台、CRM，而这里的“环境”是一个只有几百行代码的模拟器。

2.2 环境、动作与奖励

如果熟悉强化学习，可以把柠檬水摊理解为一个小型环境：

• 环境状态：现金、库存、天气、天数。
• 动作空间：进货柠檬数、进货糖包数、进货纸杯数、售价、广告策略。
• 奖励信号：每天的销售收入和最终累计利润。
• 终止条件：运行到设定的总天数。

不过这里不需要训练模型，而是直接让预训练大模型通过提示词来决策。所以问题的关键在于：模型能否根据环境状态和一条系统提示词，自己推理出合理的经营策略。

2.3 为什么要用 API 而不是网页聊天

看视频时，很多人以为这个实验是在网页聊天窗口里手动问 AI“今天该进多少货”，然后把答案手动填进表单。工程化做法完全不同。我们应该通过 API 直接调用模型，让程序自动发送状态、接收决策、执行决策并记录结果。

使用 API 有几个明显好处：

• 可重复：每次调用参数一致，方便做对比实验。
• 可控制：可以设置 temperature、max_tokens、响应格式等参数。
• 可记录：所有输入输出都可以落盘，方便分析模型哪一步出了问题。
• 可批量化：可以连续跑几十轮，而不是手动复制粘贴。

因此，后面所有示例都基于 OpenAI Python SDK 和 Anthropic Python SDK。

3. 环境准备与前置条件

这个实验对硬件没有要求，一台普通开发机即可。需要准备的主要是 Python 环境和 API 密钥。

建议使用 Python 3.10 及以上版本，项目最好用虚拟环境隔离依赖。实际测试中，版本差异可能影响 SDK 行为，但本文重点演示通用思路，不绑定精确版本。

3.1 创建项目目录和虚拟环境

在终端里执行：

mkdir lemonade-lab && cd lemonade-lab python3 -m venv .venv source .venv/bin/activate

Windows 环境把最后一步换成：

.venv\Scripts\activate

3.2 安装依赖

pip install openai anthropic python-dotenv

三个依赖的用途：

• openai：用于调用 GPT 系列模型。
• anthropic：用于调用 Claude 系列模型。
• python-dotenv：用于从.env文件读取 API 密钥，避免把密钥写进代码。

3.3 配置 API 密钥

在项目根目录创建.env文件：

OPENAI_API_KEY=sk-your-openai-key ANTHROPIC_API_KEY=sk-ant-your-anthropic-key

注意：.env文件绝不能提交到 Git 仓库，建议在.gitignore中加入一行*.env。API 密钥是敏感凭证，泄露后可能导致盗刷。如果是在公司服务器上运行，更推荐使用 KMS 或配置中心管理密钥，而不是直接写在文件里。

如果某个模型在当前网络环境或账户下不可用，请以你账户可访问的模型为准。例如，可以把gpt-4o-mini换成你账户可用的 OpenAI 兼容模型，也可以把claude-3-5-sonnet-latest换成你账户可见的 Claude 模型。本文代码只依赖模型返回 JSON 文本，不绑定具体模型名。

4. 核心流程拆解

整个实验可以拆成四个模块：模拟环境、LLM 代理、比赛主循环、结果分析。下面逐个说明设计思路。

4.1 模拟环境模块

模拟环境的作用是维护经营状态，并按照规则执行决策。它不需要依赖任何大模型 SDK，是一个纯 Python 类。

核心规则设计如下：

• 初始资金 20 美元，初始库存为 0。
• 每天开始前，程序获得当天天气预告。
• 决策动作包含进货数量、售价、是否广告。
• 执行顺序：先采购扣钱，再计算客流和销量，最后把收入加到现金上。
• 销量不能超过制作能力：可制作杯数等于柠檬、糖、纸杯三者中的最小值。
• 当天卖不掉的库存保留到第二天，但不会自动变成现金，属于沉淀资金。
• 天气会影响客流：晴天客流最多，阴天一般，雨天最少。
• 广告会提高当日客流因子，但需要付出固定成本。

为什么把“卖不掉的库存”计入浪费指标？因为在真实经营里，库存占用资金，现金才是生存的关键。这个规则会迫使模型学习控制进货量，而不是盲目买买买。

4.2 LLM 代理模块

LLM 代理负责把环境状态转换成决策动作。它的核心是提示词设计和输出解析。

提示词必须明确告诉模型三件事：

1. 你正在经营一个柠檬水摊，目标是在多天内最大化累计利润。
2. 输入的 JSON 格式和含义。
3. 输出必须是 JSON，不能有其他文字。

输出解析是关键的一步。GPT 和 Claude 偶尔会输出 Markdown 代码块格式的 JSON，需要写一个解析函数去掉多余内容。更稳妥的做法是，解析失败时返回一个保守决策，而不是让程序崩溃。

4.3 对比实验设计

要公平对比 GPT 和 Claude，需要保证两个模型面对相同的天气序列和客流随机数。做法是固定随机种子。因为运行脚本里天气和客流都依赖同一个random模块，只要在每次运行前调用random.seed(42)，两个模型就会看到相同的随机序列。这样，利润差异就只能归因于模型决策质量，而不是运气。

建议每组实验跑多个种子，比如42、2024、7，然后取平均利润。单次运行只能说明某一次的运气，多轮平均更有说服力。

5. 完整示例与代码实现

下面给出完整代码。为了便于理解，拆成多个文件，项目结构如下：

lemonade-lab/ ├── .env ├── lemonade_env.py ├── llm_agents.py ├── run_experiment.py └── result_log.jsonl

5.1 模拟环境：lemonade_env.py

# 文件路径：lemonade-lab/lemonade_env.py import random from dataclasses import dataclass @dataclass class LemonadeEnv: cash: float = 20.0 lemons: int = 0 sugar: int = 0 cups: int = 0 price: float = 1.0 day: int = 0 def reset(self): self.cash = 20.0 self.lemons = 0 self.sugar = 0 self.cups = 0 self.price = 1.0 self.day = 0 def state_text(self, forecast: str) -> str: return ( f"Day {self.day + 1}, forecast={forecast}, " f"cash=${self.cash:.2f}, lemons={self.lemons}, " f"sugar={self.sugar}, cups={self.cups}, " f"last_price=${self.price:.2f}" ) def apply_decision(self, d: dict, weather: str) -> dict: self.day += 1 buy_lemons = max(0, int(d.get("buy_lemons", 0))) buy_sugar = max(0, int(d.get("buy_sugar", 0))) buy_cups = max(0, int(d.get("buy_cups", 0))) price = round(max(0.2, min(float(d.get("price", 1.0)), 5.0)), 2) advertise = 1 if d.get("advertise", 0) else 0 cost = ( buy_lemons * 0.2 + buy_sugar * 0.1 + buy_cups * 0.15 + advertise * 1.0 ) # 现金不足时按比例缩减采购 if cost > self.cash: scale = self.cash / cost buy_lemons = int(buy_lemons * scale) buy_sugar = int(buy_sugar * scale) buy_cups = int(buy_cups * scale) cost = ( buy_lemons * 0.2 + buy_sugar * 0.1 + buy_cups * 0.15 + advertise * 1.0 ) if cost > self.cash: advertise = 0 cost = ( buy_lemons * 0.2 + buy_sugar * 0.1 + buy_cups * 0.15 ) self.cash -= cost self.lemons += buy_lemons self.sugar += buy_sugar self.cups += buy_cups weather_factor = { "sunny": 1.3, "cloudy": 1.0, "rainy": 0.6, }.get(weather, 1.0) ad_factor = 1.6 if advertise else 1.0 walkers = random.randint(15, 50) customers = int(walkers * weather_factor * ad_factor) # 价格越高，购买转化率越低 buy_prob = max(0.05, 1.2 - 0.35 * price) demand = int(customers * buy_prob) capacity = min(self.lemons, self.sugar, self.cups) sales = min(demand, capacity) revenue = sales * price self.cash += revenue self.lemons -= sales self.sugar -= sales self.cups -= sales self.price = price return { "day": self.day, "weather": weather, "walkers": walkers, "demand": demand, "capacity": capacity, "sales": sales, "revenue": round(revenue, 2), "cash": round(self.cash, 2), "waste_lemons": self.lemons, "decision": d, }

这段代码的关键点在于：

• 采购先于销售扣款，现金不足时按比例缩减采购，避免产生负现金流。
• 制作能力受三个库存维度约束，模型必须尽量让柠檬、糖、纸杯数量匹配。
• 天气和广告都只影响客流，最终销量还受价格转化率和库存上限影响。

5.2 LLM 代理：llm_agents.py

# 文件路径：lemonade-lab/llm_agents.py import json import os import re from anthropic import Anthropic from openai import OpenAI SYSTEM_PROMPT = """ 你是一个柠檬水摊的经营者。你的目标是在多天内最大化累计利润。 每天只能做一次决策，输出 JSON 对象，不要输出多余文字，不要使用 Markdown。 JSON 字段含义： - buy_lemons：当天进货柠檬数量，整数 - buy_sugar：当天进货糖包数量，整数 - buy_cups：当天进货纸杯数量，整数 - price：当天每杯售价，小数，建议在 0.5 到 3.0 之间 - advertise：是否花 1 美元做广告，1 表示做，0 表示不做 约束： - 现金不足时无法采购 - 每杯需要消耗 1 个柠檬、1 份糖、1 个纸杯 - 卖不掉的库存不会自动变成现金，要避免浪费 - 天气影响客流，晴天客流最多，下雨客流最少 - 价格过高会降低购买人数 请根据当前状态和天气预告理性决策。 """.strip() def parse_json(text: str) -> dict: cleaned = re.sub(r"```json|```", "", text).strip() return json.loads(cleaned) class BaseAgent: def decide(self, state_text: str) -> dict: raise NotImplementedError class GPTAgent(BaseAgent): def __init__(self, model: str = "gpt-4o-mini", temperature: float = 0.2): self.model = model self.temperature = temperature self.client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def decide(self, state_text: str) -> dict: user_prompt = "当前状态：\n" + state_text try: resp = self.client.chat.completions.create( model=self.model, temperature=self.temperature, max_tokens=300, response_format={"type": "json_object"}, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_prompt}, ], ) return parse_json(resp.choices[0].message.content) except Exception as e: print("GPT call failed:", e) return self._fallback() def _fallback(self) -> dict: return { "buy_lemons": 0, "buy_sugar": 0, "buy_cups": 0, "price": 1.0, "advertise": 0, } class ClaudeAgent(BaseAgent): def __init__(self, model: str = "claude-3-5-sonnet-latest", temperature: float = 0.2): self.model = model self.temperature = temperature self.client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY")) def decide(self, state_text: str) -> dict: user_prompt = "当前状态：\n" + state_text try: resp = self.client.messages.create( model=self.model, max_tokens=300, temperature=self.temperature, system=SYSTEM_PROMPT, messages=[{"role": "user", "content": user_prompt}], ) text = resp.content[0].text return parse_json(text) except Exception as e: print("Claude call failed:", e) return self._fallback() def _fallback(self) -> dict: return { "buy_lemons": 0, "buy_sugar": 0, "buy_cups": 0, "price": 1.0, "advertise": 0, }

这里有两个值得注意的工程细节。

第一，解析函数parse_json剥离了模型可能输出的 Markdown 代码块标记。因为 Claude 在复杂任务中偶尔会输出 ````json包裹的内容，直接json.loads` 会失败。

第二，调用失败时返回一个保守决策，而不是抛出异常让整个实验终止。在真实 Agent 系统中，这对应“兜底动作”，可以避免因为模型临时故障导致业务流程中断。

5.3 主程序：run_experiment.py

# 文件路径：lemonade-lab/run_experiment.py import argparse import json import random from lemonade_env import LemonadeEnv from llm_agents import ClaudeAgent, GPTAgent WEATHER_CANDIDATES = ["sunny", "sunny", "cloudy", "cloudy", "rainy"] def main(): parser = argparse.ArgumentParser() parser.add_argument("--provider", choices=["gpt", "claude"], required=True) parser.add_argument("--days", type=int, default=7) parser.add_argument("--seed", type=int, default=42) parser.add_argument("--model", type=str, default=None) args = parser.parse_args() random.seed(args.seed) env = LemonadeEnv() if args.provider == "gpt": agent = GPTAgent(model=args.model or "gpt-4o-mini") else: agent = ClaudeAgent(model=args.model or "claude-3-5-sonnet-latest") records = [] for _ in range(args.days): forecast = random.choice(WEATHER_CANDIDATES) # 实际天气以 70% 概率与预报一致，模拟预报误差 if random.random() < 0.7: actual_weather = forecast else: actual_weather = random.choice(WEATHER_CANDIDATES) state_text = env.state_text(forecast) decision = agent.decide(state_text) for key in ["buy_lemons", "buy_sugar", "buy_cups", "price", "advertise"]: if key not in decision: decision[key] = 0 record = env.apply_decision(decision, actual_weather) records.append(record) print(json.dumps(record, ensure_ascii=False)) final_profit = env.cash - 20.0 total_sales = sum(r["sales"] for r in records) total_revenue = round(sum(r["revenue"] for r in records), 2) waste_lemons = sum(r["waste_lemons"] for r in records) print("\n=== SUMMARY ===") print(f"provider={args.provider} days={args.days} seed={args.seed}") print(f"final_cash={env.cash:.2f} total_profit={final_profit:.2f}") print(f"total_revenue={total_revenue} total_sales={total_sales} waste_lemons={waste_lemons}") with open("result_log.jsonl", "a", encoding="utf-8") as f: for r in records: f.write(json.dumps(r, ensure_ascii=False) + "\n") if __name__ == "__main__": main()

主程序的流程很清晰：固定随机种子、生成预报和实际天气、让模型决策、环境执行、记录日志。所有结果追加写入result_log.jsonl，方便后续统计。

注意，天气预报和实际天气之间存在 30% 的不一致概率。这是刻意设计的，目的是测试模型会不会因为盲目相信预报而采购失误。在真实经营中，天气预报本身就不是绝对准确的。

5.4 运行命令

确认.env文件存在后，先跑 GPT：

python run_experiment.py --provider gpt --days 7 --seed 42

再跑 Claude：

python run_experiment.py --provider claude --days 7 --seed 42

如果某个模型名称在你的账户下不可用，可以通过--model参数指定其他模型名：

python run_experiment.py --provider gpt --model gpt-4o --days 7 --seed 42

6. 运行结果与效果验证

运行成功后，控制台会持续输出每天的决策和经营结果。下面是一次典型运行的日志格式，不是特定模型的实测数据，而是用来展示日志结构：

{"day": 1, "weather": "sunny", "walkers": 48, "demand": 36, "capacity": 20, "sales": 20, "revenue": 24.0, "cash": 38.0, "waste_lemons": 0, "decision": {"buy_lemons": 20, "buy_sugar": 20, "buy_cups": 20, "price": 1.2, "advertise": 1}}

日志末尾会输出汇总信息：

=== SUMMARY === provider=gpt days=7 seed=42 final_cash=31.50 total_profit=11.50 total_revenue=48.00 total_sales=34 waste_lemons=8

如何判断实验是否成功？主要看四个方面：

• 程序没有因为 JSON 解析错误或 API 异常中断。
• 每天的现金不为负。
• 最终利润大于 0。
• 库存浪费量相对可控。

如果模型把采购量定得远超实际需求，累计利润可能为负，同时 waste_lemons 会非常高。这说明模型没有理解“库存不会自动变现”这一约束。

对比两组实验时，不要只看一次结果。建议固定天数，把种子分别设为 42、2024、7，各跑三轮并记录汇总利润，然后看平均值和波动范围。单次运行中，某天突然出现高温晴好天气，可能让某个模型偶然获得高收入，多轮平均能消除这种随机误差。

7. 常见问题与排查思路

在实际运行这个实验时，最容易出现问题的地方不是环境代码，而是模型调用和输出解析。下面列出我整理的高频问题。

问题现象	可能原因	排查方式	解决方案
调用 API 报AuthenticationError	API 密钥缺失或错误	检查.env文件是否存在，确认密钥前缀	修复密钥，重启终端让环境变量生效
返回的 JSON 不能解析	模型输出了 Markdown 代码块或额外文字	打印原始文本，确认parse_json是否覆盖常见格式	增强清洗逻辑：先剥离代码块，再尝试json.loads
连续几天采购为 0	模型把输出键名写错	查看日志中的decision字段	在提示词中强调字段名，并在主程序里增加默认值兜底
API 请求超时或限流	并发过高或网络不稳定	查看 SDK 返回的异常信息	增加超时参数，失败后重试；必要时限制并发
库存浪费很多	模型没有准确预测销量	对比天气预告、客流和采购量	改进提示词，加入前两天销售历史，引导模型动态调整
运行结果不稳定	随机种子没有固定	检查主程序是否调用了random.seed	在random.seed(args.seed)之后不要插入其他随机数调用
成本超预期	max_tokens设置过高或模型价格较高	统计每天的 token 消耗	调整max_tokens，优先使用gpt-4o-mini这类低成本模型

如果你遇到模型输出一直不合规，可以补充少量示例。在系统提示词中增加一个 JSON 示例，往往比反复修改字段说明更有效。

8. 最佳实践与工程建议

把柠檬水摊实验从“玩具”升级成“可用的 Agent 评测框架”，需要关注下面几个工程点。

8.1 提示词设计要显式给出约束

大模型在自由对话中擅长发散，但在决策闭环里必须收敛。系统提示词要把目标、字段、约束一次说清。尤其是“卖不掉的库存不会自动变现”这类反直觉规则，如果提示词不写出来，模型很容易把柠檬囤到发霉，然后亏损。

8.2 输出必须校验，不能直接信任模型

模型返回的 JSON 就算能被json.loads解析，也可能包含非法值。例如，price可能被输出成负数，buy_lemons可能被输出成字符串。生产级代码必须在环境执行前对每个字段做类型和范围校验。这个实验是在模拟环境里，即使出错也不会造成真实损失；但换到真实业务，例如自动定价或自动采购，输出校验就是安全底线。

8.3 增加历史记忆

当前版本的提示词只包含当天状态，模型看不到前一天发生了什么。这会让模型遗忘自己的失误，也无法从反馈中学习。在更接近真实系统的版本里，应该把最近 3 天的决策和结果摘要放进提示词：

最近三天： Day 3: 进20个柠檬，售出18杯，收入21.6，库存剩余2 Day 4: 进25个柠檬，售出12杯，收入9.6，库存剩余15 Day 5: 请根据以上销售趋势调整进货量。

这一步对利润提升非常明显，因为模型能够感知“昨天囤货太多”这个错误信号。

8.4 使用固定随机种子做公平对比

对比不同模型或不同提示词时，必须控制在单一变量原则下。除了模型身份，其他条件都应相同：天气序列、客流随机数、初始资金、总天数。用固定种子是成本最低、也最有效的公平性保障。

8.5 成本控制与失败兜底

调用 API 需要花钱，虽然单次决策很便宜，但跑大量实验时成本不可忽视。建议限制max_tokens=300，因为一个柠檬水摊决策 JSON 通常不到 100 个 token。同时在代码里加一层 try-except，失败时返回保守决策，保证整套实验能够跑完，而不是中途崩溃。

8.6 结果留痕

每一次运行都应该把完整日志落盘，包括原始状态、模型决策、天气、销量、现金。这不仅是为了复现结果，也是排查模型异常的重要依据。建议用 JSONL 格式，一行一条记录，后续用 Python 或数据库分析都很方便。

9. 总结与后续学习方向

这个柠檬水摊实验的核心价值，是让我们看到大模型的能力边界不在“会不会聊天”，而在“能不能在一个有约束、有反馈、有随机性的环境中持续做出合理决策”。GPT 和 Claude 都可能给出不错的单日决策，但连续多天经营后，能否控制库存、平衡价格和客流、应对天气预报误差，才是评价一个模型“是否具备 Agent 潜力”的重要标准。

如果你拿到了代码，建议先按默认参数跑通全流程，然后做三类改进：

• 第一，修改提示词，加入销售历史，观察利润变化。
• 第二，增加工具调用能力，让模型不仅做决策，还能查询历史销售数据、读取外部天气 API。
• 第三，把实验从“单模型决策”扩展成“多模型竞争”，例如让两个 Agent 分别经营两个摊位，再引入互相观察和竞争定价。

从工程角度看，这个 demo 已经包含了一个通用 Agent 系统的核心要素：状态管理、决策器、环境执行、日志记录、结果评估。把柠檬水摊替换成库存管理、投放策略、客户运营，套路完全一致。真正的难点从来不是调用一次大模型，而是如何围绕模型构建一套可信、可控、可评估的决策闭环。