技术文章 知乎 - 孔某人 2026/08/12
文章认为 AI for math（AI 辅助数学研究）是 2026 年进展速度第二快的方向，与 AI Coding 同级，但短期商业价值不如后者。作者指出前沿 LLM 已基本达到人类数学家水平并在部分维度超越，数学界从轻视转向参与。通过近期尝试，作者发现当前通用 Agent 与 LLM 在解决数学猜想上仍存在系统性短板：面对复杂探索空间时缺乏推进和管理多个探索方向的能力，模型倾向于制定完整计划、回避不确定方向，可能源于 Coding 场景 RL 的负面外溢；同时 Agent 层面临 Context 压力和任务拆分问题。作者建议所有目标通用 Agent 的团队尝试 AI for math，因为其验证成本低、能暴露方案盲点，是 AI4Science 和深度探索场景的“新手村”。文章观点基于个人观察，非严谨实验。
推荐收录。文章对 AI for math 的进展、短板和通用 Agent 的关联做了有深度的原创分析，指出了当前 LLM 在不确定探索中的关键缺陷（如倾向完整计划、回避风险），并建议将数学作为低成本测试场景。适合关注 LLM/Agent 能力边界、AI4Science 和自主迭代的研究者与工程师，可迁移价值在于用低交互成本暴露系统盲点；风险是部分结论依赖个人经验，但整体判断有启发性。
工程实践 知乎 - 孔某人 2026/08/09
文章分享了作者在构建Multi-Agent系统进行中型数学探索任务时的架构设计经验，重点涵盖Token成本优化、可并发度瓶颈分析与Worker拆分、系统迭代的持续需求与独立升级Agent设计、详细的角色划分（Merger、TaskCreater、TaskWorker、TaskReviewer、SystemUpdater、UserInterface、Reporter、Critic）、高层视角隔离以及全局状态与消息通讯的工程实现。文中还讨论了基于GitHub Issue的方案受限于性能和非结构化问题，进而转向专用全局状态Server，并介绍了Controller模型内部Master-Worker架构以隔离上下文。作者指出整个方案仍较复杂，需较长时间试运行和打磨，但提供了丰富的工程决策依据和迁移价值。
推荐收录，因为文章从真实工程探索出发，系统性地分析了Multi-Agent系统设计中的成本控制、并发瓶颈、角色分工、系统迭代和全局状态管理等关键问题，给出了具体可迁移的架构思路和教训，适合对Agent系统设计、AI工程化及复杂系统迭代有深入需求的读者参考。
技术文章 知乎 - 孔某人 2026/08/03
文章从Agent执行长程任务时状态管理困难的问题出发，提出了Agentic Job Runtime的概念。作者指出，当任务涉及大量共享资源、优先级调度和动态规划时，单一Agent通过文档更新状态容易丢失信息，因此需要引入队列、数据库表等传统数据结构，并采用多Agent主从架构（类似蜂群或主从式并发）来管理状态和流水线执行。该Runtime类似现代编程语言运行时，需支持状态持久化、恢复、回滚、不同LLM配置，以及可视化和权限控制。文章最后辨析了与Agent OS的区别，认为它不是对底层资源的封装管理，而是面向单个Job的执行环境，可能是Agent OS最早落地的方向。整体提供了一种务实的系统设计思路，适合大规模Agent工程场景。
文章不是空泛的概念讨论，而是给出了具体的技术方案和工程架构，对解决Agent复杂状态管理和任务协调有实际指导价值。适合AI工程师、Agent框架开发者和对多Agent系统感兴趣的研究者，其设计思想可迁移到需要长程、多任务并发的Agent系统中。
工程实践 知乎 - 孔某人 2026/07/27
本文分享在长程自迭代Agent场景中观察到的一种“可塑性丧失”现象：当Agent积累大量经验记忆和历史迭代记录后，反而变得懒惰和抗拒大规模改进。作者以auto research任务为例，指出即使有完备harness和记忆，后续迭代效率并未提升，且冷启动时的可塑性优于依赖历史记录的状态。分析原因认为，模型通过上下文看到大量失败尝试和历史过度自信论述，这些信号在训练数据中常常与任务结束相关，且当前模型对持续性环境的长历史探索训练不足。文章给出应用层和模型层的启示，如丢弃记忆重新开始、抑制过度自信与懒惰等，并讨论了解决路径的困难。该发现揭示了LLM Agent在记忆利用上的反直觉缺陷，对工程实践具有警示和参考意义。
推荐收录，因其基于真实工程观察，揭示了一个未被广泛重视的Agent记忆腐败问题，并提供成因分析和规避思路。对开发长任务LLM Agent、auto research系统的工程师有直接启发，关于历史经验可塑性的权衡可迁移至其它持续性智能体设计，具有长期参考价值。
个人心得 知乎 - 孔某人 2026/07/26
文章记录了作者使用Claude Opus 5进行高强度开发任务的1.5天体验，核心观察是模型在复杂方案设计中表现出的“懒惰”现象：随着问题规模扩大，局部设计质量下降且倾向于自我辩护，但经指正后又能推翻原有方案，说明其尚未学会有效分解子问题并保持思考深度。作者将这一现象与模型规模关联，猜测复杂设计能力与参数量正相关，并指出根本解决方向在于教会模型对可分解任务进行拆分思考。文中还涉及因模型行为变化而需调整prompt、使用“Context, not control”原则优化Skill等实践心得。结论认为下一代模型的优化方向之一是提升复杂设计的分解思考能力。本文为速报性质，观点基于个人短期体验，缺乏系统实验对比，但提供了对模型能力边界的深入观察。
文章从真实开发体验出发，提出了模型懒惰的新维度——复杂设计中的思考衰减，并关联模型规模，为理解大模型的能力边界提供了鲜活素材。作者对提示词适应、Agent行为分析和“分解思考”的洞见，对从事AI辅助开发的读者具有直接启发，可迁移用于设计更稳健的AI工作流。推荐收录为个人反思类内容，以补充精选库中关于模型工程应用的实战观察。
技术文章 知乎 - 孔某人 2026/07/22
文章分析了Claude模型服务端返回的thinking signature的加密机制与绕过方法。作者先通过protobuf结构逆向出签名格式，推断其采用BLAKE2b哈希、随机nonce、AEAD加密与信封加密（随机DEK经KEK加密）保护思考内容，认为密码学上无明显漏洞，量子计算亦难破解。随后提出攻击面：构造包含thinking块与tool call的历史消息，注入工具结果后追问，可引导模型复述思考过程，虽不能精确还原原文，但能提取关键内容。测试发现fable模型拒绝复述，opus等可接受，反映安全护栏差异，并提及OpenAI的事后审查更严格。文章属科普性技术分析，基于真实API格式，非完整工业方案，但揭示了模型思维链保护的实际应用与潜在弱点。
推荐收录，因其从protobuf逆向到攻击面分析，提供了对主流模型思维链保护机制的第一手技术剖析。对AI安全研究者、逆向工程和LLM应用开发者而言，文中信封加密在服务端的落地方式与利用历史消息绕过防护的思路具有可迁移的参考价值。尽管是科普，但分析基于真实API结构，证据具体，有助于理解模型输出控制的工程边界。
技术文章 知乎 - 孔某人 2026/07/16
本文指出 LLM 已进入长程任务时代，数据与环境构造需从追求极难单步问题转向利用真实用户 session 重构时间轴来提供易得的中间 reward。作者分析了模型懒惰、遗漏任务、未确认用户意图等常见问题，提出通过对比完整 session 结果来判定阶段性完成度，并将用户中途介入的信息前移为事先提问，从而构造出更理想的目标 session 或里程碑校验。文章强调数据多样性的价值，认为获取真实用户场景数据是模型厂商的核心竞争力，并讨论了云端 workspace 等隐秘获取上下文的方式。边界在于假定已拥有真实 Agent 产品用户 session 数据，且训练依赖 RL 架构，对于没有此类数据的团队难以直接应用。
本文提供了长程任务时代 RL 数据构造的工程洞察，直接针对 Agent 训练中的核心痛点提出了可操作的重构方法，对从事 LLM 训练和 Agent 开发的工程师有直接参考价值。作者结合实践与前沿论文，展示了如何将真实用户交互转化为有效的训练信号，避免生搬硬套思考过程，可迁移至各类需要长程任务能力的 AI 产品研发中。
技术文章 知乎 - 孔某人 2026/06/28
文章讨论的是 Agent 应用层而非模型层的“自动自我改进”，作者认为它更像一种理想口号，而不是已经成熟的技术方案。文中把可自优化的部分拆成 Memory、SOP/workflow 和 Harness，并指出它们都受总上下文长度、模型难以抽取可泛化规则等约束。随着运行案例增多，这些记忆和流程会越写越厚，却未必更高效，反而可能迅速消耗上下文预算。作者认为在固定场景、充足历史数据和专家持续评估下，确实能做出人机混合的增益，但很难低成本泛化为全自动方案。文章还提醒，当前围绕 Long-Horizon、Harness、Loop Engineering 等概念的传播，容易把有限能力包装成“万灵药”。
收录，因为文章直接指出了应用层自我改进的关键边界：上下文容量、泛化抽象能力和持续评估成本，都是 Memory/SOP/Harness 难以自动增长的硬约束。适合做 Agent 产品和 AI 工程的预期管理，但它主要是经验性判断，缺少量化实验支撑。
技术文章 知乎 - 孔某人 2026/06/21
这篇文章讨论了长程任务训练正在从以 GRPO 为代表的“整段 rollout 级”方案，转向更适合 agentic 场景的 critic-based PPO / step-based 训练范式。作者重点分析了为什么长任务、tool call、外部反馈会让 credit assignment 变得更困难，以及为何以 tool-call turn 作为中间粒度，可能比纯 token-level critic 或 trace-level reward 更可行。文章还进一步提出了一个更激进的思路：引入结构化的 belief block 和 update 机制，把模型对当前环境与任务的认知显式化，以降低 actor 与 critic 的理解成本，并讨论了其潜在收益与 reward hacking 风险。
推荐收录，因为它不是单纯跟风讨论热点，而是围绕长程任务训练中的 credit assignment、粒度切分和训练范式选择，给出了可迁移的机制分析。对关注 agent、LLM 训练和 RL 设计的读者来说，这篇文章能帮助理解为什么“tool-call turn 级”监督会重新变得重要，以及新范式的边界在哪里。
工程实践 知乎 - 孔某人 2026/06/17
文章围绕主流 Agent Harness 中的 Goal 机制展开，对 Claude Code、Codex、Kimi Code、OpenClaw、Hermes 等实现做了并列比较，重点分析它们在长程任务中的自动续跑、目标达成判定、token 预算、blocked/complete 状态和 Hook 触发方式。作者通过双语 Prompt、状态机结构和工具说明，解释了 Goal 本质上是在模型停下时自动发起“继续/复核”回合，用来缓解模型过早停工或自我判断不完整的问题，同时也指出它不是万能方案，仍受当前上下文判断偏差和额外回合开销的限制。
推荐收录，因为它不是泛泛介绍“Agent 功能”，而是基于实际版本和逆向分析，给出了 Goal 机制的实现差异、状态设计与提示词细节，具有很强的一手参考价值。对做 LLM 工程、Agent 框架设计和自动化任务编排的读者来说，文章能直接迁移为状态机设计、结束判定和预算控制的实现思路。
技术文章 知乎 - 孔某人 2026/06/10
这篇文章系统对比了主流 Agent Harness 中 SubAgent、Agent as Tool 与 Multi-Agent 的实现差异，重点分析了 Claude Code、Codex、OpenAI Agents SDK 和 OpenCode 在上下文继承、Fork、Coordinator、Teammate/Swarm、Handoff 等机制上的设计取舍。作者结合逆向分析、版本差异和实际使用体验，指出当前主流实现更偏向 SubAgent/Agent-as-Tool，而不是传统对等 Multi-Agent；其核心价值在于既能解决长上下文任务，又能引入旁观者视角与并行子任务能力，但相关结论受版本与灰度状态影响，边界条件需要注意。
推荐收录，因为它不是泛泛而谈“多智能体很强”，而是把不同产品的 Agent 编排机制拆开比较，能帮助读者理解 Agent Harness 的真实工程权衡。对做 AI 工程、开发 CLI/IDE 代理、或设计多阶段任务编排系统的人，都有较强的迁移价值。
技术文章 知乎 - 孔某人 2026/06/09
这篇文章系统对比了主流 Agent Harness 在 Context 压缩上的实现差异，覆盖 Claude Code、Codex/OpenAI Agents SDK、OpenCode、Pi、Kimi Code 以及 Hermes Agent 等多个项目。作者不仅梳理了共同的压缩触发思路、token 估算方式和兜底策略，还通过版本级逆向与 prompt 还原，分析了各家在本地压缩、服务端压缩、局部压缩、tool result 清理、增量摘要更新等方面的具体设计。文章的核心结论是：当前多数实现仍处在较早期阶段，普遍依赖 LLM 生成历史摘要来替换上下文，但不同框架在压缩触发、摘要格式、分支处理和服务端协同上的工程成熟度差异明显。
推荐收录，因为它不是泛泛介绍“上下文压缩”的概念，而是对真实 Agent Harness 的实现细节做了横向拆解，能直接帮助读者理解不同框架如何管理长上下文。对于做 AI Agent、编排框架、上下文管理或提示词工程的读者，这篇文章有很强的可迁移价值，尤其适合参考其压缩触发、摘要模板和分支处理思路。
工程实践 知乎 - 孔某人 2026/06/03
这篇文章系统对比了主流 Agent Harness 的 Memory 实现，重点分析 Claude Code、Codex/OpenAI Agents SDK、OpenClaw 等方案在记忆写入、召回、整合与淘汰上的设计差异。作者不仅贴出并解读关键 prompt 和实现细节，还讨论了文本记忆与向量 RAG 的取舍、同步写入与离线整合的延迟成本，以及“记什么、不记什么”的质量边界。文章结论偏向 Claude Code 的方案更均衡、Codex 更像事后挖掘式记忆、OpenClaw 的实现相对华而不实，但整体仍提供了可迁移的 Agent 记忆架构分析框架。
推荐收录，因为它不是泛泛介绍“Agent 有记忆”这一概念，而是深入比较了多个真实产品的记忆系统如何落地、如何权衡延迟与质量、以及为什么当前主流方案普遍避开传统 RAG。对于做 Agent、LLM 工具链或 AI 编程助手的人，这些分析具有很强的可迁移价值。
个人心得 知乎 - 孔某人 2026/05/28
文章围绕“长程任务”重新审视白领工作与 Agent 能力边界，认为很多可持续 1 小时以上的任务并不是抽象的“白领任务”，而是高度专业化、强依赖上下文和质量标准的岗位流程。作者进一步讨论了任务执行中不可避免的信息获取与交付标准同步问题，提出在更高 Agent 渗透率下，组织形态可能从按岗位划分转向按工艺流程划分，并比较了类人多 Agent、中央 Agent 和质检返工机制等不同设计路径。
推荐收录，因为它不是泛泛谈“Agent 很强”，而是把长程任务拆到信息流、交付标准、组织结构和工作流单元这些更可迁移的设计层面，适合做 AI 工程与 Agent 产品设计的参考。虽然文章偏观点和反思，缺少严格实验数据，但它对理解长任务场景、团队协作与中控式 Agent 架构的权衡很有启发。
工程实践 知乎 - 孔某人 2026/05/25
本文介绍了一个面向1小时到2天级无人值守长任务的通用 Agent 框架 Deputy，重点服务非 Coding 白领办公场景，而不是专门优化编程任务。作者围绕“按需生成 harness”“Master-Worker + Reviewer/Watcher 审计”“基于文件系统的任务级 Memory”“允许 Worker 使用更便宜模型”等设计给出一整套架构取舍，并解释了为何不采用单 Agent、对等 Multi-Agent 或完全依赖现成 Agent 内核的方案。文章同时明确指出当前 0.1.0 版本仍需要打磨，且开源代码只是高层 spec 的编译结果，适合作为长任务 Agent 架构的参考实现而非直接生产落地模板。
推荐收录，因为它不是泛泛介绍“Agent 很强”的产品稿，而是围绕长任务执行、审计纠偏、记忆机制和 harness 生成给出了可复用的架构判断。对关注 LLM 工程化、任务编排和长时 автономous delivery 的读者来说，文章能提供较强的迁移价值与设计边界感。
工具笔记 知乎 - 孔某人 2026/05/13
文章讨论 AI Coding 时代软件工程实践如何形成“复利”，核心观点是：不要把 Coding Agent 当成需要不断手工修补的工具，而应把它看作一种新的“编译器”。作者提出应明确区分人工强干预的“干预边界”和交给 AI 执行的“High-level Spec”层，尽量通过规范化文档、设计约束和重复指令沉淀来复用，而不是事后逐步编辑生成结果。文章还指出 AI Coding 在熟悉领域、高质量代码、强可靠性场景中收益会下降，边界不清时越容易陷入重复干预和低效协作。
推荐收录，因为它不是泛泛讨论“AI 写代码很快”，而是给出了一个可迁移的软件工程视角：把 AI Coding 的问题建模成编译与接口设计，而不是单次生成与修补。对正在使用 Coding Agent 的开发者、团队和工具实践者，这篇文章能帮助他们重新划分人机协作边界，减少无效干预。
工程实践 知乎 - 孔某人 2026/05/11
这篇文章延续上一部分，讨论下一代 Agent 架构为什么不能只依赖单一 harness 自动生成，而需要引入更复杂的“智能 harness”或多角色协作设计。作者从长任务场景出发，系统列出当前 LLM/Agent 的一组关键问题，包括上下文窗口不足、任务中后期懒惰、奖励目标偏移、单上下文复盘失效、元认知不足以及长期任务能力薄弱，并进一步指出这些问题在 multi-agent 场景里还会叠加协作可靠性和协作规划问题。
推荐收录，因为文章不是泛泛谈“多智能体更强”，而是基于作者的原型实践，明确拆解了当前 Agent 系统的失效模式和需要补强的架构环节。对做 AI 工程、Agent 框架或长任务自动化产品的人来说，文中的问题清单、角色分工思路和边界判断都有较强迁移价值。
职业经验 知乎 - 孔某人 2026/05/09
这篇文章围绕“大组织内过度推行 AI Coding 是否会适得其反”展开，核心观点是：在核心业务和大型组织中，AI 编码带来的短期提速可能会被需求膨胀、系统复杂度上升、review 退化和组织激励错配迅速抵消。作者进一步指出，单靠渐进式重构并不能根治问题，真正的矛盾在于需求控制、交付节奏、团队治理和历史复杂度管理，而这些往往比“提效”更难推动。
推荐收录，因为它不是在讨论 AI Coding 的工具技巧，而是在分析大组织里 AI 采用后的组织性副作用、流程失衡和长期维护成本，这类判断对技术管理者和资深工程师有较强参考价值。文章能帮助读者从“生成率”和“交付速度”之外，重新审视需求质量、架构可维护性和团队激励对 AI 落地的真实约束。