摘抄一段不错的思考：

OpenClaw 和 Hermes Agent 看起来都是开源 AI Agent 框架，License 也都是 MIT，但两者的方向并不一样：OpenClaw 更像一个跨平台 AI 助手网关，重点是把 Agent 接入 Telegram、Slack、微信、iMessage 等各种消息渠道；Hermes Agent 更像一个自我进化型个人 Agent，重点是长期运行、自动学习、自动生成和管理 Skill，让系统越用越懂你。

核心差异主要在架构和记忆机制。OpenClaw 把 Runtime 当成一等公民，内置 PI、Codex、Claude CLI、外部 ACP Agent 等多种运行时，每个模型可以明确指定由哪个 Runtime 执行，找不到就报错，不会静默回退。它更像一个调度多个 Agent Runtime 的窗口管理器。Hermes 则以自己的 Sync Agent Loop 为核心，Codex Runtime 只是可选扩展，更像是在原生 Agent 里接入一个 Codex 插件。

记忆系统上，OpenClaw 更透明，长期记忆、每日工作记忆都落在 Markdown 文件里，用户可以直接查看、编辑和审查；它会把日常观察整理成候选内容，但是否升级为长期记忆由人决定。Hermes 更自动化，基础是 Memory.md、User.md，再叠加 SQLite + FTS 检索和多个外部 Memory Provider；它的 curator 机制会自动给 Skill 打分、降权、归档，尽量减少人工参与。

权限和插件生态也体现了两种哲学。OpenClaw 倾向集中管理认证信息，通过 TokenSync 统一管理 ChatGPT OAuth、OpenAI Key、Anthropic Key、本地 CLI Auth 等，方便审计，但安全责任也更集中。Hermes 倾向委托，把 Codex 相关认证交给 Codex CLI 自己维护，攻击面更小，但登录态需要分别管理。插件上，OpenClaw 有 ClawHub，支持 Skills、Code Plugins、Bundle Plugins、Souls，也兼容 Codex、Claude、Cursor 的部分格式；Hermes 则通过 Python Entry Points 和 agentskills.io 标准做扩展，更强调开放互通和自我改写 Skill 的能力。

怎么选很明确：如果你要的是一个接入渠道广、跨平台消息入口强、本地配置透明、适合手动掌控的个人 AI 助手网关，OpenClaw 更合适；如果你要的是一个长期运行、自我学习、自动维护 Skill、深度接入 IDE 和开发者工作流的 Agent，Hermes Agent 更合适。两者可以都装来测试，但主入口最好只选一个，因为 Session、记忆和 Skill 系统各自独立，长期混用容易导致上下文分裂。

吹着风，看着闲暇的人们，感觉这一刻身体才属于真正的自己

macOS 用户用 iCloud Drive 经常遇到这个报错：

Resource deadlock avoided (OSError: [Errno 11])

尤其是用 Hermes Agent、OpenClaw Agent 处理文件时特别常见，比如书评发布、自动化脚本等场景。

我把解决方案做成了一个开源小工具：

fix-icloud-sync

核心思路很简单：通过 TextEdit 强制触发 iCloud 把文件真正下载下来，绕过 stub 文件的死锁问题。

目前已适配：
- Hermes Agent（已做正式 Skill）
- OpenClaw Agent（已做正式 Skill）
- Claude Code / Cursor / 普通终端（一键安装）

仓库地址：
github.com

有遇到同样问题的可以试试，欢迎提 Issue。

