注册并分享邀请链接,可获得视频播放与邀请奖励。

Yifan Xu 的个人资料封面
Yifan Xu 的头像

Yifan Xu (@yifanxu_ephai)

@yifanxu_ephai
0 正在关注    0 粉丝
按照业内大佬的分享,模型是针对特定 harness 训练的,按理说应该和自家 harness 最合拍。但却恰恰相反。 图一:Kimi K3 在 Alma 上表现最好,反倒和自家 harness 相性不合。 图二:GLM 5.3 在 Kimi Code 上通过率最高,自家 Z Code 却排在最后。
显示更多
0
16
40
1
转发到社区
这两天尝试了一下 Codex 的 MCP Events,发现和我想象中的功能非常不一样。 最早看到这个更新时,我以为 Codex harness 终于开放了一个 notification sink:MCP 任务可以在后台执行,工具调用先返回任务 ID;等任务完成,再把 completion event 推回 harness,唤醒 Agent 继续工作。如果能打通,可定制性会非常高, 可以将MCP tool定制成 原生工具的使用体验。 我期待的是这样一条链路: 调用 MCP tool → 后台执行 → 完成事件推回 harness → Agent 接着处理结果。 于是我vibe了个本地exec_command + write_stidn MCP, 才发现这个event push notification只有ChatGPT Work 的云端场景才支持。 希望官方能早日支持本地的MCP Event功能
显示更多
Harness Engineering发展史
回顾一下 harness engineering 发展的历史,至今似乎还没有一个边界清晰的解释,能说清楚它到底是什么。 先是二月份,OpenAI 发布了 Harness Engineering 的 blog,介绍他们如何从一个 empty repo 出发,搭建可靠的文档、知识库、测试体系和日志环境,供 agent 开展开发工作。 几乎同一时间,LangChain 通过修改提示词、工具和 middleware,将 Deep Agents 在 benchmark 上的成绩提升了 25%,随后提出了 Agent = Model + Harness 的公式。 紧接着,三月份,Anthropic 发布了他们的 harness 方案:一个 Planner → Generator → Evaluator 的循环。 到了四月份,Anthropic 跟吃错药一样,把定义改成了:harness = agent loop,工具环境 = meta-harness。然后再把 harness、meta-harness 和什么脑子啊、手啊拼起来,组成 Managed Agents。 五月和七月,龙虾作者又出来谈 loop engineering 和 graph engineering。火了一小阵,随后又没什么声音了。 八月份,DeepSeek Harness 带着 Everything is a Plugin 的概念横空出世。我当时就说,这就是个 UI harness。现在看来,时间也验证了我的判断。 八月底,OpenAI 看到 DeepSeek Harness 爆火,也整出了一个“OpenAI Harness”的概念,实则就是 Codex。 九月份似乎消停了一阵。到了十月,Pi 又带着 1.0 版本登场,自称 minimalist harness 😂。 感觉 harness engineering 就像哈姆雷特一样:一千个人心中,有一千种 harness。定义越来越宽泛,也越来越离谱。
显示更多
回顾一下 harness engineering 发展的历史,至今似乎还没有一个边界清晰的解释,能说清楚它到底是什么。 先是二月份,OpenAI 发布了 Harness Engineering 的 blog,介绍他们如何从一个 empty repo 出发,搭建可靠的文档、知识库、测试体系和日志环境,供 agent 开展开发工作。 几乎同一时间,LangChain 通过修改提示词、工具和 middleware,将 Deep Agents 在 benchmark 上的成绩提升了 25%,随后提出了 Agent = Model + Harness 的公式。 紧接着,三月份,Anthropic 发布了他们的 harness 方案:一个 Planner → Generator → Evaluator 的循环。 到了四月份,Anthropic 跟吃错药一样,把定义改成了:harness = agent loop,工具环境 = meta-harness。然后再把 harness、meta-harness 和什么脑子啊、手啊拼起来,组成 Managed Agents。 五月和七月,龙虾作者又出来谈 loop engineering 和 graph engineering。火了一小阵,随后又没什么声音了。 八月份,DeepSeek Harness 带着 Everything is a Plugin 的概念横空出世。我当时就说,这就是个 UI harness。现在看来,时间也验证了我的判断。 八月底,OpenAI 看到 DeepSeek Harness 爆火,也整出了一个“OpenAI Harness”的概念,实则就是 Codex。 九月份似乎消停了一阵。到了十月,Pi 又带着 1.0 版本登场,自称 minimalist harness 😂。 感觉 harness engineering 就像哈姆雷特一样:一千个人心中,有一千种 harness。定义越来越宽泛,也越来越离谱。
显示更多
想了解为什么Anthropic和openai都把Slack当作重要的办公生态?这东西真的很多人在用吗? 我在国外读高中和大学,工作加实习3年。唯一一次接触Slack就是一门历史选修课,教授用来发布作业的。 大部分时候用的都是Microsoft Teams, 有那么两位年轻教授用Discord。
显示更多
0
28
28
1
转发到社区
这个文案怎么在哪里见过🤔 @ScarletKc
0
14
37
0
转发到社区
今天试用 Cue 时,我又想起最初做 sandbox 时的一个问题: 为什么我们总默认“一个 Agent 对应一台 computer”?无法实现以下两种场景。 场景 1: 我希望 Agent A 同时使用两台电脑:在电脑 1 上改代码、跑测试,在电脑 2 上查资料、验证产品流程。 场景 2: 两位 Agent 可以协作使用同一台电脑。Agent A 写代码,Agent B 负责review。 tbh 我不太看好这种runtime one-on-one绑定的模式。 未来一定agent比人多,比电脑多,比可以启动的vm,服务器多得多。各大厂商似乎还没有意识到这一点。
显示更多
0
31
58
2
转发到社区
向大家强烈推荐 LoopX —— 由字节跳动火山引擎 OpenViking 核心贡献者(清华 EE / ByteDance AML 的黄瑞腾 @huangruiteng)亲手打造的 Loop Engineering + Graph Engineering 开源项目。 它是一个轻量级「状态内核」,专为超长程 AI Agent 设计:让 Agent 在无人干预下稳定运行 200+ 小时 而不漂移。核心把 Goal、Todo/Gate、Evidence、Authority、Handoff 等外置成可执行控制面,像一块「Agent 专属 Kanban」,既管 loop,又管状态图,支持 auto PR 修复、AutoML 实验、自进化能力升级等真实场景。已与 OpenViking 深度合作,开源仓库完整可跑。 GitHub:
显示更多
开源项目 LoopX:超长程 Agent 自主运行 200+ hours,状态不漂移。 我的技术主张是:LLM 上下文有限,长程 Agent 需要外置状态,通过完备的状态管理、监督和规划,让 Agent 无人干预时跑得稳、持续有产出;有人干预时跑得更好,能吸收反馈继续演进。 两条真实 trajectory 分别跨越 220.7 / 272.9 小时,跨多轮执行、等待、人工决策、writeback 与 resume 后,整个 loop 仍能找回目标、证据和下一步。 目前 LoopX 已有 3 个 showcase:auto PR issue fix、AutoML experiment 和 auto coredump fix。 以 OpenViking 开源仓库的 PR issue fix 为例,Agent 不只是循环写代码。它需要持续理解 issue 的不同状态,判断何时开发、何时等待、何时请求 review,处理 CI、冲突和上游变化,并连续交付多个 PR。 这对应 LoopX 的 domain state 管理:领域系统决定真实状态,LoopX 负责把状态投影成下一步可执行的工作。 与此同时,Agent 还可以在干活过程中实现能力自进化。当它发现现有系统缺少某项能力时,可以提出 feature、完成开发与验证、发布新的离线或在线版本,再使用新能力继续原来的任务。 长程 Agent 天然适合自进化,“完成工作”和“升级完成工作的系统”可以在同一条长程轨迹中发生。 LoopX 把这些信息外置成结构化控制面: • Goal / Vision:目标是什么,什么不能被局部优化牺牲 • Todo / Gate:当前执行的 frontier,以及必须留给人的关键判断 • Identity / Authority:谁能 claim、writeback、approve • Evidence / Receipt:每次推进留下什么可回读证据 • Quota / Scheduler:何时继续执行,何时安静等待 • Handoff / Recovery:换模型、换会话、换 host 后如何恢复 你也可以把它理解为一块专门给 Agent 设计的可执行 Kanban。 普通看板只展示“谁在做什么”;LoopX 的状态会直接约束和驱动下一次 bounded turn,让看板本身成为执行系统的一部分。 这套系统最强的地方是通用性。它不只可以修 PR,还可以做 auto research、长期实验、自媒体运营、复杂 feature 开发和办公任务。 Agent 不再只是一次性的回答机器,而可以围绕一个人的 vision,长期工作、等待、吸收反馈、积累证据并持续演进。 LoopX 从一开始 build in public:状态协议、CLI、控制面实现和真实运行轨迹都进入了开源仓库;它也已经和 OpenViking、NoKV 等 agent infra 项目形成了开源合作伙伴关系。 我希望 LoopX 最终能放大每个人的 vision 和想象力。只要你有自己的目标、想法或技术主张,就能拥有一个全天候继续工作和探索的 Agent 系统,帮助你把愿景一点点变成现实。 欢迎试用、提 issue、贡献代码,或者用一个真实的 multi-day task 跑 LoopX。
显示更多
0
17
490
89
转发到社区