Coding Agent
工程实践手册
基于 Kimi 近期 Agent Harness 研发岗位的 JD，结合我自己的工程开发经验， 整理成这份 Coding Agent 系统实践指南。
选择章节01 goal.receive()
02 context.retrieve(repo)
03 model.decide(state)
04 policy.authorize(action)
05 tool.execute(action)
06 event.append(result)
07 verifier.check(diff)
08 eval.compare(baseline)
✓ recoverable
✓ observable
✓ measurable从一份 Kimi Code 招聘 JD 展开的系统工程笔记
最近看到 Kimi Code 的一份 Agent Harness 研发 JD。它没有把岗位描述停留在“会调用模型”上，而是很直接地写出了 Coding Agent 真正难的部分：执行循环、工具系统、仓库级上下文、长任务恢复、真实 trace 与评测闭环。
这些问题恰好也是我在工程开发中持续关注的主题。于是我沿着这份 JD 把问题逐层展开，整理成这份公开笔记。它不是岗位题库，也不试图复述某个产品；我更想得到一套可以拿来设计、实现和审查 Coding Agent 的问题框架。
文中涉及 Kimi Code 的部分只依据公开仓库和文档。实现会持续变化，因此我更关注背后的工程约束，而不是某个版本的类名或参数。
这份笔记怎么读#
可以先建立一条主线：模型负责在不确定信息里做决策，Runtime 负责把决策约束为可执行、可恢复、可审计的行为，Evaluation 则负责证明系统是否真的变好。
阅读具体方案时，我习惯追问五件事：
- 状态放在哪里，崩溃后能否恢复？
- 副作用边界在哪里，未知结果会不会被重复执行？
- 上下文为什么是这些，而不是更多或更少？
- 失败最早从哪一步开始，怎样用最小实验归因？
- 改进用什么任务、指标和对照组证明？
像“加缓存、重试、RAG 或 Multi-agent”这样的答案通常不够。更关键的是缓存键与失效条件、错误分类和重试语义、检索污染、Agent 之间隔离的状态，以及成功率提升是否值得新增的成本和复杂度。
不必一次读完
每一章都是可以独立阅读的工程主题。建议从 Runtime 建立主线，再按工具、上下文、 长任务和评测逐步深入；产品判断与主流 Agent 对比章节也可以单独阅读。
Agent Runtime：把模型决策变成可靠执行
状态机、事务边界、终止条件、Planning，以及必须由 Runtime 守住的不变量。
工具系统与仓库级上下文
工具契约、副作用、文件与 Shell，以及如何在真实仓库里选择高价值上下文。
安全边界、长任务与恢复
权限、沙箱、事件日志、crash recovery、用户打断和长任务资源治理。
Subagent 调度与 Model Gateway
什么时候并行才有价值，以及如何隔离上下文、权限、成本和 provider 差异。
Evaluation、Observability 与 Trace
从真实失败构造评测，设计 grader，并用 trace 找到第一次关键偏离。
系统设计与故障分析
终端 Agent、monorepo、远程沙箱和评测平台的设计，以及典型事故推演。
产品判断与自研 Harness
已有成熟 Coding Agent 时，模型公司为什么仍然值得维护自己的 Harness。
主流 Coding Agent 的路线与取舍
比较 Codex、Claude Code、Kimi Code、DeepSeek TUI 与 TRAE 的产品边界、优势和代价。
工程问题与实现检查
用于实现和设计审查的高密度索引，以及一个最小 Coding Agent 练习。
推荐阅读与结语
继续研究 Coding Agent 系统工程时值得回到的官方资料、论文和项目。
模型公司为什么仍然需要自己的 Harness？
能通过兼容接口调用模型，不等于模型能力被稳定兑现。真正需要证明的是： 自有 Runtime、上下文、评测和数据闭环能否在固定模型下产生可测量的增益。