fangjun

我写的关于 web3 的 thread，整理一下以便查阅。

@GenAI_is_real can you share the article link? thanks

Today I read a lengthy piece on Harness Engineering — tens of thousands of words, almost certainly AI-written. My first reaction wasn't "wow, what a powerful concept." It was "do these people have any ideas beyond coining new terms for old ones?" I've always been annoyed by this pattern in the AI world — the constant reinvention of existing concepts. From prompt engineering to context engineering, now to harness engineering. Every few months someone coins a new term, writes a 10,000-word essay, sprinkles in a few big-company case studies, and the whole community starts buzzing. But if you actually look at the content, it's the same thing every time: Design the environment your model runs in — what information it receives, what tools it can use, how errors get intercepted, how memory is managed across sessions. This has existed since the day ChatGPT launched. It doesn't become a new discipline just because someone — for whatever reason — decided to give it a new name. That said, complaints aside, the research and case studies cited in the article do have value — especially since they overlap heavily with what I've been building with how-to-sglang. So let me use this as an opportunity to talk about the mistakes I've actually made. Some background first. The most common requests in the SGLang community are How-to Questions — how to deploy DeepSeek-V3 on 8 GPUs, what to do when the gateway can't reach the worker address, whether the gap between GLM-5 INT4 and official FP8 is significant. These questions span an extremely wide technical surface, and as the community grows faster and faster, we increasingly can't keep up with replies. So I started building a multi-agent system to answer them automatically. The first idea was, of course, the most naive one — build a single omniscient Agent, stuff all of SGLang's docs, code, and cookbooks into it, and let it answer everything. That didn't work. You don't need harness engineering theory to explain why — the context window isn't RAM. The more you stuff into it, the more the model's attention scatters and the worse the answers get. An Agent trying to simultaneously understand quantization, PD disaggregation, diffusion serving, and hardware compatibility ends up understanding none of them deeply. The design we eventually landed on is a multi-layered sub-domain expert architecture. SGLang's documentation already has natural functional boundaries — advanced features, platforms, supported models — with cookbooks organized by model. We turned each sub-domain into an independent expert agent, with an Expert Debating Manager responsible for receiving questions, decomposing them into sub-questions, consulting the Expert Routing Table to activate the right agents, solving in parallel, then synthesizing answers. Looking back, this design maps almost perfectly onto the patterns the harness engineering community advocates. But when I was building it, I had no idea these patterns had names. And I didn't need to. 1. Progressive disclosure — we didn't dump all documentation into any single agent. Each domain expert loads only its own domain knowledge, and the Manager decides who to activate based on the question type. My gut feeling is that this design yielded far more improvement than swapping in a stronger model ever did. You don't need to know this is called "progressive disclosure" to make this decision. You just need to have tried the "stuff everything in" approach once and watched it fail. 2. Repository as source of truth — the entire workflow lives in the how-to-sglang repo. All expert agents draw their knowledge from markdown files inside the repo, with no dependency on external documents or verbal agreements. Early on, we had the urge to write one massive sglang-maintain.md covering everything. We quickly learned that doesn't work. OpenAI's Codex team made the same mistake — they tried a single oversized AGENTS.md and watched it rot in predictable ways. You don't need to have read their blog to step on this landmine yourself. It's the classic software engineering problem of "monolithic docs always go stale," except in an agent context the consequences are worse — stale documentation doesn't just go unread, it actively misleads the agent. 3. Structured routing — the Expert Routing Table explicitly maps question types to agents. A question about GLM-5 INT4 activates both the Cookbook Domain Expert and the Quantization Domain Expert simultaneously. The Manager doesn't guess; it follows a structured index. The harness engineering crowd calls this "mechanized constraints." I call it normal engineering. I'm not saying the ideas behind harness engineering are bad. The cited research is solid, the ACI concept from SWE-agent is genuinely worth knowing, and Anthropic's dual-agent architecture (initializer agent + coding agent) is valuable reference material for anyone doing long-horizon tasks. What I find tiresome is the constant coining of new terms — packaging established engineering common sense as a new discipline, then manufacturing anxiety around "you're behind if you don't know this word." Prompt engineering, context engineering, harness engineering — they're different facets of the same thing. Next month someone will probably coin scaffold engineering or orchestration engineering, write another lengthy essay citing the same SWE-agent paper, and the community will start another cycle of amplification. What I actually learned from how-to-sglang can be stated without any new vocabulary: Information fed to agents should be minimal and precise, not maximal. Complex systems should be split into specialized sub-modules, not built as omniscient agents. All knowledge must live in the repo — verbal agreements don't exist. Routing and constraints must be structural, not left to the agent's judgment. Feedback loops should be as tight as possible — we currently use a logging system to record the full reasoning chain of every query, and we've started using Codex for LLM-as-a-judge verification, but we're still far from ideal. None of this is new. In traditional software engineering, these are called separation of concerns, single responsibility principle, docs-as-code, and shift-left constraints. We're just applying them to LLM work environments now, and some people feel that warrants a new name. I don't know how many more new terms this field will produce. But I do know that, at least today, we've never achieved a qualitative leap on how-to-sglang by swapping in a stronger model. What actually drove breakthroughs was always improvements at the environment level — more precise knowledge partitioning, better routing logic, tighter feedback loops. Whether you call it harness engineering, context engineering, or nothing at all, it's just good engineering practice. Nothing more, nothing less. There is one question I genuinely haven't figured out: if model capabilities keep scaling exponentially, will there come a day when models are strong enough to build their own environments? I had this exact confusion when observing OpenClaw — it went from 400K lines to a million in a single month, driven entirely by AI itself. Who built that project's environment? A human, or the AI? And if it was the AI, how many of the design principles we're discussing today will be completely irrelevant in two years? I don't know. But at least today, across every instance of real practice I can observe, this is still human work — and the most valuable kind.

