一条面向开源开发者的内测招募，意外变成了 Agent 生态的集中展示。8 月 1 日，DeepSeek Harness 团队负责人崔添翼在 X 上邀请 Agent Harness 相关开源项目开发者参加内测，并要求附上 GitHub ID 与代表作。大量项目借此进入同一个讨论现场，也把一个容易被忽略的问题推到台前：当模型能力逐渐接近时，真正决定 Agent 能否投入生产的，往往是模型外面的那套 Harness。
Harness 不只是“再包一层 API”
在 Agent 系统里，模型通常只负责生成下一步意图。把意图变成可靠执行，还需要一组工程组件：提示词组装、工具注册、参数校验、循环调度、状态持久化、权限控制、失败重试、日志追踪和结果评估。这些组件合起来，可以被理解为 Agent Harness。
一个最小执行循环大致包含以下步骤：
- Harness 把用户目标、历史状态和可用工具交给模型。
- 模型选择工具并生成参数，或者直接给出最终答案。
- Harness 校验调用是否合法，再执行工具。
- 工具结果被写回上下文，进入下一轮推理。
- 达到完成条件、预算上限或安全边界后停止。
因此，比较不同 Harness 时，只看演示里“能不能完成任务”并不够。工作开发者更应该检查几个具体问题：工具参数是否采用结构化 Schema，执行过程能否恢复，模型是否可以替换，每一步是否留有可检索的轨迹，以及失控循环会不会被硬性终止。
为什么一次招募会变成生态路演
招募要求提交 GitHub ID 和开源代表作，这实际上形成了一个天然的项目筛选与展示机制。参与者不只是在申请测试资格，也在公开回答三个问题：项目解决什么任务、采用什么运行时抽象、代码是否经得起外部检查。
从来源摘要可以确认的是，这次邀请面向 Agent Harness 相关开源项目，并引发了大规模项目展示。至于 DeepSeek Harness 的正式接口、支持的工具协议、评测标准和发布时间，摘要没有给出完整信息，不宜提前推断。
不过，这场集中亮相仍然释放出几个值得观察的方向：
- 模型与运行时正在解耦。 团队会希望用同一套任务和工具测试不同模型，而不是为每个模型重写业务流程。
- 开源代表作成为能力证明。 README、提交历史、测试和真实案例，比概念描述更容易建立可信度。
- Harness 的竞争转向工程质量。 多轮任务是否可恢复、工具是否隔离、成本是否可控，会直接影响生产可用性。
- 统一评测变得更重要。 没有固定任务集、预算和成功条件，Agent 演示之间很难进行有效比较。
可以这样实践：先做一个可替换的最小 Harness
下面是一个不依赖第三方库的教学示例。它不是 DeepSeek Harness 的官方接口，而是一个可以直接运行、再替换模型适配器的最小项目。示例用确定性的本地 Agent 模拟模型决策，重点展示工具注册、参数校验、步数限制和执行轨迹。
将以下内容保存为 mini_harness.py：
from dataclasses import dataclass, field
from typing import Any, Callable
@dataclass
class Tool:
name: str
description: str
handler: Callable[..., Any]
required: tuple[str, ...] = ()
def run(self, arguments: dict[str, Any]) -> Any:
missing = [key for key in self.required if key not in arguments]
if missing:
raise ValueError(f"missing arguments: {', '.join(missing)}")
return self.handler(**arguments)
@dataclass
class Harness:
tools: dict[str, Tool]
max_steps: int = 4
trace: list[dict[str, Any]] = field(default_factory=list)
def run(self, agent: Callable[[str, list[dict[str, Any]]], dict], task: str) -> str:
for step in range(1, self.max_steps + 1):
action = agent(task, self.trace)
self.trace.append({"step": step, "action": action})
if action["type"] == "finish":
return action["answer"]
if action["type"] != "tool":
raise ValueError(f"unsupported action: {action['type']}")
tool_name = action["name"]
if tool_name not in self.tools:
raise PermissionError(f"tool is not allowed: {tool_name}")
try:
result = self.tools[tool_name].run(action.get("arguments", {}))
except Exception as exc:
result = {"error": str(exc)}
self.trace.append({"step": step, "tool": tool_name, "result": result})
raise RuntimeError("agent exceeded the step budget")
def add(a: float, b: float) -> float:
return a + b
def demo_agent(task: str, trace: list[dict[str, Any]]) -> dict:
# 实际项目可在这里接入任意支持结构化输出的模型 API。
if not trace:
return {
"type": "tool",
"name": "add",
"arguments": {"a": 19, "b": 23},
}
result = trace[-1]["result"]
return {"type": "finish", "answer": f"计算结果是 {result}"}
if __name__ == "__main__":
harness = Harness(
tools={
"add": Tool(
name="add",
description="计算两个数字之和",
handler=add,
required=("a", "b"),
)
}
)
answer = harness.run(demo_agent, "计算 19 + 23")
print(answer)
print("执行轨迹：")
for event in harness.trace:
print(event)
直接运行：
python mini_harness.py
预期结果包含 计算结果是 42，随后输出每一步 action 和工具结果。接入真实模型时，可以替换 demo_agent，但应保留 Harness 对工具白名单、必填参数和最大步数的控制。不要让模型生成的工具名直接进入 subprocess、数据库或文件系统。
参加内测或评估项目时该准备什么
如果准备提交一个开源 Agent 项目，仓库至少应让评审者快速复现核心流程。一个可操作的检查清单包括：
- 用一条命令启动最小示例，并锁定依赖版本。
- 明确列出支持的模型、工具协议和状态存储方式。
- 提供成功、超时、工具报错和模型输出非法参数的测试。
- 记录 token、耗时、工具调用次数与最终状态。
- 给文件、网络、Shell 和凭据访问设置默认拒绝策略。
- 使用固定任务集重复运行，报告成功率和成本，而不是只展示最佳案例。
DeepSeek Harness 的具体能力仍应以正式披露和实际内测结果为准。但这次招募已经说明，Agent 生态的关注点正在从单次回答质量扩展到完整执行系统。对开发团队而言，现在更值得投入的不是再做一个只能演示的聊天界面，而是建立可替换、可观察、可评测并且能够限制风险的运行框架。