介绍下最近在做的个人项目 Jeju，一个声明式的 Agent harness。
核心思路很简单：通过配置创建 Agent，完成特定任务。同时带了一些开箱即用的能力：执行轨迹可视化、评估轨迹效果、自进化机制。
名字的由来没什么深意。前阵子去济州岛徒步，非常喜欢偶来小径，于是用 Jeju 命名这个项目，算是给一段愉快的徒步经历留个纪念。
起因
我是 Codex 的重度用户。去年主要用它写代码，今年它慢慢演化成了个人助手，承担各种日常任务和工作流：写代码、看邮件、写博客、创建每周规划、文章校审润色，杂七杂八都交给它。如果你也经常在 Codex 里切换模型、手动管理 subagent，Jeju 就是为这个痛点设计的：让你用声明式配置创建 Agent，不用每次都从头拼 prompt 和工具链。
GPT 5.5 在写代码、执行任务、推理场景很强，但写文章不太行，这方面我更喜欢量大管饱的 Deepseek V4，随便用，根本不心疼。于是我需要一个能在 Codex 里方便创建 subagent、切换模型的脚手架。
另外，我一直在研究几个有名气的开源 Agent：pi、opencode、codex，想着从零实现一个比较完整的 Agent，走一遍完整流程，看看和自己预想的设计有多大差别。
再加上 Agent 自进化是上半年比较热门的研究方向，我也很感兴趣，想亲自动手实现一遍。
综合以上所有诉求，Jeju 诞生了。
设计理念
Jeju 的设计围绕几个实际需求展开。
Manifest 定义 Agent 能力
一个能完成任务的 Agent 通常包括这几部分：大模型做推理规划，携带工具和经验技能，任务运行较长时需要上下文管理和压缩策略，任务完成后可配置触发评估。
基于这些组件，我参考 Kubernetes 的 manifest 规范设计了一套声明式配置。一个典型的例子如下：
apiVersion: jeju/v1alpha1
kind: Agent
metadata:
name: repo-inspector
description: "Inspect a local repository and produce a structured summary"
models:
providers:
primary:
type: openaiCompatible
preset: deepseek
model: deepseek-v4-flash
envKey: DEEPSEEK_API_KEY
instructions:
system: ../prompts/repo-inspector.md
runtime:
model: primary
loop:
type: react
limits:
maxSteps: 12
maxDurationSec: 300
workspace:
path: ../workspace/repo-inspector
tools:
- read
- search
permissions:
access: readOnly
approval: never
output:
name: repo_summary
schema:
type: object
required: [summary, findings]
additionalProperties: false
properties:
summary: { type: string }
findings:
type: array
items: { type: string }
evaluate:
enabled: true
evaluators:
- name: basic
uses: rules
rules: [finalAnswerExists, runCompleted]当 Agent 的行为通过配置定义后，会带来几个好处。
第一，方便做消融实验。同一个任务，可以对比不同模型的效果；同一个模型，可以对比不同工具的表现。通过对比，你能快速了解模型差异和工具影响。
第二，保障 Agent 稳定的表现能力。面对同样的任务，除了模型本身的性能波动，其他配置都是不变的，最终任务更容易达到预期效果。
第三，持续优化 Agent。Agent 执行不好时，我会让 Codex 结合执行轨迹分析并优化 Agent 配置，提升任务表现。
执行轨迹可视化
为了有效分析 Agent 执行效果，需要一套轨迹协议记录执行过程，同时需要一个可视化页面方便人来阅读。
轨迹协议采用 JSONL 格式存储每一次动作，一次完整的执行只生成一个 trajectory.jsonl。Agent 跑完任务后，触发可视化工具解析该文件，生成一个 HTML 网页。在浏览器中打开就能直观地看到这次执行的全貌，包括 Agent 元信息和任务执行的每一步情况。
一个小故事。可视化页面最开始用 GPT 5.5 设计，功能没问题，但总觉得缺一点精致。后来换成 Opus 4.8，寥寥几句话，既能指出 GPT 的设计问题，还能重构成更精致的页面。从此我无条件信任 Claude 的审美。这件事也让我更确信：工具链里多放几个模型，各取所长，体验会好很多。
Agent 自进化机制
有了可读的执行轨迹之后，一个很自然的问题就是：能不能根据轨迹改进 Agent？当任务跑得不好时，轨迹能帮我们定位是哪个环节出了问题：工具调用不对、上下文太长导致信息丢失，还是 system prompt 本身有歧义。这种失败归因能力，恰好是 Agent 自进化的前提：只有知道哪里坏了，才能有针对性地去修。推荐详细阅读这两篇文章进一步了解：Agent 自进化到底在进化什么 和 把自进化闭环做好：从 Bad Case 到 Harness Patch。
Jeju 参考文章里的思想实现了一个离线进化流程。核心思路很朴素：不直接改写原始 Agent，而是在受限的配置空间里生成候选 harness patch，再用 benchmark 结果做选择。配置里可以明确声明哪些部分允许修改，比如只允许改 system prompt；也可以设置 guard，禁止把题目、答案或者特定样本硬编码进 prompt。
为了验证这套机制是否真的有效，我基于 HotpotQA 的 dev distractor 子集构建了一个简易 benchmark，任务是多跳问答。每个样本给出问题和约 10 段上下文，其中只有 2 段真正相关，其余都是干扰段。评估使用 HotpotQA 官方的 answer EM/F1 规则，是纯程序化 evaluator，不依赖 LLM judge。
实验的 train/selection/test 划分是 100/50/100。solver 和 evolver 都使用 DeepSeek V4 Flash，只进化 solver 的 system prompt。train split 给 evolver 反馈，selection split 选择候选，100 题 test split 只在最后对 baseline 和 best candidate 做一次验收。结果是 Pareto 策略在 held-out test 上相比原始 prompt 提升了 +3.6pp answer F1 和 +7pp exact match；同样预算下，greedy hillclimb 只有 +1.7pp F1 和 +4pp EM。
需要说明的是，这只是一次单任务、单模型的早期验证，远不足以证明自进化机制在通用场景下的有效性。不同任务、不同模型、不同进化策略组合下的表现还需要更多实验来观察。但至少在这个受限设定里，方向是走得通的。
Agent-friendly 设计
我觉得 2026 年的新项目不能只满足给人看，也要给 Agent 看。
我在本项目中主要做了两点优化：一是增加了给 Agent 的使用指南，你无需理解 Jeju 的各种参数，只需要把项目地址扔给你的 Agent，问它问题；二是增加了 Jeju Agent Builder skill，在 Agent 中调用该 skill 创建和调用 Jeju Agent，非常方便。
举个我的实际应用场景。我喜欢用 Deepseek V4 校审和润色文章，在 Codex 中调用 Jeju Agent Builder 创建两个 Jeju Agent，分别负责校审和润色。每次写完一篇文章，我就告诉 Codex 先调用校审 Agent 阅读文章给出修改建议，我读完之后挑选需要改的地方，再调用润色 Agent 优化文章。
现状与方向
Jeju 目前具备完整的 Agent Loop、自动评估、轨迹可视化、Agent Team（lead-worker 模式）和自进化框架，也支持 Agent 分发管理。但核心问题是：怎么让 Agent 从“自己能跑”变成“别人也能方便地用”？
接下来想探索两个方向。一个是本地的 Agent Store GUI App，让管理和使用 Agent 更直观，降低上手门槛。另一个是支持云端运行长程任务，让 Agent 不再受限于本地机器的在线时间。两个方向都在解决同一个问题：降低 Agent 的使用和运行门槛。
结尾
Jeju 从一开始就是我的 Agent 试验田。Manifest 配置来自切换模型做消融实验的真实需求，轨迹可视化来自调试 Agent 时反复翻日志的痛点，自进化来自对“能不能让 Agent 自己改进自己”的好奇，Agent Builder skill 来自日常写作流程中不想手动配置的懒惰。每个设计决策背后都有一个具体的问题在推动。
做着做着发现挺有用的，值得分享给更多人体验。如果你也在做类似的事情，希望这些思路对你有用。