@wangray 这蛮好的，不过也很尴尬，分享这些东西对自身有没有价值呢？

发现我还是分享的太少了😅 很多我觉得没必要说的东西，可能真有人想看 知识的诅咒：你越熟悉一件事，越低估它对别人的价值 所以接下来我打算多分享一些"显而易见"的东西 — 工作流、踩过的坑、日常怎么用 AI 你觉得太简单不值得说的，发出来试试

@jakevin7 试试github copilot

OpenCLI 5K star了，目前整个项目没有爆发式的增长，都是一点点的在稳步提升。 另外最近 token 不太够用了，好难受啊！！！ codex for open source 也申请不成功😢

我现在很好奇 x block 的上限，我现在block 每一个广告...

@kalasoo 这是一个重要问题

其实我总在想 Opus 5.0 发布的时候 有多少今天的东西都没有意义了 那些过度思考的 xxx Engineering、各种架构、各种概念、各种安装

@yibie 人格化是错误的方向，短期的热闹而已

这是我去年的遗憾。 gtdstudy.com

@wwwgoubuli 他不知道为什么非要安装那些东西，安装了，我立刻问，安装的什么，先把那些安装删掉了

慕名试了一下 gstack。 确实很yc，与我的刻板印象相符。 全是那套他们自己奉若圭臬，但已经过时的片儿汤话。 很像是那种照着上个商业时代，投资人最爱追的那些东西，做的一个角色扮演游戏。有点复古味道，会让我想起之前风起云涌的年代。 但也就这样了。 劝大家别浪费时间，一群title高高在上的人能有什么新世代的经验感悟？ 就该自己上手，你写出来的一定比Garry tan 写出来的东西强。

@xicilion 您需要一台新电脑

@null12022202 @kevinma_dev_zh 我之前想过，还 notebooklm 搞了一批 ppt 先分析了 但想想这种 skill 大概很难有什么实际价值 做就是炫技，就不想搞了

