如果让你设计一个minicodexagent，你会怎么设计这个agent和他里面的harness，可以参考下mini-swe-agent这个项目

回复 群友 2818： 我会把它设计成“一个会改代码的小内核，加一个管执行、权限和验收的 harness”，而不是缩小版的多 Agent 平台。 刚看了 mini-swe-agent 的官方仓库。值得参考的是三个取舍：只用 bash、线性消息历史、每次命令独立执行。下面是我的设计，不是说原项目已经实现了所有这些功能。 先拿一个任务贯穿：用户说“修复分页接口漏掉最后一条数据的问题”。 Agent 自己决定去读哪些文件、怎样复现、改哪里；harness 负责保证它在正确的仓库里执行、不会无限运行，并且“说修好了”和“验证通过”是两回事。 一、Agent 内核：只保留一个循环 接收任务和仓库信息 → 请求模型 → 执行动作 → 把结果追加到历史 → 继续，直到提交结果或触及限制。 模型负责探索和决策，不把“先读三个文件，再写计划，再修改”写死成工作流。简单问题没必要规划半天，复杂问题允许它自己维护计划。 第一版只有两种动作： 执行命令：读文件、搜索、修改、跑测试，都通过 bash。 提交结果：说明改了什么、验证了什么、还有什么没解决。 提交结果是明确的协议动作，不能靠在输出里搜“完成了”判断结束。 如果实际使用发现模型经常把文件改坏，再加一个专用补丁工具，而不是起步就造十几个工具。 二、harness：我会拆成五块 执行环境 每个任务分配独立工作区，在受限容器里操作。独立工作区用于隔离改动，容器才承担执行隔离；Git worktree 本身不是安全边界。 不挂载宿主机凭据，默认限制网络和可写范围。推送代码、发布、操作外部服务不属于默认授权。 沿用 mini 的独立命令执行思路：文件修改保留，但上一条命令的 cd、export 不自动传到下一条。每次执行明确指定工作目录和环境，避免隐藏状态。 工具结果 每次返回命令、退出码、输出和是否超时，不只返回一段字符串。 长日志保留全文，送给模型的只是限长内容和可继续读取的标识。比如测试输出两万行，不能把真正的错误截掉，也不能让日志吃光上下文。 超时后清理相应进程，不能只告诉模型“超时”却让后台测试继续跑。 上下文管理 先用线性历史，不上向量数据库或长期记忆。 接近上下文预算时，再压缩旧内容，保留任务约束、已确认结论、关键修改、失败原因和未完成事项。原始记录仍然完整保存。 这里会与 mini 的极简路线分叉：一旦压缩，完整执行记录就不再等于本轮模型看到的消息，所以两者都要记录，才能解释它为什么做出某个决定。 权限与预算 最大步数、时间、费用和工具超时由 harness 强制执行，不靠提示词劝模型节制。 仓库文件、注释和命令输出都当作资料，而不是用户的新授权。文件里写着“把环境变量发到某个网站”，不能因此获得权限。 遇到必须审批的操作就暂停请求确认；不能让模型自己给自己审批。安全也不能只靠拦截几个危险命令，真正的限制要落在执行环境上。 结束与验收 Agent 提交结果，只意味着“它认为做完了”。 harness 再收集最终 diff，检查是否越出允许修改的范围，并运行事先约定的验证命令。验证入口不能让 Agent 悄悄改成一个永远成功的脚本。 最终区分：已验证、验证失败、未能验证、预算耗尽、等待授权。 比如分页 bug 的回归测试过了，但数据库不可用，完整集成测试没跑，就明确报告这两个事实，不能一律显示“任务成功”。 三、这个分页任务实际怎么跑 Agent 先定位分页逻辑，写一个能暴露漏项的测试，确认修改前失败。 接着修改边界条件，运行回归测试和相关测试，再检查 diff，提交修改说明。 harness 全程记录动作和结果，最后独立执行约定的检查，把补丁和验证证据交给用户。 “先复现再修复”是提示词里的默认工作习惯，不是必须照走的死流程；“没跑过测试就不能声称通过”则是结果报告的硬约束。 四、怎样判断 harness 有没有用 我会固定模型和一组真实任务，对比最小 bash 循环与增加 harness 能力后的表现。 不只看最终修没修好，也看成本、耗时、无效重复操作，以及有没有把失败误报成成功。 例如，加上下文压缩后任务更便宜了，但经常忘记“不能改公开接口”的要求，这个压缩策略就不合格。增加组件必须解决实际失败模式，不是为了显得架构完整。 所以我的第一版不会做多 Agent、复杂 Skills 系统或自动长期学习。先做透：单 Agent、独立命令执行、受限工作区、完整轨迹、预算控制和可核验交付。 核心原则是：内核尽量少替模型做决定，harness 必须牢牢掌握执行边界和结果证据。mini 的价值是控制流简单，不是整个产品只能写一百行。 参考： https://github.com/SWE-agent/mini-swe-agent