观澈辨机

最近我一直在思考一个问题： 未来的 Agent 系统，会是 One Harness, Many Models，还是 Many Agent Profiles, Standardized Interfaces？ 我越来越倾向后者。 但这里先说明，我并不否定 One Harness, Many Models。 恰恰相反，我自己就在使用这种模式。 Codex 可以接不同模型，Pi 也可以接不同模型。很多场景下，这种方式简单、直接，而且效果已经不错。 我真正怀疑的是另一件事： 我们是否应该期待一个 Harness，通过不断切换模型，就覆盖所有 Agent 场景？ 我的答案越来越偏向：不需要。 先说一下我对几个概念的理解LLM 是模型本身。 Harness 是驱动模型完成 Agent 工作的一整套运行和执行机制，包括 Agent Loop、Context、Tools、Session、Recovery 等。 而我这里所说的、真正可以拿来工作的 Agent Profile，更接近： 123456789Agent Profile=Harness+Model+Configuration+Ca...

最近看了克里斯托弗·诺兰的《奥德赛》。 电影给我留下最深印象的，并不是奥德修斯的冒险本身，而是一个更大的背景： 一个旧秩序正在结束。 特洛伊战争持续多年，传统的英雄主义、战争规则和信任关系都开始失效。 最终结束战争的，不是更强大的武力，而是特洛伊木马。 欺骗取代了正面对抗。 于是很容易产生一种理解： 因为人们开始使用阴谋和欺骗，所以信任被破坏，秩序开始崩坏。 但我越来越觉得，因果关系可能恰恰相反。 不是阴谋诡计摧毁了原本健康的秩序。 而是： 旧秩序已经发展到了无法解决现实问题的阶段，于是阴谋诡计开始成为一种有效策略。 特洛伊木马不是秩序崩坏的原因。 它更像是秩序已经发生变化以后，浮出水面的一个症状。 当然，我们无法确定导演真正想表达什么，也没有必要过度揣测。 电影只是给我打开了一个问题。 而这个问题远远不只属于古希腊。 为什么新的，总是倾向于否定旧的？我们经常看到一种现象。 一个旧制度出现问题以后，人们很容易得出一个结论： 这个体系不行了。 随后，判断又会进一步扩大： 过去的方法都是错的。 再进一步： 必须重新来过。 这种逻辑在政治、社会运动、企业管理甚至普通...

最近和同学聊天。 我们聊到现在的就业环境：工资不高，工作强度却越来越大；很多公司看起来规模不小，真正进去以后却发现管理混乱，团队像个草台班子。 一个同学突然说： 会不会真正顶尖的人，都不属于“地球人”了？ 这当然是一句玩笑。 但我突然想到一个问题： 我们在一个环境里看到的“优秀者”，真的是这个世界上最优秀的人吗？ 还是说，我们看到的，其实只是： 这个环境能够留下来，并且愿意展示给我们看的那些人？ 这个问题让我重新想到一个我越来越习惯使用的观察方式： 结构主义。 当然，我这里说的不是哲学教科书里严格意义上的结构主义，而是从结构主义中借来的一种观察世界的方法。 它非常简单： 不要只盯着人和事件，要去寻找产生这些人和事件的结构。 我们天然喜欢把问题归结到“人”人脑非常喜欢讲故事。 而故事天然需要人物。 所以当一家公司出了问题，我们很容易说： 老板不行。 管理层太蠢。 员工没有责任心。 产品经理能力不够。 程序员水平太差。 同样，当我们看到某个人成功，也容易归结为： 他聪明。 他努力。 他有能力。 他情商高。 这些判断当然不一定错。 但它们经常只解释了表层现象。 因为还有一个...