早上去机场，果然又打了一个烟味臭车，距离上次打到正常车已经记忆模糊了哈哈。关键这还是滴滴打车，不是高德那种外包打车。然后就让 AI 给我分析了下为什么会这样：
articleweb_search:1#0web_search:1#1web_search:1#10
国内网约车烟味、异味问题确实已演变成行业性顽疾，尤其在冬季更为突出。这个问题不是简单的"司机不讲卫生"，而是行业生态恶化的外在表现。海外（主要指美国、欧洲等市场）虽然也存在类似投诉，但管控逻辑和国内有本质差异。
一、国内问题有多严重？
不是个别现象，而是系统性问题。 2024年底"越来越容易打到臭车了"冲上热搜，乘客普遍反映烟味、汗味、食物残渣味混合，"像进了司机的被窝"citeweb_search:1#10。到了2025年，问题已从快车蔓延至专车甚至豪华车，有乘客表示"一个月内打了三次专车，只有第一次是无烟车"citeweb_search:1#7。
核心原因不是司机"懒"，而是生存挤压：
• 收入微薄：中国新就业研究中心2025年数据显示，网约车司机月均收入仅7623元，其中六成是家庭唯一收入来源citeweb_search:1#6。
• 超长工时：司机日均工作12小时以上，连续服务超4小时平台才强制下线20分钟citeweb_search:1#5。车辆成为他们的"食堂"甚至"房子"，吃喝拉撒睡都在车里解决。
• 成本转嫁：洗车、除臭、清洁的时间和经济成本完全由司机承担。在平台抽成（部分高达25%-27%）和低价竞争下，司机只能牺牲服务质量换取接单量citeweb_search:1#12web_search:1#16。
• 聚合平台失控：高德等聚合平台接入大量中小服务商，缺乏统一服务标准和线下管理能力，"轻资产"模式稀释了服务品质citeweb_search:1#9web_search:1#12。
二、海外有类似问题吗？
存在，但程度和性质不同。
1. 美国（Uber/Lyft）
• 政策层面：Uber社区指南明确将"在车内吸烟"列为财产损害行为，违规需承担清洁维修费，严重者封号citeweb_search:2#3。Lyft更明确："驾驶时在车内吸烟违反社区规则，可能有乘客存在呼吸系统问题"citeweb_search:2#1。
• 执行层面：平台主要依赖乘客事后投诉，但美国司机平均收入、工作时长和生活条件相对优于国内，极少出现"以车为家"的极端情况。烟味投诉多属个别司机违规，而非行业通病。
2. 欧洲与日本
• 法律环境：欧洲多国（如英国、德国、意大利）对公共场所吸烟有严格限制，网约车作为密闭服务空间，司机吸烟面临高额罚款甚至吊销营运许可citeweb_search:2#8。
• 日本：日本对车内清洁要求极高，且加热不燃烧烟草（HNB）虽普及，但司机在载客时吸烟会被视为严重服务失格，社会舆论压力极大。
根本差异：海外平台对"车内吸烟"有明确的零容忍政策和退出机制（封号/罚款），而国内长期停留在"扣分-培训-恢复"的循环，违规成本过低。
----
三、为什么国内平台"管控难"？
平台并非完全不作为，滴滴已推出"拉黑异味车"、清新车PK赛、香香车、暂停服务等措施citeweb_search:1#5web_search:1#10，但效果有限，原因在于：
1. 责任转嫁：平台将清洁成本完全推给司机，又通过算法压榨司机收入，导致"既要马儿跑，又要马儿不吃草"citeweb_search:1#0web_search:1#1。
2. 聚合模式漏洞：高德打车被约谈指出"对合作网约车平台管理不到位、压低运价"等问题，聚合平台以"信息中介"身份规避承运责任citeweb_search:1#9。
3. 退出机制缺失：司机被一家平台扣分，可换另一家平台继续接单，行业黑名单未打通citeweb_search:1#3。
4. 监管滞后：虽有《网络预约出租汽车经营服务管理暂行办法》，但对"车内空气质量"缺乏量化标准和强制检测手段。
----
四、怎么办？——从个人到 systemic 的解决路径
作为乘客，当下能做什么
• 善用"拉黑"功能：滴滴已上线"拉黑异味车"（12个月内不再匹配该车辆），遇到烟味车果断使用并配合差评

• 选择服务层级：如果预算允许，优先选择"专车"或"优享"（虽然近年专车品质也在下滑，但概率上仍优于快车）。
• 即时沟通：上车后发现烟味，可要求司机开窗通风（冬季可开外循环），司机拒绝则有权取消订单并投诉。
• 保留证据：拍照/录像记录车内环境，投诉时附上，平台处理效率更高。
平台需要做的（而非正在做的）
北京大学政府管理学院教授马亮指出，单纯寄希望于乘客拉黑和司机罚款，无助于根本解决问题
平台应：
1. 承担清洁成本：为司机提供免费或补贴价的定期深度清洁/除臭服务，而非只发"香香卡"掩盖气味。
2. 建立空气标准：明确车内空气质量量化指标（如PM2.5、异味等级），引入第三方检测。
3. 算法向善：停止以"口碑值"逼迫司机超长时间工作，保障司机有清洁车辆的时间和基本收入。
4. 聚合平台担责：高德等应落实"首问负责和先行赔付"，对接入平台的服务质量承担连带责任
监管与行业层面
• 立法细化：在地方网约车管理条例中增设"车内环境"专章，将"无异味"作为强制考核标准，不达标暂停营运citeweb_search:1#3web_search:1#20。
• 行业黑名单互通：打通各平台司机不良记录，避免"东家不做西家做"。
• 司机权益保障：政府提供廉租房、可负担停车场和充电桩，让司机不必"以车为家"
• 价格机制：部分地区可尝试网约车政府指导价，避免无底线的低价竞争导致服务崩盘。
----
总结
国内网约车烟味问题的本质是平台经济模式下，服务成本被转嫁给最弱势的司机端，最终由乘客承担后果。海外之所以相对可控，并非技术先进，而是平台-司机-监管三方对服务底线有共识，且违规代价足够高。
短期内，乘客只能靠"拉黑+投诉"自保；中长期看，必须推动平台从"流量收割者"转向"价值共创者"，让清洁成本回归平台，让司机有尊严地提供服务。否则，"臭车"只会从快车的标配，变成整个行业的底色。

