1. 为什么“创造力评估”在 AI Agent 场景里这么难做先说一个我自己的观察当你让一个基于 LangChain 编排的 Agent 去“设计一个校园二手交易平台”时它给出的方案往往结构完整、条理清晰甚至还会主动补上“信用分体系”“智能推荐”这些模块。第一次看会觉得惊艳但如果你连续跑十次同一个任务就会发现它的输出高度收敛——换汤不换药只是把“信用分”换成“信誉评级”把“智能推荐”换成“个性化匹配”。这就是 AI Agent Harness Engineering 里最容易被忽略的问题我们到底在评估“输出质量”还是在评估“创造力”这两件事完全不是一回事。一个 Agent 可以生成语法完美、逻辑通顺、覆盖全面的方案但它可能只是在做组合式复用——把训练数据里见过的模块重新排列。而真正创新应该是提出训练数据里很少出现、甚至从未出现的思路。在 Harness Engineering 的语境下创造力评估的核心难点有三个。第一缺乏对照基线。你说这个方案“新颖”那跟什么比跟训练语料比跟人类专家方案比跟 Agent 自己历史输出比没有基线新颖性就是一句空话。第二维度混淆。很多人把“有用”当成“有创意”但一个完全复述教科书内容的回答可以非常有用却毫无创意。第三评估不可复现。靠人打分成本高、主观性强换个评估者结论就变了。所以这篇文章要交付的不是一套“理论框架”而是一套可复制、可跑分、可复盘的评估配置。我会用 LangChain 搭一个最小的创意生成 Agent然后给它配上一套包含任务集、评分维度、对照基线的评估流程最后通过跑分对比和失败样例复盘帮你判断你手里的 Agent到底是在组合还是在创新。适合谁看如果你正在用 LangChain 或类似框架做 Agent 编排想量化它的创意能力边界或者你是产品/技术负责人需要判断“AI 生成方案”是否具备差异化价值这篇都能直接拿去改。前置知识只需要会 Python、了解 LLM 基本调用即可LangChain 不熟也没关系配置我会写全。核心检索词先明确AI Agent 创造力评估本质是区分“组合式复用”与“真正创新”的一套量化方法。下面从环境准备开始一步步落地。2. TaoToken 前置把模型调用统一成可切换的配置在动手写评估代码之前有一个前置问题必须先解决模型调用入口。创造力评估天然需要对比不同模型、不同温度下的输出差异如果你每个模型都去单独申请 Key、单独改代码评估流程根本跑不起来。我试过最省事的做法是用 TaoToken 作为统一的模型接入层把 Base URL、Key、Model ID 三件套固定下来后面切换模型只改一个字符串。TaoToken 在这里扮演的角色很明确它是一个兼容 OpenAI 接口规范的模型调用入口你拿到的 API Key 可以同时驱动对话模型和编码类模型。对创造力评估来说这意味着你可以用同一套 LangChain 代码把model参数从gpt-4o-mini换成别的模型跑分对比时不用动评估逻辑。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址后面不加任何 UTM 参数直接填进配置即可。具体要准备的东西就三样Base URLhttps://taotoken.net/api这是所有请求的根地址LangChain 的ChatOpenAI通过base_url参数接收。API Key在控制台创建形如sk-开头的一串字符。创建入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 进去后找 API Keys 页面即可。Model ID这是最容易被忽略的一环。很多人只填 Base URL 和 Key结果请求报model not found。Model ID 必须和你账号下可用的模型名完全一致比如对话类常用gpt-4o-mini、claude-3-5-sonnet这类标识。你可以在模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 先手动发一条消息确认模型可用再把它的 ID 抄进配置。为什么强调“三件套必须写全”因为创造力评估里模型本身就是变量。同一套任务集用不同 Model ID 跑出来的新颖性分数可能差很多。如果你只配了 Base URL 和 Key却没固定 Model ID跑分对比就失去了意义。我踩过的坑是早期评估脚本里模型名写死在代码里后来想换模型对比改了十几处还漏了一处导致结果混入旧模型输出白跑一轮。另外如果你后续要做长期编码类 Agent 的创造力跟踪比如让 Agent 持续产出代码方案并评估其创新性可以考虑 Coding Plan 这类长期额度方案入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。它适合需要反复跑评估、消耗量大的场景避免每次评估都临时充值。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 遇到接口细节问题可以先查这里。把这三件套准备好写进.env文件后面的 LangChain 代码就能直接读取。这一步看起来简单但它是整个评估流程可复现的前提——配置不统一跑分不可信。3. 可复制配置任务集、评分维度与对照基线这一节是全文的核心我会把评估配置拆成三块任务集评什么、评分维度怎么打分、对照基线跟谁比。每一块都给出可直接复制的 JSON/TOML 片段路径和字段名保持一致你复制过去改改就能用。3.1 任务集配置tasks.json任务集决定了评估的覆盖面。创造力评估最忌讳只用一两个任务就下结论因为不同任务对“创新”的要求不一样。我建议至少覆盖三类开放设计类如产品方案、约束求解类如给定预算做活动策划、跨域迁移类如把某个领域的机制搬到另一个领域。下面是一个可直接用的tasks.json{ tasks: [ { id: task_001, type: open_design, prompt: 请设计一个帮助大学生管理时间的应用要求包含核心功能、差异化亮点和落地路径。, reference_corpus: [ 番茄钟应用通过定时提醒帮助用户专注核心功能是倒计时和任务清单。, 日程管理应用通常包含日历视图、提醒推送和任务分类功能。, 时间管理方法包括四象限法、GTD 工作法、番茄工作法等。 ] }, { id: task_002, type: constrained_solving, prompt: 预算 5000 元为一家社区书店策划一场吸引年轻人的线下活动给出完整方案。, reference_corpus: [ 书店活动常见形式包括读书分享会、作者签售、主题展览。, 低成本活动可以联合周边咖啡馆、手作工坊做联名。, 吸引年轻人常用手段是社交媒体打卡、限量周边、盲盒。 ] }, { id: task_003, type: cross_domain, prompt: 借鉴游戏化机制设计一套提升员工内部知识分享积极性的方案。, reference_corpus: [ 游戏化常用元素包括积分、徽章、排行榜、任务系统。, 知识分享平台常见激励是积分兑换、等级特权。, 员工激励理论包括马斯洛需求层次、双因素理论。 ] } ] }注意reference_corpus字段——它就是每个任务的局部对照基线。新颖性计算时Agent 输出会跟这个语料库做相似度比较。语料库不需要很大但必须覆盖“常规思路”否则新颖性分数会虚高。比如 task_001 里放了番茄钟、日程管理、时间管理方法三条基本覆盖了最常见的方向Agent 如果只是把这些拼起来相似度就会偏高新颖性分数自然低。3.2 评分维度配置scoring.toml评分维度我用 TOML 写因为权重和阈值用 TOML 表达比 JSON 更清晰。下面这份scoring.toml定义了三个维度、权重和创造力类型判断阈值[weights] novelty 0.4 usefulness 0.4 surprisingness 0.2 [thresholds] # 新颖性高于此值且有用性达标判为真正创新 novelty_transformational 0.7 # 新颖性高于此值且有用性达标判为组合创新 novelty_combinatorial 0.3 # 有用性最低门槛 usefulness 0.5 # 惊喜性辅助门槛真正创新时参考 surprisingness 0.4 [model] base_url https://taotoken.net/api model_id gpt-4o-mini temperature 0.7 eval_temperature 0.0这里有两个温度参数要区分temperature是生成 Agent用的设 0.7 是为了让输出有一定随机性否则每次跑都一样评估没意义eval_temperature是评估 LLM用的必须设 0保证打分稳定可复现。很多人评估结果飘忽不定就是因为评估模型温度没归零。权重怎么定开放设计类任务可以适当提高新颖性和惊喜性权重工程类任务提高有用性权重。上面这套 0.4/0.4/0.2 是通用起点你可以按任务类型在代码里覆盖。3.3 对照基线三层比较光有局部语料库还不够我建议做三层对照第一层与参考语料库比算新颖性这是最基础的。第二层与 Agent 自身历史输出比。同一个任务跑多次如果每次输出高度相似说明它在“复读”不是在创新。第三层与人类基线比。找几个人对同一任务写方案把 Agent 输出和人类输出放在一起用同样的评估维度打分看差距在哪。第三层最费事但最有价值。我实测下来Agent 在“结构完整性”上经常超过人类但在“意外性”上普遍偏低——人类会提出一些看似不相关但很妙的点子Agent 很少。这个差距就是判断“组合”还是“创新”的关键信号。把这三块配置准备好放进项目目录config/tasks.json、config/scoring.toml。下面进入代码实现。4. 验证请求跑分对比与成功结果解读配置就绪后写评估代码。核心逻辑是读配置 → 生成 Agent 输出 → 计算三个维度分数 → 综合判断类型 → 输出跑分表。下面给出关键实现完整可跑。4.1 读取配置与初始化import json import tomllib from pathlib import Path from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 读取配置 with open(config/tasks.json, r, encodingutf-8) as f: tasks_config json.load(f) with open(config/scoring.toml, rb) as f: scoring tomllib.load(f) BASE_URL scoring[model][base_url] MODEL_ID scoring[model][model_id] GEN_TEMP scoring[model][temperature] EVAL_TEMP scoring[model][eval_temperature] # 生成用 LLM gen_llm ChatOpenAI( modelMODEL_ID, base_urlBASE_URL, api_key你的API_KEY, # 实际从环境变量读取 temperatureGEN_TEMP, ) # 评估用 LLM温度归零 eval_llm ChatOpenAI( modelMODEL_ID, base_urlBASE_URL, api_key你的API_KEY, temperatureEVAL_TEMP, )注意base_url直接来自配置指向https://taotoken.net/api。这样切换模型只改 TOML 里的model_id代码不动。4.2 生成 Agent 输出gen_prompt ChatPromptTemplate.from_messages([ (system, 你是一位富有创造力的专家擅长提出新颖、有用且令人惊喜的方案。 请避免陈词滥调给出具体可落地的思路。), (human, {task}), ]) gen_chain gen_prompt | gen_llm | StrOutputParser() def generate(task_prompt: str) - str: return gen_chain.invoke({task: task_prompt})4.3 三个维度打分新颖性用 TF-IDF 余弦相似度取 1 减平均相似度def calc_novelty(content: str, corpus: list[str]) - float: texts corpus [content] vectorizer TfidfVectorizer(stop_wordsenglish) try: matrix vectorizer.fit_transform(texts) except ValueError: return 0.5 sims cosine_similarity(matrix[-1], matrix[:-1])[0] return float(max(0.0, min(1.0, 1 - np.mean(sims))))有用性和惊喜性用 LLM 打分提示词要求只返回数字def llm_score(content: str, task: str, dimension: str) - float: criteria { usefulness: 评估内容对完成任务的帮助程度0 到 1 分。, surprisingness: 评估内容是否情理之中意料之外0 到 1 分。, } prompt ChatPromptTemplate.from_messages([ (system, f你是客观评估专家。{criteria[dimension]} 只返回一个 0 到 1 之间的数字不要任何其他文字。), (human, 任务{task}\n\n内容{content}\n\n分数), ]) chain prompt | eval_llm | StrOutputParser() try: return float(max(0.0, min(1.0, float(chain.invoke( {task: task, content: content}).strip()))) except Exception: return 0.54.4 综合评估与跑分表def evaluate_one(task: dict) - dict: content generate(task[prompt]) novelty calc_novelty(content, task[reference_corpus]) usefulness llm_score(content, task[prompt], usefulness) surprisingness llm_score(content, task[prompt], surprisingness) w scoring[weights] composite (novelty * w[novelty] usefulness * w[usefulness] surprisingness * w[surprisingness]) t scoring[thresholds] if novelty t[novelty_transformational] and usefulness t[usefulness]: ctype 真正创新 elif novelty t[novelty_combinatorial] and usefulness t[usefulness]: ctype 组合创新 else: ctype 非创新 return { task_id: task[id], novelty: round(novelty, 3), usefulness: round(usefulness, 3), surprisingness: round(surprisingness, 3), composite: round(composite, 3), type: ctype, } results [evaluate_one(t) for t in tasks_config[tasks]] for r in results: print(r)跑完之后你会得到类似这样的输出{task_id: task_001, novelty: 0.42, usefulness: 0.78, surprisingness: 0.35, composite: 0.55, type: 组合创新} {task_id: task_002, novelty: 0.31, usefulness: 0.72, surprisingness: 0.28, composite: 0.47, type: 组合创新} {task_id: task_003, novelty: 0.68, usefulness: 0.65, surprisingness: 0.52, composite: 0.63, type: 组合创新}怎么解读task_003 的新颖性 0.68 已经接近真正创新阈值 0.7说明跨域迁移类任务更容易激发 Agent 的“创新感”因为它需要把游戏化机制搬到员工激励场景训练数据里这种组合相对少。而 task_002 新颖性只有 0.31因为社区书店活动方案在语料里太常见Agent 基本在复用。成功结果不是分数高而是分数能区分任务类型。如果所有任务都落在“组合创新”说明你的 Agent 缺乏突破能力如果所有任务都“非创新”可能是语料库太宽泛把新颖性压低了。跑分表的价值在于横向对比不是单点绝对值。验证请求是否真正走通可以看日志里有没有正常返回。如果报401是 Key 问题如果报model not found是 Model ID 没写对如果报local proxy failed是 Base URL 填错或网络层配置问题。这些下一节细说。5. 本篇常见错排查从真实报错定位配置问题评估流程跑不起来九成问题出在配置三件套上。下面按真实报错逐条排查。报错一401 Unauthorized或invalid api key这是最常见的。原因通常是 Key 没填、填错、或者.env没被正确加载。排查顺序先确认代码里api_key确实读到了值打印前几位看是否为空再确认 Key 没有多余空格或换行最后确认这个 Key 在控制台是启用状态。注意Key 和 Base URL 必须配套——用 A 平台的 Key 去请求 B 平台的地址必然 401。报错二local proxy failed或连接超时这个报错通常意味着请求根本没到达服务端。检查base_url是否写成了https://taotoken.net/api有没有多写斜杠或漏写/api。另外确认运行环境没有配置额外的网络层拦截。如果是在容器里跑检查容器网络是否能正常出站。这个错误和 Key 无关纯粹是地址或网络层问题。报错三model not found或reading choices解析失败model not found是 Model ID 写错了。回到模型对话页面手动发一条消息把实际可用的模型标识抄下来。reading choices报错则更隐蔽——它通常意味着返回结构不是预期的 OpenAI 格式可能是 Base URL 指向了非兼容接口或者请求被中间层改写了。确认base_url精确指向https://taotoken.net/api不要带任何多余路径。报错四评估分数全是 0.5这不是报错但比报错更坑。全 0.5 说明 LLM 打分环节全部走了异常兜底。原因可能是评估提示词让模型返回了带解释的文字float()转换失败。解决方法是强化提示词里的“只返回数字”并且在解析时用正则先提取数字再转换。另外确认eval_temperature是 0温度太高会让模型不守格式。报错五OAuth 相关错误如果你用的是某些需要 OAuth 授权的客户端比如 Claude Code 这类可能会遇到 OAuth 流程失败。这类问题通常和 API Key 模式不同需要走专门的授权流程。接入文档里有对应说明遇到时先查文档不要盲目改代码。对于纯 API 调用场景用 Key 模式即可不涉及 OAuth。配置三件套自查清单Base URL 是否为https://taotoken.net/apiKey 是否有效且无空格Model ID 是否与可用模型完全一致。这三项任何一项不对都会导致请求失败。我建议把这三项写进一个check_config()函数启动时先自检比事后排查省事得多。排查完配置评估流程基本就能稳定跑起来。剩下的就是根据跑分结果调整任务集和阈值让评估更贴合你的实际场景。6. 语义一致 CTA把评估流程接到你的 Agent 工作流里跑通评估只是第一步真正有价值的是把它变成日常动作。我的做法是每次调整 Agent 的提示词或编排逻辑后跑一遍同一套任务集对比跑分表。如果新颖性整体下降说明改动让 Agent 更保守了如果有用性下降说明改动牺牲了落地性。这种量化反馈比“感觉好像变好了”靠谱得多。如果你要长期做这类评估模型调用量会不小尤其是评估环节每个任务要调三次 LLM。这时候可以考虑用 Coding Plan 来覆盖长期额度入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 适合需要反复跑分的场景。接入细节和参数说明在文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里都有遇到接口问题先查这里。创建和管理 Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 建议给评估流程单独建一个 Key方便统计消耗和隔离风险。想先手动验证模型输出风格可以去模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 试几条确认模型行为符合预期再写进配置。最后给一个实用技巧把跑分结果存成 CSV每次评估追加一行带上时间戳和配置版本。跑上十几轮之后你就能画出新颖性、有用性随配置变化的趋势线。这条线比任何单次评估结论都更能说明你的 Agent 到底在往“组合”还是“创新”的方向走。评估的终点不是分数是趋势。