最近在做大模型网关，之前也积累了比较丰富的Coding Agent经验，看了一些针对Anthropic’s Programmatic Tool Calling的分析，感觉都有一些不到位，技术上来说，Anthropic实现了一个服务端的CodeAct工具，将代码编写和执行都放在服务端进行，并不在API中完全暴露，由此，API的使用者可以在减少token消耗的情况下实现目标。 如果在客户端实现，则至

一篇碎碎念，好久没更新了。 最近花了很多时间在研究各个模型之间的差别，同一个prompt下面，不同的厂商的模型所表现出的trajectory差别巨大。同时，随着年末大家的混战，我们惊喜的发现OpenAI、Anthropic、Google三足鼎立的局面似乎正在形成。当我们觉得GPT-5 Codex横扫四方时，Sonnet 4.5的出色表现让我感觉Anthropic并未落后，而Gemini 3 Pro

是时候思考如何构建一个可扩展的云原生Coding Agent系统了。 Agentic Workflow自Claude code横空出世，人们越来越倾向于采用一个简单的定义来描述Agent：大型语言模型在循环中自主使用工具来完成某个目标。 Agent Design Considerations鉴于大模型的消息是无状态的，我们很容易拆分出LLM消息和工具实现两部分，MCP协议给了我们这样的一个exa

简单记录一些对于Debug Agent的思考，与Coding Agent不同，Debug Agent需要包含更多的环境感知，需要更多的细节设计 ContextDebug Agent应当由三个重要部分组成：用户上下文、程序上下文和自动化交互方案 用户上下文当人们深入地使用Agent进行编程的时候，常常陷入debug困难的境地，表现为： 很难描述自己遇到了什么问题，一种方案是进行截图或者录屏，然后交

最近看了一些LLM评估的文章，很明显有两个倾向 使用LLM进行评估（LLM-as-Judge）是一种AI-Native的方式，或许在Human alignement（对齐）上可以做到比较好，但仍然受限于简单任务，对于复杂任务人们很难模拟并自动化评估 由于复杂性，大多数产品不使用自动评估方法，而是通过研究员/工程师的自主洞见，或者设计信号（Signal），进行A/B实验来判断模

LLM并非一台计算机，LLM目前只是一个处理器，人们通常将记忆、RAG等外置存储手段作为内存看待，但实际上，只有Context才能被看做内存，而这些外挂的存储手段，可以看作是一种“虚拟内存”，LLM通过工具调用或者工程师通过工程化的手段进行“换页”，人们将此称为Context Engineering。 我之前介绍过工程上的Context Engineering策略，而LLM进行工具调用的方式，目前

LLM是没有时间概念的我想起人们让Deepseek深度思考三秒后给出答案，Deepseek真的考虑一下什么是三秒，以及如何思考三秒。或许这就是肉身人类与硅基生命的区别。 时间是人类最重要的幻觉认识到时间对于自己的重要性，是认识到自身意义的开始。 如果一个人一直按部就班地活着，时间对他来说是最不值钱的，相比之下，不被破坏的规律是他最重要的东西。 但某一天，突然发现，一个人的人生之所以不同，就是因为每

最近我又开始可以发呆了。 高考结束之后，人生仿佛按下了快进键，在大学卷，在实习卷，在工作卷，只有付出努力才能获得回报。 不论是在地铁、出游、还是在家里，我都在思考，思考着课程、作业、工作内容、架构设计、赚了多少钱，对比着自己和别人的生活，叹息着自己的生活不如意，于是又催促自己再加把劲。 或许我就是这样失去了发呆的能力。 我曾经认为，发呆是灵感的来源，是快速休息的方式，我总会在课堂上、公交车上、地铁

这是一篇随笔，在思考人类应该如何利用LLM的时候，我意识到杠杆效应是一个很好的思考角度。 工具杠杆从工具杠杆的角度上看，LLM是一个很平均的工具，在不对其进行微调的时候，人们总能通过chatbot提升自己的效率，但由于单纯聊天产生的价值不高，人们需要通过高价值的劳动行为来提升杠杆率。 目前得到验证的工具杠杆是Coding，在上一个时代（互联网时代）已经验证过，代码可以不间断的运行并带来价值，其边际

我曾在之前的文章中讨论过AI产品需要更端到端的设计来帮助用户发挥Agent智能，在目前来看，暴露错误是一个很好的让用户学习、同时进一步发挥模型智能的方式。 在传统的产品设计中，人们总是倾向于所谓的简洁，将一切复杂的原理藏在产品后面，让用户能够下意识的完成操作，人们总是假设用户无法理解产品背后的运行逻辑，不具备或不愿意花时间理解产品的技术细节。但在AI时代，每个人都需要通过表达来创造自己想要的东西，