1. 从 40.2% 说起：LifePlanner 到底在测什么
如果你最近在折腾地理空间智能体，大概率会刷到 LifePlanner 这个名字。它是一套地理空间规划基准，核心设定很接地气：在约 10 平方公里的城市空间里，铺开 3600 多个地点，再灌进约 20 万条社交媒体笔记与评论，然后让 LLM 智能体通过 MCP 工具集去检索证据、做规划。667 道题，四类任务，三档难度，复杂档 Pass Rate 只有 40.2%。
这个数字为什么值得单独拎出来讲？因为它不是"模型不够大"的问题。同一批模型在 L0 简单档能跑到 89.4%，到 L1 掉到 57.7%，L2 直接腰斩到 40.2%，Token 用量却从 24.6k 飙到 251.1k。也就是说，模型不是不会调工具，而是在"多步检索 + 隐式约束整合"这一步开始崩。论文把失败归因写得很直白：大数据库上的证据获取不完整、工具调用不精确、约束整合弱。
我先把题目形状还原一下，你才能理解后面配置为什么那么写。典型 L2 题：用户从办公室开车去见朋友，先去一个能接触短腿犬的场所，再去一个热门湖边日落点，要求抵达时都在营业，且最小化总驾驶时间。输入是地图 POI、路网，加上每个地点最多 20 条小红书笔记（每条最多 10 条评论）。标准答案是地点选择、访问顺序与路线的结构化 JSON。
注意这里的坑：营业时间藏在评论里，短腿犬友好藏在笔记里，日落点"热门"要靠社交信号判断，而"最小化总驾驶时间"是全局约束。L0 只需一次检索就能答，L1 要多次检索加无约束计算，L2 必须把隐式约束和检索证据整合成全局有效计划。40.2% 就是卡在最后这层整合上。
所以这篇不是复述论文结论，而是交付一套你能跑起来的评测配置：任务集怎么组织、评分脚本怎么写、MCP 接入参数怎么填、报错怎么排。目标很明确——让你在自己的机器上复现这条 GeoAI 智能体评测链路，而不是看完点个收藏。
适合谁看：正在做地理空间 Agent 的工程师、想给规划类能力建回归集的团队、以及被"工具调了但结果不对"折磨过的人。如果你只关心模型排行榜，这篇可能不对胃口；如果你想搞清楚可靠性在哪一步掉下去，往下走。
2. 前置准备：TaoToken 接入与 MCP 工具链选型
在写评分脚本之前，得先把模型侧和工具侧接好。模型侧我用 TaoToken 做统一入口，原因是它同时提供 OpenAI 兼容接口和 Anthropic 兼容接口，LifePlanner 这类评测经常要在不同骨干之间切换，统一 Base URL 能省掉大量改配置的功夫。
先拿 Key。打开 https://taotoken.net/api-keys ，登录后创建一个新 Key，复制出来。注意这个 Key 只在创建时完整显示一次，丢了就重新建。控制台在 https://taotoken.net/console ，可以看用量和余额。
Base URL 分两种写法，别搞混：
- OpenAI 兼容：
https://taotoken.net/api/v1 - Anthropic 兼容：
https://taotoken.net/api
模型对话调试入口在 https://taotoken.net/model-chat ，接入文档在 https://taotoken.net/doc 。如果你要长期跑编码类 Agent，可以看 Coding Plan：https://taotoken.net/coding-plan 。
工具侧有两个 MCP 方案值得摆在一起对比，因为它们定位完全不同：
| 方案 | 定位 | 工具数量 | 适合场景 |
|---|---|---|---|
| GIS MCP Server | 通用 GIS 库封装 | 92+ | 缓冲区、坐标转换、空间统计 |
| geo-assistant-mcp-toolset | POI + 影像端到端 | 工具链 | Overture POI、DuckDB 空间 SQL、NAIP 影像 |
GIS MCP Server 把 Shapely、PyProj、GeoPandas、Rasterio、PySAL 这些库统一暴露成 MCP 工具，智能体收到空间查询时路由到对应工具，而不是手写整段 Python。geo-assistant-mcp-toolset 是 Development Seed 的只读地理助手，调用链是get_place → get_search_area → places_within_area / fetch_naip_image → interpret_image，中间的几何与影像通过 session state 以@state:<key>句柄传递，不进模型上下文。
这个设计差异很关键。LifePlanner 的失败模式之一是证据获取不完整，而把大块几何和影像挡在上下文之外，能同时降 token 和降幻觉。所以我的评测配置里，POI 检索走 geo-assistant 那条链，空间计算走 GIS MCP Server，两者互补。
还有一个参考项是 GeoForge，它不改骨干权重，靠三层非参数记忆自进化：Workflow Graph Memory 记全局操作顺序，Action-Level Experiences 记局部修正，Adapted Skill SOP 记流程与数据约束。论文报告 GPT-5 从 63.16% 提到 74.33%，消融去掉 Skill 记忆后掉到 52.66%。这套思路可以后置到你的评测闭环里，但第一步先把基础链路跑通。
3. 可复制配置：任务集、评分脚本与 MCP 参数
这一节是全文最干的部分，配置直接抄。先建目录结构：
lifeplanner-eval/ ├── tasks/ │ ├── L0.jsonl │ ├── L1.jsonl │ └── L2.jsonl ├── config/ │ ├── mcp_settings.json │ └── model.toml ├── scripts/ │ ├── run_eval.py │ └── score.py └── outputs/任务集按难度分文件，每行一条 JSON。L2 的题目结构长这样，字段名和论文口径对齐：
{ "task_id": "L2_0042", "difficulty": "L2", "query": "从办公室开车去见朋友，先去能接触短腿犬的场所，再去热门湖边日落点，抵达时均需营业，最小化总驾驶时间", "start_poi": "office_001", "constraints": { "implicit": ["dog_friendly", "sunset_view", "popular"], "explicit": ["open_at_arrival", "minimize_drive_time"] }, "evidence_pool": "social_notes_20k", "answer_schema": { "places": ["poi_id"], "order": ["poi_id"], "route": ["edge_id"] } }MCP 接入参数写进config/mcp_settings.json。这里同时挂两个 server，注意command和args按你本地实际路径改：
{ "mcpServers": { "gis-mcp": { "command": "uvx", "args": ["gis-mcp@0.15.0"], "env": { "GIS_MCP_MODE": "readonly" } }, "geo-assistant": { "command": "python", "args": ["-m", "geo_assistant_mcp.server"], "env": { "DUCKDB_PATH": "./data/overture.duckdb", "OLLAMA_HOST": "http://localhost:11434", "VISION_MODEL": "gemma4:cloud" } } } }模型配置用 TOML，方便在骨干之间切换：
[model] provider = "taotoken" base_url = "https://taotoken.net/api/v1" api_key_env = "TAOTOKEN_API_KEY" model_id = "claude-opus-5" max_tokens = 8192 temperature = 0.0 [eval] task_dir = "./tasks" output_dir = "./outputs" max_steps = 100 step_timeout_sec = 30如果你用的是 Claude Code 这类走 Anthropic 协议的客户端，Base URL 换成https://taotoken.net/api，Key 和 Model ID 三件套保持一致即可。Cline 里配 MCP 也是同样三件套：Base URL、Key、Model ID，缺一个就连不上。
评分脚本的核心逻辑是结构化比对，不是字符串匹配。score.py关键片段：
import json def score_task(pred, gold, difficulty): if difficulty == "L0": return pred["places"] == gold["places"] if difficulty == "L1": return pred["places"] == gold["places"] and pred["order"] == gold["order"] # L2 需要同时校验地点、顺序、路线与约束 place_ok = set(pred["places"]) == set(gold["places"]) order_ok = pred["order"] == gold["order"] route_ok = pred["route"] == gold["route"] return place_ok and order_ok and route_ok跑评测：
export TAOTOKEN_API_KEY="你的Key" python scripts/run_eval.py --config config/model.toml --difficulty L2 python scripts/score.py --outputs outputs/ --report report.jsonrun_eval.py里要做的一件事是限制步数。LifePlanner 的 L2 平均 Token 到 251.1k，不设上限很容易烧穿预算。max_steps = 100和step_timeout_sec = 30是我实测下来比较稳的值，再低会误杀正常多步检索。
4. 验证请求：从单题到全量跑通
配置写完别急着全量跑，先拿一道 L2 题验证链路。第一步验证模型侧通不通：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-opus-5", "messages": [{"role": "user", "content": "返回 JSON: {\"ok\": true}"}], "temperature": 0 }'返回里能看到choices[0].message.content就说明模型侧通了。如果这里就报错，先看第 5 节的排障。
第二步验证 MCP 工具能不能被调起来。单独跑一次工具发现：
python -c " from mcp import ClientSession, StdioServerParameters import asyncio, json async def main(): params = StdioServerParameters(command='uvx', args=['gis-mcp@0.15.0']) async with ClientSession(params) as session: tools = await session.list_tools() print(json.dumps([t.name for t in tools.tools], indent=2)) asyncio.run(main()) "正常会打印出 92 个工具名，包含buffer、project_geometry、spatial_join这类。如果只出来几个或者报连接失败，多半是uvx没装或版本不对。
第三步跑单题：
python scripts/run_eval.py \ --config config/model.toml \ --task-id L2_0042 \ --verbose--verbose会打印每一步的工具调用、参数、观测和中间产物路径。这是我踩过坑之后加上的——L2 失败往往不是最后答案错，而是中间某一步检索漏了证据。看轨迹比看结果有用得多。
单题跑通后，先跑 L0 全量确认评分脚本没写反：
python scripts/run_eval.py --config config/model.toml --difficulty L0 python scripts/score.py --outputs outputs/ --report report_L0.jsonL0 应该接近 89% 这个量级。如果 L0 都跑不到 80%，问题在链路不在模型，回去查 MCP 参数。L0 正常后再跑 L1、L2，对比三档的 Pass Rate 和 Token 用量，你就能复现出论文里那条从 89.4% 到 40.2% 的曲线。
跑完 L2 后重点看失败样本的轨迹。我实测下来，失败集中在三类：一是评论里的营业时间没被检索到，二是"热门"这种社交信号没被量化，三是多个约束各自满足但组合起来冲突。这三类正好对应论文说的证据获取不完整、工具调用不精确、约束整合弱。
5. 常见报错排查：401、local proxy failed 与 choices 读取失败
这一节按真实报错来，遇到哪个查哪个。
401 Unauthorized。最常见的原因是 Key 没导出到环境变量，或者导出后没重新开 shell。检查：
echo $TAOTOKEN_API_KEY如果为空，export TAOTOKEN_API_KEY="..."后重开终端。另一个原因是 Base URL 写错，OpenAI 兼容必须是https://taotoken.net/api/v1，少写/v1会 404 或 401。Anthropic 兼容是https://taotoken.net/api，两者不能混用。
local proxy failed / connection refused。这个报错通常出现在 MCP server 启动阶段，不是模型侧问题。先确认uvx可用：
uvx --version没有就装 uv。然后确认gis-mcp@0.15.0这个版本号存在，写错版本会拉取失败。如果是 geo-assistant 报这个错，检查DUCKDB_PATH指向的文件是否存在，DuckDB 打不开会直接导致 server 起不来。
reading 'choices' of undefined。这是解析响应时字段不存在。原因一般是模型返回了错误对象而不是正常 completion，但脚本直接读了choices。加一层防御：
resp = requests.post(url, headers=headers, json=payload).json() if "choices" not in resp: raise RuntimeError(f"unexpected response: {resp}") content = resp["choices"][0]["message"]["content"]这样报错会直接告诉你上游返回了什么，而不是一句 undefined。常见上游错误是模型 ID 写错，比如把claude-opus-5写成claude-opus-5.0。
OAuth 相关报错。如果你用 Claude Code 或 Codex 这类客户端，可能会碰到 OAuth 流程问题。Codex 的auth.json里如果残留了旧凭据，会覆盖你新配的 Base URL 和 Key。处理方式是清掉~/.codex/auth.json里的旧字段，只保留：
{ "base_url": "https://taotoken.net/api/v1", "api_key": "你的Key", "model": "claude-opus-5" }三件套 Base URL、Key、Model ID 必须同时正确，缺一个就会走到 OAuth 回退逻辑然后失败。CC Switch 里切换配置时同理，切完确认三件套都生效再跑评测。
评分脚本报 KeyError: 'route'。说明模型返回的 JSON 缺字段。L2 的 answer_schema 要求 places、order、route 三个字段，模型可能只给了前两个。在run_eval.py里加 schema 校验，缺字段直接判失败并记录，不要让它进评分函数。
Token 用量异常高。如果单题超过 300k，检查是不是max_steps没生效，或者工具返回的观测没做截断。geo-assistant 的 session state 句柄机制就是为了避免大对象进上下文，如果发现影像 base64 直接进了消息历史，说明句柄传递没配对。
6. 把评测跑成回归集：下一步怎么用
链路跑通之后，这套东西的价值不在单次跑分，而在变成回归集。每次改工具参数、换骨干、调 prompt，都跑一遍 667 题，看三档 Pass Rate 的位移。L0 掉说明基础检索坏了，L1 掉说明多步检索出问题，L2 掉说明约束整合退化——分层定位比看总分有用。
如果你要做长期编码或 Agent 迭代，Coding Plan 那条线可以配合用：https://taotoken.net/coding-plan 。模型对话调试继续用 https://taotoken.net/model-chat ，接入细节查 https://taotoken.net/doc ，Key 管理在 https://taotoken.net/api-keys 。
最后留一个实用技巧：把 L2 的失败样本按失败类型打标，攒到几十条之后，你会发现大部分错误集中在少数几个约束组合上。针对这几个组合补检索策略或加校验步骤，比盲目换更大的模型有效得多。40.2% 这个数字不可怕，可怕的是不知道剩下 59.8% 错在哪一步。
