问题

[blissful dock]

我看到官方在5月7号更新的dag runtime，我其实自己是写了这个模块的，所以我担心更新后会不会把我的dag runtime给覆盖掉？这个官方要考虑这点

[outer verge]

I saw the official dag runtime update on May 7th. I actually wrote this module myself, so I am worried that my dag runtime will be overwritten after the update? The authorities need to consider this

[zealous depot]

是的，这个担心是合理的。

如果你的 DAG runtime 是直接改在 ~/.hermes/hermes-agent 官方源码目录里的，那么它属于本地代码改动。hermes update 正常会先检测本地改动，stash 保存，再拉取官方更新，然后尝试把你的本地改动恢复回来。

所以它不应该被故意静默覆盖，但如果 5 月 7 日的 DAG/runtime 更新改到了同一批文件，就可能出现 git 冲突，需要你手动处理。

更新前建议先检查一下：

cd ~/.hermes/hermes-agent
git status --short
git diff --name-only

如果这里能看到你的 DAG runtime 文件，先备份一下再更新：

cp -a ~/.hermes/hermes-agent ~/.hermes/hermes-agent.backup-before-dag-update

然后再跑：

hermes update

[outer verge]

Yes, this concern is legitimate.

If your DAG runtime is changed directly in the ~/.hermes/hermes-agent official source code directory, then it is a local code change. hermes update will normally detect local changes first, stash save, then pull official updates, and then try to restore your local changes.

So it shouldn't be silently overwritten on purpose, but if the May 7th DAG/runtime update changes the same batch of files, there may be a git conflict that requires you to handle it manually.

It is recommended to check before updating:

cd ~/.hermes/hermes-agent
git status --short
git diff --name-only

If you can see your DAG runtime file here, back it up first and then update it:

cp -a ~/.hermes/hermes-agent ~/.hermes/hermes-agent.backup-before-dag-update

Then run:

hermes update

[blissful dock]

如果在tg这些应用的窗口显示上下文过长了，我是应该/new 呢还是他自动会切换新窗口，我用户这边是无感的？是不是不管是自动还是/new 聊天框里的记忆都会丢失了 ？

[outer verge]

If the window display context of these applications is too long, should I press /new? Or will it automatically switch to a new window, and the user will be unaware of it? Will the memory in the chat box be lost regardless of whether it is automatic or /new?

[blissful dock]

⚠️ Context length exceeded: max compression attempts (3) reached.

🔄 Session auto-reset — the conversation exceeded the maximum context size and could not be compressed further. Your next message will start a fresh session.

[blissful dock]

听别人说最近一周hermes变得更聪明了，我不知道这个说法的可靠性？是因为增加了什么功能吗，还是知识加了dagruntime？hermes的更新会变得更聪明吗？是因为harness做的更好的缘故还是因为功能的缘故？还是因为什么？

[outer verge]

I heard from others that Hermes has become smarter in the past week. I don’t know how reliable this statement is? Is it because some functions have been added, or is it because dagruntime has been added to the knowledge? Will Hermes's update make it smarter? Is it because the harness is better or because of its functionality? Or because of something?

[blissful dock]

我在搭建一个多agent流程-4090-24Glinux服务器版本，但我发现流程推理下去特别慢，是因为上下文积累越来越多变慢了吗？不知道是不是我技术能力的问题，感觉多agent本地部署还是很难有生产力，就4-5个agent串联推理，等上1-2个小时一套流程，是不是有优化方案？按理不应该这么慢

[outer verge]

I am building a multi-agent process - 4090-24Glinux server version, but I found that the process reasoning is very slow. Is it because more and more contexts are accumulated and it becomes slower? I don’t know if it’s a problem with my technical ability. I feel that it’s still difficult to be productive when deploying multiple agents locally. I just use 4-5 agents for serial inference and wait 1-2 hours for a set of processes. Is there any optimization plan? Logically it shouldn't be so slow

[blissful dock]

⏳ Still working... (54 min elapsed — iteration 90/90, running: terminal)

⚠️ Iteration budget exhausted (90/90) — asking model to summarise

[zealous depot]

对，这里有两个问题叠在一起。

第一个是上下文设置。你看到 max compression attempts (3) reached，说明 Hermes 已经尝试压缩上下文，但压缩模型没有成功把会话压到可继续使用的状态。这个通常需要把 compressor/auxiliary model 换成更适合长上下文和总结的模型，最好不要用太小的本地模型来做压缩。

第二个是工作流问题。不要让一个 Telegram session 无限变成整个宇宙。长任务最好分阶段：每一阶段结束后让 Hermes 写一个 summary、保存到文件/Kanban/memory，然后 /new 开新 session 继续。这样比一直堆上下文稳定很多。

本地 4090 可以玩，也可以做很多事情，但多 agent + 长上下文 + 串行推理，本来就会慢。hosted model 的优势就是速度、上下文、并行能力都更适合这种工作流。你可以继续用本地模型做隐私敏感或小任务，但如果你想让 4-5 个 agent 真正高效跑流程，建议至少试一次 hosted inference，对比一下速度差距会很明显。

[outer verge]

Yes, there are two questions stacked up here.

