开篇：AI Agent 挑战赛的兴起
2025-2026 年，AI Agent 挑战赛像雨后春笋一样冒出来。
从 $2M 级别的企业挑战赛，到 Herald/Hermes 这样的开源 Agent 框架赛事，开发者们在这些比赛中展示了各种创意——从自动代码审查、智能运维助手，到完全自主的电商客服。
Hermes Agent Challenge 是其中比较有代表性的一个。它不是一个"谁做出最强模型"的比赛，而是"谁用已有的模型和工具，做出最有效的 Agent 系统"的比赛。
这个定位很有意思。它考验的不是"你能不能用更好的模型"，而是"你能不能用现有的东西，搭出最好的系统"。
这篇文章不是官方报道——是参与者的观察和思考。
一、Hermes Agent Challenge 的设计
挑战赛的核心规则：
- 使用 Hermes 框架（一个开源 Agent 框架）搭建 AI Agent
- Agent 需要自主完成一系列任务：信息检索、工具调用、多步骤推理
- 评判标准：不是"结果好不好"，而是"Agent 的决策过程是否合理，方法是否可复现"
1.1 任务示例
挑战赛中的典型任务类型：
任务类别：
1. 信息检索型：从给定的文档集合中找到特定信息，总结后输出
2. 工具调用型：调用多个 API 完成一个工作流
3. 多步骤推理型：根据不完全信息做推理，逐步求证
4. 错误恢复型：在工具调用失败时，Agent 能否自动恢复并继续
这些任务设计的共同点：需要 Agent 展示"决策能力"而不仅仅是"回答能力"。
1.2 评判标准
挑战赛的评分不是"通过/不通过"的二元判定，而是多维度的评分：
@dataclass
class AgentEvaluationResult:
"""
Agent 的评估结果（Hermes Challenge 评分模型）
"""
# 任务完成度 (40%)
task_completion: float # 0-1: 任务完成的比例
# 决策质量 (25%)
decision_quality: float # 0-1: 每一步决策是否合理
tool_selection_accuracy: float # 0-1: 是否使用了正确的工具
# 错误处理 (20%)
error_recovery: float # 0-1: 出错时的处理能力
graceful_degradation: float # 0-1: 无法完成任务时的降级处理
# 可解释性 (15%)
reasoning_quality: float # 0-1: 推理过程是否清晰
auditability: float # 0-1: 决策过程是否可以追溯
@property
def total_score(self) -> float:
return (
self.task_completion * 0.4 +
self.decision_quality * 0.25 +
self.error_recovery * 0.20 +
self.reasoning_quality * 0.15
) * 100
def evaluate_submission(agent_logs: str, expected_results: Dict) -> AgentEvaluationResult:
"""评估 Agent 的一次任务执行"""
# 从日志中提取关键事件
events = parse_agent_events(agent_logs)
# 1. 任务完成度：Agent 是否完成了所有步骤
completed_steps = [e for e in events if e["type"] == "task_completed"]
total_steps = len(expected_results["steps"])
task_completion = len(completed_steps) / max(total_steps, 1)
# 2. 决策质量：工具选择是否正确
tool_calls = [e for e in events if e["type"] == "tool_call"]
correct_tool_calls = sum(
1 for tc in tool_calls
if tc["tool_name"] == expected_results["expected_tool"][tc.get("step", 0)]
)
tool_accuracy = correct_tool_calls / max(len(tool_calls), 1)
# 3. 错误恢复：当工具调用失败时，Agent 怎么处理
failures = [e for e in events if e["type"] == "tool_failure"]
recoveries = [e for e in events if e["type"] == "error_recovery"]
error_recovery = min(len(recoveries) / max(len(failures), 1), 1.0)
# 4. 推理质量：Agent 的思考过程是否清晰
reasoning_steps = [e for e in events if e["type"] == "reasoning"]
reasoning_quality = min(len(reasoning_steps) / 5, 1.0) # 期望至少 5 步推理
return AgentEvaluationResult(
task_completion=task_completion,
decision_quality=tool_accuracy,
tool_selection_accuracy=tool_accuracy,
error_recovery=error_recovery,
graceful_degradation=error_recovery,
reasoning_quality=reasoning_quality,
auditability=reasoning_quality,
)
二、从参赛作品中学到的
2.1 高分作品的特征
对比分析公开的参赛作品，高分作品有几个共同特征：
特征 1：误差处理和正常流程一样被重视
这不是猜测——从公开的裁判反馈来看，那些在"意外情况"（API 超时、工具返回空值、中间步骤失败）面前表现从容的 Agent，分数明显更高。
一个常见的模式：
class ErrorAwareAgent:
"""
高分 Agent 的特征：知道怎么处理异常
低分 Agent 的特征：假设一切顺利
"""
def execute_task(self, task: Dict) -> Dict:
"""
执行任务（带全流程错误处理）
"""
try:
# 步骤 1: 检索信息
info = self.retrieve_information(task["query"])
except Exception as e:
# 代替直接报错：尝试替代方案
print(f"[Agent] 主检索失败: {e}，尝试备选方案")
info = self.fallback_retrieve(task["query"])
if not info:
return {
"status": "partial",
"error": f"无法检索到相关信息: {e}",
"completed_steps": [],
"suggestion": "请检查文档库是否包含所需信息",
}
# 步骤 2: 调用工具
tool_results = []
for tool_call in task["tools"]:
try:
result = self.call_tool(tool_call)
tool_results.append(result)
except TimeoutError:
print(f"[Agent] 工具超时: {tool_call['name']}，重试一次")
# 重试一次
try:
result = self.call_tool(tool_call, timeout=30)
tool_results.append(result)
except:
print(f"[Agent] 工具 {tool_call['name']} 不可用，跳过")
continue
# 如果有部分失败，仍返回已完成的步骤
if len(tool_results) < len(task["tools"]):
return {
"status": "partial",
"completed_steps": tool_results,
"failed_steps": len(task["tools"]) - len(tool_results),
"note": "部分工具调用失败，已跳过不可用的服务",
}
return {"status": "completed", "result": self.aggregate(tool_results)}
特征 2：不以"正确答案"为目的，以"正确过程"为目的
高分 Agent 不急着猜答案。它们会先确认自己理解了问题，然后逐步求证。
低分 Agent 的典型行为：
- 看到问题就猜答案，猜对了拿分，猜错了没分
- 没有中间推理步骤，裁判看不到决策过程
高分 Agent 的典型行为：
- 先复述问题，确认理解
- 逐步推理，每一步都有日志
- 不确定的时候，解释不清楚的地方
特征 3：工具调用不是为了调用而调用
低分 Agent 经常犯的错误：不管需不需要，先把所有工具都调一遍。
高分 Agent 的做法：
- 先判断需要哪些工具
- 只调必要的工具
- 工具结果出来后，检查是否需要再调其他工具
三、从参赛中学到的几个关键工程实践
3.1 System Prompt 设计的艺术
参赛作品中，system prompt 的设计区别很大。好的 system prompt 不是"告诉 Agent 做什么"，而是"告诉 Agent 怎么思考"。
# 低分 prompt 的特征：
SYSTEM_PROMPT_LOW = """
你是一个 AI Agent。你的任务是完成用户分配的任务。
请调用合适的工具来完成任务。
"""
# 高分 prompt 的特征：
SYSTEM_PROMPT_HIGH = """
你是一个 AI Agent。你的工作方式是：
## 工作原则
1. 先理解，再行动：每次任务开始前，复述你的理解
2. 逐步推进：一次只做一件事，不要同时调用多个工具
3. 确认结果：每个工具调用后，检查结果是否合理
4. 诚实面对失败：如果某个工具调用失败，说明原因和替代方案
## 决策流程
当你需要做决策时，请展示你的思考过程：
- 我当前的任务目标是什么？
- 为了实现这个目标，有哪些可选的路径？
- 我选择这个路径的理由是什么？
- 执行结果是什么？我需要调整方向吗？
## 错误处理
- 如果工具调用超时或报错：重试一次，换用不同的参数
- 如果重试也失败：跳过这个工具，继续其他步骤
- 如果无法完成整个任务：返回已完成的部分，说明未完成的原因
"""
好的 system prompt 本质上是给 Agent 装了一个"决策框架"。低分 Agent 依赖模型自身的推理能力，高分 Agent 通过 prompt 给模型提供了推理路径。
3.2 日志系统的质量决定了调试效率
参赛作品一个让人意外的发现：高质量的日志记录比复杂的 Agent 架构更常见于高分作品。
class AgentLogger:
"""
高分 Agent 的日志系统
"""
def __init__(self):
self.events = []
def log_decision(self,
step: str,
observation: str,
options: list,
chosen: str,
reason: str):
"""记录一个决策过程"""
self.events.append({
"type": "decision",
"step": step,
"observation": observation,
"options_considered": options,
"chosen_option": chosen,
"reasoning": reason,
})
def log_tool_call(self,
tool: str,
params: dict,
result: str,
duration_ms: float):
"""记录一次工具调用"""
self.events.append({
"type": "tool_call",
"tool": tool,
"params_summary": str(params)[:200],
"result_summary": str(result)[:200],
"duration_ms": duration_ms,
})
def generate_report(self) -> str:
"""生成可读的决策报告"""
report = ["=== Agent 决策报告 ===\n"]
for event in self.events:
if event["type"] == "decision":
report.append(f"🤔 [决策] {event['step']}")
report.append(f" 观察: {event['observation'][:100]}")
report.append(f" 选择: {event['chosen_option']}")
report.append(f" 原因: {event['reasoning'][:200]}")
elif event["type"] == "tool_call":
report.append(f"🛠️ [工具] {event['tool']}")
report.append(f" 耗时: {event['duration_ms']:.0f}ms")
report.append(f" 结果: {event['result_summary']}")
report.append("")
return "\n".join(report)
为什么日志质量不重要？
因为在 Hermes Challenge 这样的比赛中，人工评审不仅要看结果，还要看过程。如果你的 Agent 日志记录了一团乱七八糟的推理和毫无章法的工具调用，即使最终结果对了，也很难拿高分。
四、一个具体的获奖案例
4.1 案例：多层信息检索 Agent
有一个获奖作品特别有意思——它解决的是"从混乱的信息源中找到正确答案"的问题。
这个任务的难度在于：
- 信息分布在不相关的文档中
- 有些文档包含误导性信息
- Agent 需要自己判断哪些信息可靠
获奖方案的思路：
class MultiLayerRetrievalAgent:
"""
多层信息检索 Agent（获奖作品的核心思路）
架构：
1. 第一层：广泛搜索，获取候选信息
2. 第二层：交叉验证，比对不同来源
3. 第三层：综合判断，生成答案
关键：每一层都在产生"推理痕迹"，而不是简单的结果
"""
def research(self, query: str) -> Dict:
"""三层检索"""
# 第一层：广泛搜索
print(f"[Layer 1] 搜索: {query}")
candidates = self.broad_search(query)
# 第二层：交叉验证
print(f"[Layer 2] 验证: 找到 {len(candidates)} 个可能来源")
verified = []
for candidate in candidates:
# 检查来源可信度
credibility = self.check_credibility(candidate)
# 检查信息一致性（多个来源是否一致）
consistency = self.check_consistency(candidate, candidates)
verified.append({
"source": candidate["source"],
"content": candidate["content"],
"credibility_score": credibility,
"consistency_score": consistency,
"overall": (credibility + consistency) / 2,
})
# 第三层：综合判断
print(f"[Layer 3] 综合: 从 {len(verified)} 个验证结果中生成答案")
reliable = [v for v in verified if v["overall"] > 0.7]
if len(reliable) >= 2:
# 多个可靠来源，可以给出高置信度答案
answer = self.synthesize(reliable)
confidence = "high"
elif len(reliable) == 1:
# 只有一个可靠来源，标注低置信度
answer = reliable[0]["content"]
confidence = "medium"
else:
# 没有可靠来源
answer = "无法从可靠来源获取信息"
confidence = "low"
return {
"answer": answer,
"confidence": confidence,
"sources_used": [v["source"] for v in reliable],
"reasoning_steps": len(self.decision_log),
}
这个方案的亮点不是"技术复杂"，而是思路清晰。评审能清楚地看到 Agent 的每一步决策、为什么选择这个来源、为什么排除那个来源。即使最终结果错了，评审也能看到 Agent 的推理是合理的。
五、我的观点：挑战赛的价值不在结果
写这篇文章时，我想分享一个和比赛结果无关的观察。
我看了很多参赛作品，印象最深刻的不是第一名——而是那些知道自己的 Agent 什么时候不行的参赛者。
有一个作品让我印象深刻。在某个任务中，它的 Agent 在第三个步骤遇到了一个从未见过的错误类型。Agent 没有继续尝试，而是停下来说：
"我遇到了一个未知错误，类型是 X。这个情况不在我的训练数据中。我建议以下替代方案..."
然后给出了 3 条具体的建议，每一条都比让它继续执行更好。
这种能力比"完成所有任务"更让我认可。 因为它展示了对 Agent 边界的真实理解——知道 Agent 什么能做、什么不能做，比让 Agent 什么都试着做更重要。
5.1 从挑战赛到生产环境
很多参赛者赛后分享了他们的教训。我整理了最常见的几个，供参考：
教训 1："更复杂的模型 ≠ 更好的 Agent"
一位二等奖获得者分享说："我们的初版用了当时最贵的旗舰模型，效果反而没有最终版本好。最终版本用的模型参数量少了 10 倍，但因为我们把大部分逻辑都写在了 prompt 和工具调用验证里，Agent 的表现更稳定。"
教训 2："工具调用的容错性比什么都重要"
Hermes Challenge 中有一个专门的"压力测试"任务——在 Agent 运行过程中随机让工具调用失败。很多初期表现优秀的 Agent 在这个任务中翻了车。
一位参赛者在复盘中说："我们的 Agent 在前 3 个任务都拿到了近乎满分，第 4 个任务（压力测试）只拿了 40 分。因为我们假设所有工具调用都会成功——这个假设在压力测试中被完全打破了。"
教训 3："不要为了展示而展示"
有的参赛作品在 Agent 的响应中加入了大量花哨的格式——Markdown 表格、表情符号、彩色日志。但评审更关心的是：Agent 在每一步做了什么决策，而不是它怎么展示结果。
5.2 如果你也想参加下一届
基于这次观察，我给想参加下一届的人的建议：
- 先搞好 error handling，再搞功能——error handling 占了评审分数的 20%，但很多参赛者最后一天才想起加
- 日志日志日志——评审看不到 Agent 在想什么，只能通过日志推测。日志质量决定了评审对你的 Agent 的理解程度
- 一个干净的 system prompt 比十次调试更有价值——花时间打磨 prompt，让它清晰地定义 Agent 的决策框架
- 测试你的 Agent 在"工具挂了"时的表现——这是高分和低分的分水岭
结尾
Hermes Agent Challenge 这样的比赛，真正的价值不在于"选出最好的 Agent"，而在于让参与者（和围观者）看到：好的 Agent 不是靠模型堆出来的，是靠工程设计堆出来的。
一个简单的模型 + 精心设计的 system prompt + 清晰的决策流程 + 完整的错误处理 + 高质量的日志，远胜过一个强大的模型 + 随意的架构。
如果你错过了这次挑战赛，下一届可以试试。不用赢，参与本身就是最好的学习方式。
文章由文字工作者编写。Hermes Challenge 的描述基于公开信息和参与者反馈。评分标准和获奖作品的分析来自个人观察。