@kevinma_dev_zh 忽然想到也可以把高效能人士的七个习惯里面的精髓创建成skill，来指导自己每天都工作规划，避免在琐事上投入太多导致重要的事被耽误。

Garry 的 gstack skills 已经很多人转发了，但我还是想多说一句。 这个开源的东西，表面上是一套 Claude Code 的 skills 配置，但里面真正有价值的是 `/office-hours`——在你写一行代码之前，先用六个强迫性问题逼你把产品想清楚。需求是真实的吗？市场够窄吗？你有没有在骗自己？ 这套思维框架，比任何写代码的 skills 都值钱，没有之一。 多花时间读里面的具体内容，不只是安装完跑跑就算了。这是 Garry 把 YC 十几年的 founder 审查方法论直接开源出来，不多说了，我也要赶紧学习了。 github.com/garrytan/gstack

AK 的观点非常有价值，他一直在最前沿试验。但并非对大神不敬，他熟悉的其实更多是研究，而非工程，研究里面的编码经验多大程度能够到工程？肯定不是全部。

Garry Tan 的 Skill 的中文版使用指南，22个每一个都详细分析了： gona.ai/skills/index-g…

@xicilion 我自动用了 slidev 之后，就再也不用任何其他的了 不要说PPT/Keynote，连reveal 都不用了

@xicilion 装了，vs和chrome都装了 这不是懒吗，如果有个cli，然后一键打开：）当然如果serve下更好：）

@xicilion 好赞，突然想求个 markdown viewer 的 cli 因为现在待在命令行的时间多了

@jakevin7 这个牛！

OpenCLI 迎来重磅更新：External CLI Hub 发布！ 🚀 以前，为了让 AI Agent 调用某个工具，你需要反复教它写不同的命令行。 OpenCLI 成为所有 CLI 的统一入口与路由中心！ 这样只需要让 AI agent 知道通过 OpenCLI 就能知道他有哪些 CLI可以使用，不用再搞一堆 CLI skill 了 核心亮点： 零配置纯透传 不用写任何适配代码！直接运行 opencli obsidian search 或 opencli gh pr list，参数和输出100% 极其原生透传给原 CLI。AI 只需要认识 opencli 这一个入口，就能调动全网工具！ 按需无感自动安装 想调用的 CLI 还没装？OpenCLI 会自动探测平台，帮你静默执行 brew install gh 或 npm i -g readwise，装完立马接力执行 一键接入你的本地宇宙 你本地有自己写的牛逼小工具？只需一行 opencli register mycli，它就会立即出现在 opencli list 注册表中，被你的 AI Assistant瞬间“看见”并掌握使用权！ github.com/jackwener/open…

@bozhou_ai 也有类似的体会，我称：刚性代码，柔性Skill。 分阶段做任务，分阶段的部分在代码，结果检验也在代码，不行让 Skill 在一个阶段内部重做。

做 Agent 的一个体会： Prompt 负责引导，不负责约束 工程负责约束，不依赖模型自觉 少在 Prompt 里写规则，多在系统里做约束

@hylarucoder 谢谢，可以加到 AGENTS 里面去了

@null12022202 一种可能性，是我们对英文对话不敏感 英文黑话一样多

忽然想起来 ChatGPT 刚出来的时候，都说得用英语和它对话，中文语料不足，回答质量不高，一转眼几年过去了，用中文对话已经不知不觉成为日常了。

@xicilion 太赞同，我一个五步的，中间有的步骤本质上还是检查步骤，我外面加的防范代码加了一万行，准确说现在1.09万行，略有点无语了，我在看看能不能缩减到5000以内

@wangray 说起来完美，但那些上下文真的很难发挥作用

卷模型不如卷状态 Harness 搭多好，别人可以学可以抄 用什么模型，花钱就能买 但你的 agent 在你的业务里跑了三个月 那 90 天积累的领域上下文，没有人能回到三个月前去追 模型的代差会被下一次 release 抹平 私有状态的积累只会越拉越大 🔥 早一天让 agent 干真实的活 就多一天别人追不上的护城河