Day 2 我想回答一个问题：把 Job Agent 链接发给你的 agent 之后，到底会发生什么？

昨天发了一个真实使用 case，有人问我"怎么用"，今天展开说说。

先把边界放在前面：昨天提到的 242 个岗位、15 分钟、30-40 条发送和 4-5 个回复，都只是个人内测 case，不是产品承诺。

首先，你不需要再安装一个新软件，也不需要学一套新的操作界面。

Job Agent 的用法是这样的：你把它提供的链接发给你的 agent——不管是 Claude Code、Hermes、OpenClaw 还是 Codex——然后用自然语言告诉它你想找什么工作。

你可以这么说：

"我 5 年后端经验，想找北京或深圳的岗位，薪资不低于 30k，不接大小周。"

不需要填表，不需要按固定格式。你的 agent 会自己理解。

接下来它会做几件事：

1. 读你的简历，提取经历、能力和限制条件。
2. 抓取匹配的候选岗位。
3. 根据 JD 和你的背景做匹配排序。
4. 给值得聊的岗位起草个性化的招呼语。

这些跑完之后，agent 会给你一份结果清单，里面标注了匹配度、推荐理由和建议的招呼语草稿。

然后你来看。招呼语可以改，岗位可以跳过，不合适的直接删掉。你看完决定要不要推进。

Job Agent 不会替你自动发送，也不会鼓励你无限投递。它做的事情是帮你看、帮你筛、帮你写，但最后的判断权在你。

这其实也是我们对"agent 求职"的理解：agent 做重复劳动，人保留决策权。不是让 AI 替你投更多，而是让它先帮你把不值得花时间的岗位过滤掉。

如果你已经在用 Claude Code / OpenClaw / Hermes / Codex 这类 agent，可以直接申请 early access。如果你还没有自己的 agent，也可以先填表单告诉我们你的使用环境，我们按顺序邀请。

评论区可以说说：你正在用的 agent、你的求职方向、以及求职流程里最想省掉哪一步。

求职最耗时的不是“投”，是“筛” — 我用 agent 重构了整个流程

我自己用 Boss 直聘找工作的时候，每天晚上打开就是三小时起步。翻岗位列表、判断匹配度、写打招呼消息、逐条点发送。反复做这四件事。

做到后来眼睛扫 JD 都不进脑子了——更像在完成流水线工序，不是在做职业决策。真正花在"这个岗位到底值不值得投"上的时间，被压缩到几乎没有。

试过几种方案都没解决问题。简历群发工具覆盖率高但招呼语千篇一律，HR 一眼看出模板。ChatGPT 写求职信能用，但手动复制 JD、粘贴上下文、再复制回平台的流程反而更长。这些方案都在解决"怎么做得更快"，但没有解决"怎么把你的精力从机械操作中释放出来"。

后来我做了个实验：把整个流程拆成 6 步交给 agent。简历解析、岗位爬取、匹配打分、过滤、生成招呼语——前 5 步 agent 跑，第 6 步我审核确认后才发送。

核心转变不是自动化程度，而是角色转换——从操作者变成审核者。我的精力从"写 40 条招呼语"变成"看 40 条招呼语够不够好"。

在我自己的内测样本里：累计对接过 242 个岗位（多次累计，不代表稳定处理能力）。某次内测中，全流程从岗位处理到招呼语准备大约 15 分钟（单次样本，不代表每次都这个速度）。同一批次确认发送了约 30-40 条招呼语（单批样本），收到约 4-5 个回复，粗略回复率约 12-15%（小样本，不代表稳定结果，不同简历/岗位/城市/市场行情会有差异）。

分享这些不是为了暗示"你也能跑到这个数据"，而是我觉得 agent 类产品应该用真实数据说话。

关于隐私：简历原文件和平台 Cookie 永远留在你电脑上，只有脱敏后的结构化文本发到云端做 AI 处理。代码开源，你可以在客户端代码里完整验证这个数据流。建议你在试用任何求职工具前先问三个问题：原始数据存在哪？什么数据会外传？能不能在代码里验证？

如果你也在用 agent 辅助日常任务，可以试试把求职流程也编排进去。关键不是自动化程度，而是你能不能把精力从机械操作转移到决策本身。

需要我把执行清单发你，评论区留"清单"。也可以直接走官网 jobagent.agentmesh360.com 申请 early access。

继续 Kaprathy 的知识库理论，我构建了我的 KB2.0 并开源了。地址在文章中

大家都在讨论 Harness，我也聊聊我最近的一些感悟