有些结果落下来时，并不会立刻把人击中。
最先收紧的，往往不是事实本身，而是呼吸、判断，以及看待自己的方式。
后面我才慢慢意识到，这段时间真正反复回响的，并不只是一次失败，还有被它重新唤醒的另一种旧声音：恐惧。
失败把我拉回现实，让我承认差距确实存在；恐惧却总想把我从现实里拽走，在很多事情还没开始之前，就先一步占领身体和情绪。
所以回头看，这段时间更像是在同时面对两门课。
一门课，是承认失败不是对整个人的否定，而是对当前能力边界的一次校准。
一门课，是学会在心里发颤的时候，依然不把自己交给退缩，而是继续往前走一点。
SKILL.md 格式了：5 种更值得关注的 Agent Skill 设计模式当越来越多 Agent 工具开始支持相似的 Skill 组织方式后，很多开发者仍然把注意力放在“外壳”上：
SKILL.md 怎么写references/、assets/ 目录怎么摆这些当然重要，但它们解决的，本质上只是封装格式的问题。
真正决定一个 Skill 是否好用、是否稳定、是否能复用的，往往不是它“长什么样”，而是它内部的能力结构怎么设计。
这也是 Google Cloud Tech 那篇《5 Agent Skill design patterns every ADK developer should know》真正值得看的地方：
当 Skill 的包装格式逐渐标准化之后，真正拉开差距的，不再是会不会写 Skill 文件，而是会不会设计 Skill 的内容。
文章总结了 5 种反复出现的 Skill 设计模式：
它们不是五个零散技巧，而更像五种常见的 Agent 能力组织方式。
本来想回顾下25年的，但这一切衔接的太快了。而我也没有好好给自己留出时间。
那就顺带着3月相关的结果尘埃落定，再来抽出时间完成吧。
日复一日，时复一年，岁月就这样匆匆流逝……就这样逃亡着，它改变了整个世界。
它既不休息，也不停留，更不会折返。直到最终将你化为了一粒微尘。
第一次读到的时候，有一瞬间没明白自己被什么触动了。
后来想，大概是"微尘"这个词。
不是某种诗意的消逝，而是字面意义上的——被抹去，不被记得，连痕迹都没有留下。
这种恐惧我平时不太说出来，但它是真实存在的。
这两个月，时间加速的感觉不是比喻。
没有喘息的余地去问"我在哪里"，因为一停下来，已经又被推着走出去很远了。
推特永远有读不完的内容，永远有一种"你在落后"的低鸣。
我知道这种焦虑本质上是对不确定性的应激，但知道归知道，感受是另一回事。
“如果要 90 分的结果，那么就需要要付出 120 分的努力。”
听起来还有很多的事情还要做。
12 月对我来说，并不是发生了什么巨大转折的一个月。
更多的时候，它像是一个需要被收尾的节点。
就像这一年里的很多事情已经发生过、推进过，也在当下留下了结果和感受。
与其急着从中提炼结论、寻找答案，我更需要先做的一件事，是如实地把它们交代清楚。
对我来说，每个月抽出时间来进行总结，在这个阶段的意义并不在于给未来下判断，也不是为变化找理由，
而是让已经发生的事情有一个清晰的位置——
什么是用来交代过去的，什么是用来记录现实的，什么是需要单独拆出来、面向未来慢慢重建的。
当一些问题被清楚地记录下来，而不是反复被带入现在，它们才真正成为“过去”。
随着大语言模型在各个领域的应用越来越广泛，如何让 AI Agent 更好地完成特定领域的专业任务成为了一个重要课题。Anthropic 推出的 Agent Skills 提供了一个优雅的解决方案——通过标准化的技能包（Skill），让 Claude 能够动态加载专业指令和资源，从而在特定任务上表现得更加专业和一致。
本文将深入介绍 Anthropic 的 Skills 项目，帮助你理解其核心价值、技术架构和实际应用。
技术准确性声明：本文中所有关键技术细节（Progressive Disclosure、高效脚本执行、环境隔离等）均基于 Anthropic 官方文档验证，包括： - Agent Skills API Guide - Agent Skills Overview - Anthropic Engineering Blog - Agent Skills
文中涉及官方文档的部分均以引用块标注，确保信息的准确性和可追溯性。
Anthropic 的 Agent Skills 提供了一套优雅的专业技能管理方案，但最初它是 Claude 专属特性。随着社区的发展，现在有多种方案让其他 AI 编程工具（Cursor、Windsurf、Aider 等）也能使用 Skills，甚至在 LangChain、LlamaIndex 等框架中实现类似的 Skills 模式。
本文将介绍三种跨平台 Skills 实践方案，从开箱即用到深度定制，以及在实战中创建和迭代 Skills 的最佳工作流。
前置阅读：建议先阅读 Anthropic Agent Skills 完整指南 了解 Skills 的核心概念和技术架构。
如何构建一个真正能在开发流程中派上用场的 CodeAgent？不是那种回答一次就结束的代码问答机器人，而是能够理解任务、拆解步骤、操作文件、运行测试、并在遇到问题时自主调整的开发助手。
这个问题看似简单，实际落地时却会遇到大量工程细节：Agent 的状态如何建模？工具该怎么设计才能让模型稳定调用？上下文窗口有限的情况下如何让 Agent "看到"足够的信息？当 Agent 的一次操作出错时，系统该如何恢复？
这篇文章试图分享我们在这个过程中积累的一些经验。技术选型上，我们使用的是 LangGraph 和 LangChain 1.0，配合 Textual TUI 和 MCP 工具协议。但我们更希望讨论的是设计思路本身——这些思路在其他框架和工具链下同样适用。
这段时间在复盘一些事情的时候，发现自己经常会陷入两种归因：
一种是过于简单的叙事，比如“我就是不行”“对方太过分了”。
另一种是太绝对的结论，听上去很有道理，但对下一步该怎么做没什么帮助。
后来我开始有意识地问自己：
同样一件事，有没有一种归因方式，既能更接近真实的根因，又能指导我接下来该怎么做？
摘要： 本文提出了一种“N-Fold 稳定性优先”的评测框架。它通过 N 次重复实验，引入标准差 (StdDev) 和案例稳定性 (Case Stability Rate) 两个核心指标，帮助团队科学地量化和剥离 AI 模型的输出随机性，从而准确定位“稳定失败”的案例，实现可控、可迭代的工程优化。
随着经历的增加，我开始学会用“概括”来看待事情。
它带来一种清晰感——好像能用一句话，把复杂的经历和情绪都装进去。
可慢慢地，我发现这种清晰，其实是一种幻觉。
概括让我们以为理解了，
但更多时候，它会让我失去继续思考，也忽略当下的情况。
那些被我总结过的道理，总是很难带入当下的场景和体验。
它们像是事后才出现的反应，
到了需要它们的时候，它们往往像失去了声音一般。
总是误以为自己通过概括获得了理解， 实际上却失去了理解的细节。
真正的理解，也许不是提炼出一句话，
而是回到那件具体的事情里，重新感受当时的自己。
不急着下结论，不急着解释，
只是去看——那一刻我究竟在想什么，又是怎么走到这里的。
现实就是这样，不断地为我纠正，以前认为最糟糕的时刻还并不是最糟糕的。
这将近一个半月的时间，应该是今年平均表现最差和最为混乱失衡的一个周期，是投入“个人时间”上最少的周期。
各种不好的现象和习惯都让我变得不太像之前的“自己”，能感受到自己的生命力在一点点流失。
仅仅是维持好正常的状态和表现，就已经变得异常艰难。
很多事情，很多自己，很多想要看清的思想和感情，很多想要得到的问题和答案，力不从心。就这样安慰自己。
7月对于我来说更多就像是一个朦胧的梦境，偶尔想不起自己所做的事
弥漫着的大雾让我难以看清，随着我身体和精神上的惯性行走着
时好时坏，时而美丽又时而邪恶，面对无法稳定的自己会感到麻木
状态的起伏也如玻璃一般，积攒着，忍耐着，然后在某个受力点，全部破碎
我想，那既然这样，那索性随着惯性继续吧，让一切自然发生，要尽量照顾好自己
当每个人提到自己的焦虑和压力时，所体验到的份量：
或许大到能把人推进暗黑深渊而无法自拔，又或许小到也只是随意闪过的念想。
就是这样越简单的情绪描述，往往也是越难以控制和抗争的对象。
这两个月对我来说印象和感受最深的，就是焦虑和压力，而与之伴随的生活也总是被打乱和折磨。
我想，当一切秩序被打破，当所有精神被摧毁，残存下来的我会变成什么样子。
定义：一种基于 LLM 的系统，能够独立执行复杂任务，代替用户完成工作流程。
特点：
区别：