为什么很多Agent Demo看起来很强，一旦连续执行十几分钟，就开始失忆、乱调工具、重复执行，甚至自己宣布任务完成。

问题往往不是模型。

而是Harness底层缺了三样东西：

State。

Permission。

Verifier。

文章从一个最小Agent Runtime开始，把这三层拆开。

首先是State。

Agent不能只靠聊天历史记住自己干了什么。

真正的工程任务至少需要独立保存：

Goal。

Plan。

Completed Steps。

Observations。

Unresolved Errors。

Checkpoint。

即使DeepSeek V4已经支持超长Context，Context也不能代替任务状态。

因为：

Context是模型本轮需要看到的信息。

State是系统已经确认发生的事实。

Memory是跨任务值得长期保存的知识。

Checkpoint则是任务中断以后继续执行所需要的最小状态。

第二层是Permission。

Coding Agent最简单的Demo通常是直接给模型一个Shell。

但真正进入生产环境以后，read_file、write_file、run_test、database_query和deploy绝对不应该拥有相同权限。

因此Harness需要Tool Policy。

例如读取文件可以自动执行。

运行测试可以限制在Sandbox中。

写文件限制可写目录。

生产部署则必须进入人工审批。

第三层是Verifier。

这是Agent系统里非常容易被忽略的一层。

如果Planner由模型完成。

Executor也由模型驱动。

最后仍然由同一个模型判断“我已经完成了”。

那么整个系统实际上没有真正的验收边界。

代码任务应该运行测试。

数据任务应该做Schema Validation。

页面任务应该检查HTTP状态和DOM。

工作流则应该检查所有必需节点是否真正完成。

确定性规则先验收。

规则无法覆盖的部分，再交给模型Grader。

完整循环最终会变成：

Plan
  ↓
Execute
  ↓
Observe
  ↓
Verify
  ├── PASS → DONE
  └── FAIL
        ↓
      Update State
        ↓
      Re-plan

文章还进一步加入了：

• Agent State状态机

• Tool Registry

• Tool Policy

• Checkpoint

• DeepSeek V4 Pro / Flash内部模型路由

• Agent Loop

• Verifier设计

• 1M Context下的状态与上下文分层

• Multi-Model Harness

• AI漫剧多模型工作流案例

• Agent生产化的5步上线顺序

同时设计了7类工程错误码：

STATE-101｜NO_PERSISTENT_STATE

CTX-202｜CONTEXT_AS_DATABASE

TOOL-303｜UNLIMITED_SHELL

VERIFY-404｜MODEL_SELF_VERIFY

LOOP-505｜NO_BUDGET

ROUTE-606｜ONE_MODEL_FOR_ALL

PLUGIN-707｜PLUGIN_BEFORE_RUNTIME

文章最后落到一个核心判断：

模型决定Agent的智力上限。

Harness决定这个上限能不能稳定变成生产力。

等Agent真正进入生产环境以后，竞争不会只是谁的模型Benchmark更高。

而是谁的State更可靠。

谁的权限更清晰。

谁的Verifier更严格。

谁的Checkpoint更稳定。

谁能让任务失败以后继续，而不是重新来一遍。

这才是Harness Engineering真正值得研究的部分。