最近在使用 Codex 时，我逐渐形成了一种很高效的工作方式。 我为不同项目保留独立的 Workspace 和 Thread，再用一个主 Thread 负责分派任务、接收结果，并完成第一轮判断。 大致是这样： 1234567Human ↓Master Thread ↓├── Workspace A / Thread A├── Workspace B / Thread B└── Workspace C / Thread C 这样，我不需要同时盯着很多会话。 我只需要关注主 Thread 做出了什么判断，以及接下来应该把任务交给谁。 一开始，我只是觉得这种方式很省精力。 后来我突然意识到一个问题： 为什么这些子 Thread 天然是按照项目和 Workspace 区分，而不是按照“架构师 Agent”“开发 Agent”“测试 Agent”来区分？ 这个问题，让我重新审视了现在很常见的一类 Multi-Agent 设计。 我们很容易把 Agent 设计成人类组织很多 Multi-Agent 系统喜欢采用这样的结构： 12345CEO Agent├── HR Agent├──...

一次软件研发组织范式的重新思考。 一、为什么今天讨论的是组织，而不是 AI？过去两年，AI 在软件研发中的讨论大多围绕工具展开： AI 是否能写代码？ AI 是否能提高开发效率？ AI 是否会替代程序员？ 这些问题都很重要。 但经过持续实践，我们越来越认为： AI 带来的最大变化，不是开发方式，而是组织方式。 真正值得讨论的，不是某个 AI 工具，而是： 软件研发组织将如何演进。 二、软件研发组织的三次演进第一阶段：个人开发（Personal Development）软件规模较小时，一个人可以完成产品、开发、测试和部署，组织成本最低。 但随着系统越来越复杂，个人能力逐渐成为瓶颈。 第二阶段：多人组织（Multi-person Organization）这是过去几十年软件工程建立起来的组织范式：通过专业化分工解决复杂性。 典型组织链路是： 1产品 → 设计 → 前端 → 后端 → 测试 → 运维 软件工程中的大量理论和实践，包括： 项目管理 敏捷开发 DevOps 微服务 CI/CD 软件质量体系 本质上都在回答同一个问题： 如何组织更多的人，共同...

最近在使用 Codex 推进开发时，我越来越强烈地感受到一件事： AI 改变了软件开发的生产方式，但它并没有让过去几十年形成的软件工程思想失效。 恰恰相反。 当 Agent 能够越来越快地理解需求、修改代码、运行测试，甚至独立推进一个复杂任务以后，过去很多为了“提升开发效率、控制复杂度”而形成的软件工程方法，开始表现出新的价值。 最直观的感受是： 更省 Token，也更不容易跑偏。 但如果继续往下看，会发现 Token 只是表象。 真正发生变化的是： 软件工程正在从“管理人的复杂度”，进一步变成“管理 Agent 的不确定性”。 而 Agent 越强，这件事情反而越重要。 从我以前做过的 ProTable 说起很多年前，我做前端架构时，开发过类似 ProTable 这样的基础组件。 当时的目的很简单。 业务系统里有大量列表页面：用户列表、订单列表、客户列表、审批列表…… 如果每一个开发人员拿到需求以后，都重新实现一次查询、分页、筛选、Loading、异常处理、权限控制，那么不仅开发效率低，最后每个人写出来的东西也很容易不一样。 所以我们会把这些已经反复出现的问题抽象掉。 一个...

最近，我开源了一个本地优先的密码与令牌管理器：KeptNear。 最初开发它的原因很简单：我想要一个交互友好、真正由用户控制数据的本地密码管理器。 后来，在使用 Codex 处理越来越多实际工作时，我发现了另一个问题： Agent 也开始需要凭据了。 GitHub Token、API Key、数据库密码、云平台 Access Key……这些凭据通常散落在环境变量和配置文件里。Agent 需要时要反复配置，也容易在后续任务中遗忘。 更重要的问题是： Agent 为了完成一项操作，真的需要知道凭据本身吗？ Agent 需要的可能不是秘密，而是能力个人密码管理器主要围绕人设计：保存密码、自动填充、复制到剪贴板，然后由人决定何时使用。 但 Agent 不只是读取信息，它会执行 CLI、调用 API，并操作外部系统。传统做法通常是先把 Token 交给 Agent，再由它完成操作： 1Token → Agent / Tool → HTTP Client → External Service 这会让 Token 进入更多不必要的路径，例如 Agent 上下文、Shell 环境、调试日志...

