欢迎来到我的博客。
我会在这里写:工程实践与踩坑笔记、系统设计与架构思考、工具与效率、以及读书和生活杂感。
欢迎来到我的博客。
我会在这里写:工程实践与踩坑笔记、系统设计与架构思考、工具与效率、以及读书和生活杂感。
接手一个陌生代码库时,大多数人的第一反应是打开源码目录开始翻文件。Ally Piechowski 在 The Git Commands I Run Before Reading Any Code 里给出了另一条路:先别读代码,先读 git 历史。提交记录里藏着代码质量、团队健康度和项目风险的大量信号, 五条命令就能把它们挖出来。本文是这篇文章的摘要笔记。 1. 变更热点:哪些文件被改得最多 git log --format=format: --name-only --since="1 year ago" \ | sort | uniq -c | sort -nr | head -20 列出过去一年改动次数最多的 20 个文件。高频变更本身不一定是坏事,但高变更 + 低所有权的文件 是典型的风险区:改动零碎、难以预测,还会悄悄拖垮团队的排期估算。作者引用了微软研究院 2005 年的 一项研究:按组件规模归一化后的「相对 churn」,比绝对改动次数更能预测缺陷密度。 2. Bus Factor:项目压在几个人身上 git shortlog -sn --no-merges 按提交量给贡献者排序。如果一个人占了 60% 以上的提交,这就是一个关键依赖风险——尤其当这个人 已经半年没出现在提交记录里。作者建议顺手确认一下:历史上的头部贡献者,最近是否还活跃。 注意:squash merge 工作流会掩盖真实作者——统计反映的是「谁合并的」,不是「谁写的」。 3. Bug 聚集:哪些文件反复出问题 git log -i -E --grep="fix|bug|broken" --name-only --format='' \ | sort | uniq -c | sort -nr | head -20 找出提交信息里带 fix / bug / broken 的文件。把这份榜单和第 1 条的 churn 榜单对照着看, 交集就是风险最高的代码:反复出 bug、却从未被认真重构的文件。 ...
过去一年,「agent」这个词已经被用滥了。但真正决定一个 agent 好不好用的,往往不是模型本身, 而是包在模型外面的那一层东西——harness。LangChain 在 The Anatomy of an Agent Harness 里给了一个很干净的定义: Agent = Model + Harness。Harness 是「除模型之外的所有代码、配置与执行逻辑」。 模型决定上限,harness 决定你日常摸到的下限:上下文怎么管、记忆放哪、工具怎么给、 权限怎么收、循环由谁驱动。这篇文章拆四个有代表性的 harness,看它们对同一组问题给出的不同答案。 四位选手 定位 出品方 驱动方式 记忆载体 Claude Code 交互式编码 agent Anthropic 人驱动的终端会话 CLAUDE.md / AGENTS.md + 记忆目录 OpenClaw 自托管个人助理 Peter Steinberger(社区) 消息网关 + 心跳定时器 磁盘上的 Markdown 文件 Hermes 常驻自治 agent Nous Research 多渠道网关 + cron 后台 三层记忆(SQLite + Markdown) DeepAgents 开发者用的 harness SDK LangChain 开发者定义的图运行时 可插拔虚拟文件系统 简单交代下背景: Claude Code 是 Anthropic 的终端编码 agent,也是「harness 与模型联合演化」路线的代表—— LangChain 那篇文章特别指出,Claude Code 和 Codex 的模型后训练是带着 harness 一起做的。 OpenClaw 是 Peter Steinberger 在 2025 年底发布的自托管个人助理(前身叫 Clawdbot,短暂改名 Moltbot 后定名 OpenClaw),几个月内成为增长最快的开源 agent 项目之一;Steinberger 本人已于 2026 年 2 月加入 OpenAI。 Hermes 是 Nous Research 的开源 agent,把「Harness Engineering」这个概念直接产品化, 主打自我改进与 7×24 后台运行。 DeepAgents 是 LangChain 的「电池全含」harness(langchain-ai/deepagents), 不是给最终用户的产品,而是给开发者构建自己 agent 的底座,跑在 LangGraph 运行时上。 四者面向的场景完全不同,但要回答的是同一组设计问题。下面逐个维度看。 ...
为什么开这个博客 很多想法散落在各种 Slack、笔记、聊天窗口里,时间一长什么都没留下来。开个博客, 强迫自己把问题想清楚再写出来。 这里会写什么 工程实践:工作里踩过的坑、调优过程、排查故事 系统设计:大数据 / 分布式 / 平台侧的架构思考 工具与效率:让自己开发体验更好的小工具与自动化 读书与思考:不完全是技术的内容 技术栈 这个博客用 Hugo 构建,主题是 PaperMod, 源码和文章都在 GitHub 仓库里,推到 main 分支后 GitHub Actions 会自动构建并部署到 GitHub Pages。 git add . git commit -m "post: new article" git push 就这样,几十秒后就能在 https://ethan6188.github.io 上看到更新。 下一篇 还没想好。先让这里运转起来,再慢慢填内容。