智能体交易全流程实战：从 Anthropic 市场实验到小龙虾门店 AI 采购助手落地

把一波 AI 热点拆成可复现 Demo：双智能体议价、API 调用、审计日志、调试排错与上线建议一次讲清

拿到这篇文章，你最终能做出一个最小可复现 Demo：两个 AI Agent 分别扮演小龙虾门店采购和供应商销售，在 3 轮内完成询价、还价、成交判断，并输出 deal.json 和 audit.log。它不是新闻里的现成产品，而是把 2026 年 4 月这一波 AI 热点，拆成开发者可以动手复现的工程模板。

工具资源导航

如果你看完这波热点，想顺手把方案跑起来或者把账号环境补齐，这两个入口可以先收藏：

• API调用：主打各种主流模型接入、稳定转发和低门槛调用。
• GPT代购：官方渠道GPT PLUS/pro充值，秒到账，可开发票

文末资源导航属于工具信息整理，请结合平台规则和自身需求判断。

一、事实描述：这波热点到底发生了什么

先把事实和观点分开，免得一不小心把新闻解读成许愿池。

• 2026-04-25，TechCrunch AI：Anthropic 做了一个测试型分类信息市场，让 AI 智能体分别代表买家和卖家，并且达成了真实交易。
• 2026-04-26，The Washington Post 的一篇观点文章：标题是《Will AI end anonymity? I tested it.》。从标题可确认，这条讨论的是 AI 对匿名性的冲击；摘要未展开更多细节，所以这里不补脑补剧情。
• 2026-04-26，Futurism：一家具备华尔街背景的律师事务所，因为在法庭场景中的 AI 使用被发现而陷入尴尬。这个标题本身已经足够说明一个风险：AI 输出不能直接越过人工复核。
• 2026-04-26，PR Newswire：Nexar 任命 Jen Vescio 进入董事会，同时强调 Physical AI 正在规模化进入商业出行场景。
• 2026-04-26，The Guardian：英国不同部门对 AI 数据中心的能源需求存在分歧。
• 2026-04-26，韩国媒体 매일경제：IA 宣布将 AI 基础设施作为新的业务战略方向。

二、观点分析：AI 正从会聊天，走向会交易、会留下责任链

把这些新闻放一起看，信号很明确：AI 已经不只是一个回答问题的窗口，而是在向三件事迁移。

1. 从内容生成走向行动执行：Anthropic 的实验说明，Agent 不只是写文案，它可以代表角色做出交易决策。
2. 从线上文本走向现实世界：Nexar 那条新闻提醒我们，Physical AI 一旦进入商业出行、供应链、门店运营，延迟、可靠性和安全边界都不是可选项。
3. 从效率工具走向责任工具：匿名性、法庭场景、能源消耗，这些热点都在提醒开发者一件事：你能不能接上 API，已经不是问题；你敢不敢让它自动执行，以及如何留痕、限权、复核，才是问题。

所以这篇实战的重点不是把 Agent 写得多玄学，而是把它写得可复现、可控、可审计。

三、场景定义：做一个小龙虾门店 AI 采购议价助手

先说明边界：**下面这个小龙虾案例是教学 Demo，不是新闻中的真实业务。**我只是借 Anthropic 的交易实验，抽象出一个最适合开发者上手的实体行业场景。

业务设定如下：

• 门店晚高峰后发现次日库存不足
• 需要补货 60 斤小龙虾
• 目标单价不高于 26
• 最晚次日早上 8:00 到店
• 买方 Agent 负责压价和时效约束
• 卖方 Agent 负责根据库存、底价、起订量回报价
• 系统只生成订单草案，不直接对外发送正式订单

这类场景很适合副业项目、SaaS 原型和门店运营助手，因为流程清晰、收益点明确，而且天然需要日志留存。

四、技术栈：尽量轻，先跑起来

为了保证可复现，先用最小栈：

• Python 3.11
• requests：调用兼容聊天接口
• json：保存成交草案与审计日志
• 任意兼容 Chat Completions 风格的模型 API