The first is context settings. You see max compression attempts (3) reached, indicating that Hermes has tried to compress the context, but the compression model has not successfully compressed the session to a state that can continue to be used. This usually requires changing the compressor/auxiliary model to a model more suitable for long context and summary. It is best not to use a local model that is too small for compression.

The second is a workflow issue. Don’t let one Telegram session infinitely become the entire universe. Long tasks are best divided into stages: after each stage, let Hermes write a summary, save it to the file /Kanban/memory, and then open a new session with /new to continue. This is much more stable than always heaping context.

Local 4090 can play and do many things, but multi-agent + long context + serial reasoning will inherently be slow. The advantage of the hosted model is that its speed, context, and parallel capabilities are more suitable for this kind of workflow. You can continue to use the local model to do privacy-sensitive or small tasks, but if you want 4-5 agents to run the process really efficiently, it is recommended to try hosted inference at least once. The speed difference will be obvious when compared.

[blissful dock]

据说最近更新的版本有一个功能是自动整理skill的，不知道有没有？名称是什么？如何使用，在agent的设置上我应该专门设置哪些文件，对agent是有很大提升的？比如soul.md

[outer verge]

It is said that the recently updated version has a function that automatically organizes skills. I wonder if it is available? What's the name? How to use it? Which files should I set specifically for the agent settings? Will it greatly improve the agent? For example soul.md

[zealous depot]

有，这个功能叫 curator，也就是 skill curator / 技能整理器。

它的作用不是“让模型突然变聪明”，而是帮你维护 agent 自己创建出来的 skills：检查哪些 skill 很久没用、哪些可能重复、哪些应该标记 stale、哪些可以 archive。它不会自动删除，archive 也是可恢复的。

先看状态：

hermes curator status

想先预览，不改任何东西：

hermes curator run --dry-run

确认没问题后手动跑一次：

hermes curator run

如果暂时不想让它后台自动整理：

hermes curator pause

恢复：

hermes curator resume

如果某个你自己写的 skill 很重要，不想被自动标记或归档：

hermes curator pin <skill-name>

注意两点：

第一，curator 主要处理 agent-created skills。官方 bundled skills 和 hub-installed skills 不会被它随便改掉。

第二，它对提升 agent 有帮助，但不是最核心的提升点。真正影响很大的还是：模型能力、上下文长度、工具是否配置正确、skills 是否写得清楚、SOUL.md 是否简洁。

SOUL.md 不建议写太长。它适合放稳定身份和工作偏好，比如：

你是谁、主要使用语言、回答风格、常用工作方式、哪些事情要谨慎。

不要把大量教程、日志、旧错误、完整项目文档都塞进 SOUL.md。那些应该放到单独文件、skills、memory 或项目文档里。SOUL.md 越像一本大书，agent 越容易慢、乱、抓错重点。

我的建议：

SOUL.md 保持短。
重复工作写成 skill。
长期事实放 memory。
项目规则放项目里的 AGENTS.md。
旧日志和调试记录不要放进每次都会加载的文件里。

这样比单纯开启 curator 更能提升稳定性。

[outer verge]

Yes, this function is called curator, which is skill curator/skill organizer.

Its role is not to "make the model suddenly smarter", but to help you maintain the skills created by the agent itself: check which skills have not been used for a long time, which ones may be repeated, which ones should be marked as stale, and which ones can be archived. It is not automatically deleted and the archive is recoverable.

Let’s look at the status first:

hermes curator status

Want to preview first without changing anything:

hermes curator run --dry-run

After confirming that there is no problem, run it manually:

hermes curator run

If you don’t want it to be automatically organized in the background for the time being:

hermes curator pause

Recovery:

hermes curator resume

If a skill you wrote yourself is important and you don't want to be automatically tagged or archived:

hermes curator pin <skill-name>

Note two points:

First, curator mainly deals with agent-created skills. Official bundled skills and hub-installed skills will not be changed casually by it.

Second, it is helpful to improve the agent, but it is not the core improvement point. What really has a big impact is: model capability, context length, whether the tools are configured correctly, whether the skills are clearly written, and whether the SOUL.md is concise.

SOUL.md is not recommended to be too long. It is suitable for stable identity and work preferences, such as:

Who are you, the main language you use, your answering style, how you usually work, and what things you should be careful about.

Don't cram tons of tutorials, logs, old bugs, complete project documentation into SOUL.md. Those should be placed in separate files, skills, memory or project documents. The more SOUL.md looks like a big book, the easier it is for the agent to be slow, messy, and miss the key points.

My suggestion:

SOUL.md Keep it short.
Repetitive tasks are written as skills.
Long-term facts are

stored in memory.
Project rules are placed in AGENTS.md in the project.
Don't put old logs and debug records into files that will be loaded every time.

This can improve stability more than simply turning on curator.

[zealous depot]

看起来这个问题已经回答清楚了，我先把这个帖子标记为已答复/关闭。

如果后面你在 DAG runtime、skills、curator、多 agent 流程、上下文压缩，或者本地/hosted 模型配置上遇到其他问题，随时再开帖或回复我们就可以，我们可以继续帮你排查。