关于人与 AI 的认知连续性 长期使用 ChatGPT 后，我逐渐感受到一种过去使用其他工具时很少有过的体验：它不只是在记住我，还开始沿着我的思路思考。 我曾经把同一个问题分别交给 ChatGPT 和直接调用的 GPT API。两边使用的都是能力很强的模型，得到的结果却明显不同。 API 给出的回答并不差，但更像一个面向任何人的通用答案。ChatGPT 的回答却能接住我真正关心的问题，沿用我习惯的分析方式，并把一个刚刚产生的想法放回过去反复讨论的脉络中。 有时，它甚至能够使用我的思维逻辑帮助我分析问题，写出一篇与我过去表达高度一致的文章。只看最终文本，已经很难简单判断它究竟是由人写的，还是由 AI 写的。 这让我意识到，ChatGPT 所延续的可能不只是一些关于我的信息。 它正在依据长期对话中反复出现的特征，形成一个关于“我可能如何思考”的模型。 在目前的 AI 产品中，ChatGPT 可能是对人的认知连续性做得最好的一个。但这种连续性并不总是稳定。 它有时能够准确延续我的思路，有时却会保留某个结论，而遗漏这个结论形成的条件；它能够识别一个相对稳定的我，却未必总能及时理解一个...

最近一年，我一直高强度使用 Codex、Claude Code 等 AI Agent 来参与日常开发。 刚开始的时候，我和很多人一样，总想着不断给 Agent 增加能力。 遇到一种任务，就增加一个 Skill；发现一条规则，就写进 AGENTS.md；做完一次复杂排查，就想着沉淀下来，方便以后继续使用。 当时觉得这样会越来越智能。 后来我发现，事情并没有那么简单。 Skill，不是越多越好我现在越来越少创建 Skill，也越来越克制使用 Skill。 不是因为 Skill 没用。 恰恰相反，是因为 Skill 很有用，所以更应该慎用。 每加载一个 Skill，本质上都是在告诉 Agent： 除了当前任务，你还需要额外关注这些规则、流程和约束。 如果当前只是一次代码阅读、一次简单修改，或者定位一个问题，这些额外的信息很可能不会帮助 Agent，反而会稀释当前任务真正需要关注的内容。 很多时候，不使用 Skill，Agent 本身已经能够很好地完成工作。 上下文不是越多越好后来我慢慢养成了一个习惯： 如果当前任务没有明确需要，就不要提前加载。 以前，我总觉得多读一点总没坏处。 后...

很多时候，我们以为自己是在解决问题。 但更真实的情况可能是：我们正在一个已经被组织好的问题里努力。 比如一次项目延期，表面看是“有人没有按时交付”。于是我们很自然地开始追问：谁负责？谁拖了进度？下次怎么避免？ 这些问题当然有意义。但如果只停在这里，我们看到的只是内容层。再往深处看，延期背后可能是职责边界不清、需求变化没有入口、资源承诺与实际能力不匹配，或者团队默认把不确定性压给最后一个环节。 这时，问题就不再只是“谁没做好”，而变成了： 这个问题是如何被结构制造出来的？ 这正是 JanusPath 最初想处理的东西。 一、不要只问发生了什么，还要问它为什么以这种方式发生在 JanusPath 的第一篇论文 The Janus Path: A Structured Cognitive Model 中，核心命题可以用一句话概括： 结构先于内容。 也就是说，我们看到的事件、观点、冲突、选择，往往不是孤立出现的。它们背后有一套关系、边界、位置、张力和反馈机制，正在规定什么会被看见，什么会被忽略，什么会被当成自然。 一个会议争吵，内容层看是情绪冲突；结构层看，可能是权责不对等。 一个产品失...