项目目录可以只放一个文件：

bash
agent_market_demo.py

安装依赖：

bash
python -m venv .venv
source .venv/bin/activate
pip install requests

五、步骤 1：写最小可运行版本

下面这段代码的目标很朴素：让两个 Agent 谈判 3 轮，能成交就写入 deal.json，不成交也要留下 audit.log。先别追求它像顶级采购总监，先让它别把自己聊丢了。

python
import os, json, requests

BASE_URL = os.getenv(‘BASE_URL’, ‘https://your-api-host/v1’)
API_KEY = os.getenv(‘API_KEY’)
MODEL_NAME = os.getenv(‘MODEL_NAME’, ‘your-model-name’)

def call_llm(system_prompt, user_text, temperature=0.2):
payload = {
‘model’: MODEL_NAME,
‘temperature’: temperature,
‘messages’: [
{‘role’: ‘system’, ‘content’: system_prompt},
{‘role’: ‘user’, ‘content’: user_text}
]
}
r = requests.post(
f’{BASE_URL}/chat/completions’,
headers={
‘Authorization’: f’Bearer {API_KEY}',
‘Content-Type’: ‘application/json’
},
json=payload,
timeout=60
)
r.raise_for_status()
return r.json()[‘choices’][0][‘message’][‘content’]

def to_json(text):
text = text.replace(‘’, ‘’).replace(‘’, ‘’).strip()
return json.loads(text)

buyer_system = ‘’’
你是门店采购助手。
目标：单价不高于 26，数量不少于 60，最晚明早 8:00 送达。
输出严格 JSON：
{‘action’: ‘counter|accept|reject’, ‘unit_price’: 数字, ‘quantity’: 数字, ‘delivery_time’: ‘文本’, ‘message’: ‘一句话’}
‘’’

seller_system = ‘’’
你是供应商销售助手。
约束：库存 80，底价 24，低于 50 斤不送货。
输出严格 JSON：
{‘action’: ‘counter|accept|reject’, ‘unit_price’: 数字, ‘quantity’: 数字, ‘delivery_time’: ‘文本’, ‘message’: ‘一句话’}
‘’’

state = {
‘item’: ‘小龙虾’,
‘need_qty’: 60,
‘target_price’: 26,
‘latest_arrival’: ‘明早 8:00’
}

history = []
current = json.dumps(state, ensure_ascii=False)

for round_id in range(3):
buyer_offer = to_json(call_llm(buyer_system, current, 0.2))
seller_offer = to_json(call_llm(seller_system, json.dumps(buyer_offer, ensure_ascii=False), 0.2))
history.append({‘round’: round_id + 1, ‘buyer’: buyer_offer, ‘seller’: seller_offer})

if seller_offer['action'] == 'accept' and seller_offer['unit_price'] <= 26 and seller_offer['quantity'] >= 60:
    with open('deal.json', 'w', encoding='utf-8') as f:
        f.write(json.dumps(seller_offer, ensure_ascii=False, indent=2))
    break

current = json.dumps(seller_offer, ensure_ascii=False)

with open(‘audit.log’, ‘w’, encoding=‘utf-8’) as f:
f.write(json.dumps(history, ensure_ascii=False, indent=2))

print(history[-1])
print(‘输出仅作为订单草案，需人工确认后再外发’)

运行方式：

bash
API_KEY=你的密钥 MODEL_NAME=你的模型 BASE_URL=你的接口前缀 python agent_market_demo.py

六、步骤 2：让结果更稳，而不是更会胡说

这个 Demo 能跑，不等于它稳定。真正影响复现率的，通常是这三个点：

1）把提示词写成规则，不要写成散文

像上面这样直接限定字段、动作枚举、交付条件，模型更容易输出结构化结果。否则它很可能在第三轮突然开始发表对餐饮行业的看法，仿佛参加了论坛圆桌。

2）把业务约束前置成显式输入

比如库存 80、底价 24、低于 50 不送货，这些都应该明确给 Seller Agent。不要期待模型自己悟出你的供应链规则。

3）默认开启审计日志

audit.log 不是装饰品。它能帮你回答三个上线后一定会遇到的问题：

• 为什么成交了这个价格？
• 是哪一轮开始偏离规则的？
• 这份草案到底是人确认的，还是 Agent 自己冲出去发的？

七、调试排错：开发者最常踩的 4 个坑

坑 1：模型不输出 JSON

处理方式：

• 把 temperature 先降到 0 或 0.2
• system prompt 里要求严格 JSON
• 对输出先做去代码块清洗，再 json.loads

坑 2：两个 Agent 无限拉扯，像在进行哲学辩论

处理方式：

• 限制最大轮次为 3 到 5
• 给 Buyer 明确保留价
• 给 Seller 明确底价和库存
• 超时后直接转人工

坑 3：把敏感信息原样塞进提示词

2026-04-26 那篇关于匿名性的观点文章，至少给我们一个工程提醒：**别把不必要的身份信息交给模型。**门店地址、联系人电话、历史采购人姓名，都应做最小化输入或脱敏。

坑 4：让 AI 输出直接进入正式法律或合同链路

Futurism 同日那条关于律师事务所的新闻，已经把风险提示写在标题上了。外部合同、法律文本、正式函件这类内容，必须加人工复核。Agent 可以写草稿，但别让它自己按发送键。

八、上线建议：从 Demo 到业务原型，至少补这 5 件事

1. 加人工确认关口：成交草案进入待审核队列，不要自动外发。
2. 加权限白名单：Agent 能调用哪些工具、能否发消息、能否下单，都要显式控制。
3. 加成本上限：限制单次任务轮数、最大 token、重试次数。
4. 加状态机：把流程拆成询价、还价、成交、待审核、已驳回，别靠一段 if else 硬撑全世界。
5. 加可追踪 ID：每次议价都生成任务编号，日志、草案、人工审批都挂同一个 ID。

如果你准备把场景从门店采购扩展到配送、仓储、车队协同，那么 Nexar 那条 Physical AI 相关新闻也值得放在脑子里：一旦 AI 影响真实世界，延迟和安全就是产品功能，不是彩蛋。

九、成本与合规注意点：别只盯着效果图

成本

• 双 Agent 天生比单 Agent 更费 token
• 轮次越多，成本越高，结果未必越好
• 最实用的优化不是让它多想，而是让规则更明确

合规

• 匿名性相关信息做最小化输入
• 对外文本保留 AI 生成或 AI 辅助痕迹，避免责任不清
• 涉及真实交易时，保留人工审批记录

基础设施

2026-04-26 关于 AI 数据中心能源需求的报道，以及 IA 把 AI 基础设施上升为业务战略的新闻，放到开发现场就是一句大白话：**能少打一轮模型，就别多烧一轮。**优化提示词、减少无效重试、控制上下文长度，既省钱，也更现实。

十、结尾总结：现在最值得做的，不是更大的 Agent，而是更稳的闭环

回到最初那条新闻，Anthropic 的实验之所以值得关注，不是因为它证明了 AI 会讨价还价，而是因为它把一个更大的命题摆到了台面上：智能体开始代表用户做事了。

对开发者、技术运营、想做副业项目的人来说，这意味着机会点已经从单纯的内容生成，转向了交易协同、门店运营、供应链助手、审计留痕这些更接近真实业务的场景。

如果你今天就想动手，最好的起点不是做一个万能超级 Agent，而是先复现本文这个最小闭环：

• 一个真实业务约束
• 两个职责清晰的 Agent
• 一份结构化输出
• 一条完整审计链
• 一个必须经过人工确认的出口

这套骨架一旦搭起来，后面你把小龙虾换成食材、耗材、活动物料，甚至换成企业内部采购单，路基本就通了。AI 会不会取代采购员还早，但它先取代重复拉扯的表格和聊天记录，这事已经很近了。