AI
The Hot Mess of AI: How Does Misalignment Scale With Model Intelligence and Task Complexity? from Anthropic
2026 Agentic Coding Trends Report by anthropic
Unrolling the Codex agent loop
Evaluating Deep Agents: Our Learnings from langchain
State of Agent Engineering by langchain
姚顺雨在腾讯首个研究：Context Learning Benchmark Context Learning Benchmark https://arxiv.org/abs/2602.03587 结合后面提到的“AGENTS.md outperforms skills in our agent evals”一起看就有意思了
How AI Impacts Skill Formation 过分依赖人工智能完成不熟悉任务的新手工作者可能会在这个过程中牺牲自己的技能获取
Radar Trends to Watch: January 2026
Claude Code / Codex / Gemini CLI 全方位辅助工具 *****
AGENTS.md outperforms skills in our agent evals **** 我们在注入的内容里加了一条关键指令。 “IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning for any Next.js tasks.”
Inside OpenAI’s in-house data agent
Demystifying evals for AI agents 揭开 AI agent 评估的神秘面纱
- 对话式 AI agent 的成功标准可以是多维度的：工单是否解决（状态检查）、对话是否在十轮以内完成（对话轮次限制）、语气是否恰当（基于 LLM 的评估准则）。𝜏-Bench 及其后继版本 τ2-Bench 就是两个融入了多维评估的基准测试。它们模拟了零售客服、机票预订等领域的多轮交互场景，其中一个模型扮演用户角色，而 AI agent 则需要在贴近现实的场景中完成导航与应对。
- pass@k 度量的是 agent 在 k 次尝试中至少获得一个正确解决方案的可能性。随着 k 的增加，pass@k 分数也会上升——更多的 “尝试” 意味着至少一次成功的概率更高。50% 的 pass@1 分数意味着模型在评估的第一轮尝试中成功完成了半数任务。在编码中，我们通常最感兴趣的是 agent 能够在第一次尝试中找到解决方案——即 pass@1。在其他情况下，只要其中一个解决方案有效，即使提出多个解决方案也是有效的。
- pass^k 度量所有 k 次试验都成功的概率。随着 k 的增加，pass^k 会下降，因为要求在更多试验中保持一致性是一个更高的标准。如果你的 agent 每次试验的成功率为 75%，你运行 3 次试验，那么所有三次都成功的概率为 (0.75)³ ≈ 42%。这个指标尤其重要对于面向客户的 agent，因为用户每次都期望可靠的行为。
- 从开发过程中你手动执行的检查开始——也就是每次发布前你验证的行为，以及终端用户常做的操作。如果你已上线，就查看你的缺陷追踪系统和支持工单。将用户报告的故障转化为测试用例，能确保你的测试套件真实反映实际使用场景；而根据用户影响程度优先排序，则能让你把精力投入到最关键的地方。
- 把任务质量做对，比看上去难。一条好任务，得让两位领域专家各自独立地给出通过/不通过，结论还得一致。他们自己能完成吗？若不能，任务就得再打磨。任务说明里但凡有一点含糊，指标里就多一分噪声。这条原则同样适用于给模型打分：模糊的评分标准，只会带来摇摆不定的判断。
- 既要测试行为应当触发的场景，也要测试它不该触发的场景。单向的 eval 只会带来单向的优化。比如，如果只验证 agent 在“该搜索”时是否搜索，结果可能是一个几乎什么都搜的 agent。尽量避免类别失衡的 eval。 我们在为 Claude.ai 构建网页搜索 eval 时，亲身领教了这一点。难题在于：既要阻止模型在不该搜索时乱搜，又要保留它在需要时做深入调研的能力。团队于是把 eval 做成双向：一类 query 要求模型必须搜索（例如查天气），另一类则让它直接凭已有知识回答（例如“谁创立了 Apple？”）。在“漏触发”（该搜不搜）和“过触发”（不该搜却搜）之间找到平衡并不容易，prompt 和 eval 都迭代了好几轮。随着新问题不断出现，我们仍在持续补充 eval，好让覆盖面更完整。
- 评估时用的 agent 必须与线上那版大致相同，环境本身也不能再添噪声。每次试验都从干净环境起步，才算“隔离”。若运行之间残留共享状态——遗留文件、缓存数据、资源耗尽——基础设施的抖动就会带来关联性失败，让人误以为是 agent 的问题。共享状态还可能把成绩虚高。比如，我们内部某次评估里，Claude 靠查看前几次试验留下的 git 记录，在某些任务上占了便宜。如果多轮不同试验因同一环境限制（如 CPU 内存不足）而失败，它们就不再独立，评估结果也就无法可靠衡量 agent 的真实表现。
- 优秀的评估设计，关键在于为 AI agent 和具体任务挑选最合适的评分者。我们建议：能用确定性评分器的地方，优先使用；必要时或需要更大灵活性时，引入 LLM 评分器；而人工评分则应谨慎使用，仅作为额外的验证手段。
- 人们常有一种直觉，希望检查 agent 是否严格遵循了预设的步骤——比如按特定顺序调用工具。但我们发现，这种做法过于僵化，容易导致评估体系脆弱不堪，因为 agent 经常会提出评估设计者未曾预料到的合理路径。为了避免扼杀创造力，通常更优的做法是：评分应聚焦于 agent 最终产出的结果，而非它走过的路径。
- 对于包含多个环节的任务，应设置部分得分机制。一个能准确识别问题并核实客户身份、只是未能处理退款的客服代理，显然比一上来就失败的代理要好得多。重要的是，结果中应当体现这种渐进式的成功连续体。
- 模型评分往往需要经过细致的迭代才能验证其准确性。以 LLM 为评判者的评分系统，应与人类专家紧密校准，以确保人类评分与模型评分之间差异极小。为避免幻觉，可为 LLM 设置退路，例如指令其在信息不足时返回“Unknown”。此外，制定清晰、结构化的评分标准，分别评估任务的每个维度，并用独立的 LLM 评判者逐项打分，而非用同一个 LLM 评估全部维度，也会有所帮助。待系统稳定后，仅需偶尔进行人工复核即可。
- 除非你亲自阅读大量测试的评估记录和评分，否则无法判断评分标准是否有效。在 Anthropic，我们投入资源开发了查看评估记录的工具，并会定期花时间审阅这些记录。当任务失败时，记录会告诉你，究竟是 agent 犯了真正的错误，还是你的评分标准拒绝了一个有效的解决方案。同时，它也常常揭示出关于 agent 和评估行为的关键细节。
- 失败应当显得公允：能清楚地看出 agent 错在哪里、为何出错。当分数停滞不前时，我们需要确信这是源于 agent 的表现，而非评估本身的问题。阅读评估记录，正是你验证评估是否真正衡量了关键指标的方式，这也是 agent 开发过程中一项至关重要的技能。
- 一项达到 100% 的评估只能追踪性能衰退，却无法为改进提供信号。当 agent 通过了所有可解决的任务，没有留下任何提升空间时，评估就进入了饱和状态。例如，SWE-Bench Verified 的分数今年年初是 30%，而前沿模型现在已接近 80% 以上的饱和点。随着评估趋近饱和，进展也会放缓，因为只剩下最困难的任务。这可能导致结果具有欺骗性，因为巨大的能力提升可能只表现为分数上的微小增长。再比如，代码审查初创公司 Qodo 最初对 Opus 4.5 印象不深，因为他们的一次性编码评估未能捕捉到模型在更长、更复杂任务上的进步。为此，他们开发了一个新的 agentic 评估框架，从而更清晰地展现了进展。
- 我们的原则是，除非有人深入评估细节并阅读部分记录，否则不会轻信评估分数。如果评分不公、任务描述模糊、有效方案被罚、或者测试框架限制了模型发挥，那么这项评估就需要修订。
- 我们建议实践评估驱动开发（eval-driven development）：在 agent 能够实现某项能力之前，先构建评估来定义这项计划中的能力，然后持续迭代，直到 agent 表现良好。在内部，我们常常会开发一些当下“足够好用”的功能，但它们其实是对模型未来几个月能力的押注。从较低通过率开始的“能力评估”（capability evals）能让这一点变得清晰可见。当新模型发布时，运行整套评估能迅速揭示哪些押注获得了回报。
Programming
Vibe Engineering: What I’ve Learned Working with AI Coding Agents
- design.md # What we’re building and why ;
- plan.md # How we’re building it, in phases
Custom instructions with AGENTS.md Codex reads AGENTS.md files before doing any work. By layering global guidance with project-specific overrides, you can start each task with consistent expectations, no matter which repository you open.
Pi is a minimal terminal coding harness. Pi runs in four modes:
- interactive, print or JSON, RPC for process integration, and an SDK for embedding in your own apps. See openclaw/openclaw for a real-world SDK integration.
深度解析：Moltbot 底层架构 Agent Loop 的核心运行时环境被称为 Pi（源自 @mariozechner/pi-agent-core[5]）
qmd - mini cli search engine for your docs, knowledge bases, meeting notes, whatever
The 80% Problem in Agentic Coding
- 1，车更快了，路却更堵了,
- 2，早期采用者与众人之间的差距正在扩大，而非缩小。
- 3，新模式（声明式）：“这是需求。这是必须通过的测试。这是成功标准。你自己想办法。” 4，
Automate Development Tasks with goose Headless Mode
The Rise of Coding Agent Orchestrators
Nanobot: Ultra-Lightweight Alternative to OpenClaw
3天5k+星标，港大开源极致轻量OpenClaw, 1%代码量打造个人专属贾维斯
Others
European Transparent IT JOB Market Report 2025
《康熙的红票》作者最新力作，讲述康熙朝储位之争的新故事｜豆瓣一周新书精选
Breaking Down the Shocking Ending of Fallout Season 2 time没有paywall了
把东西“翻译成数字” → 让机器试着算答案 → 根据算错的地方反过来改参数。
Encoding（编码）：把现实世界的东西变成机器能算的数字。Decoding（解码）：把机器算出来的数字再变回人能理解的结果。反向传播（Backpropagation）：发现算错了，从结果倒推，逐层修正内部参数。神经网络做的事情很朴素：一层一层做：加权求和 + 非线性变化。反向传播（Backpropagation）：错了怎么办？
先说“正向”，训练时流程是：输入 → Encoding → 网络计算 → 输出 → 和标准答案比。关键问题：到底是哪一层、哪个参数，导致我认错了？直接答案：不知道，只能从后往前一点点算。就是“反向传播”，反向传播 = 甩锅大会。
流程：先算“我错得有多离谱”（loss）,从最后一层开始问：“你对这个错误负多少责任？”，把责任一点点往前传。
每个参数：往“让错误变小”的方向微调一点点。一个极简比喻，你在练投篮：投偏了，你不会“全部推倒重来”，而是：手抬高一点，力气小一点。反向传播就是告诉你：哪个“动作”该怎么微调。
不管多复杂，最小深度学习程序一定包含这 5 个部分：1. 数据（Data）2. 编码（Encoding）3. 模型（Model）4. 损失函数（Loss）5. 反向更新（Backprop + Update）
for 每一次训练:
x = encode(输入)
y_pred = model(x)
loss = compare(y_pred, y_true)
根据 loss 反向调整 model 参数
最简单的损失函数：平方误差，loss = (预测值 - 正确值)^2
我们用一个“极简版反向传播”：
w = w - 学习率 * 梯度
b = b - 学习率 * 梯度
你现在不需要理解数学细节，只记住一句话：反向传播 = 算“该往哪个方向调参数，调多少”
把一切连起来（训练循环）
import random
# 生成训练数据
data = []
for _ in range(100):
x = random.uniform(0, 10)
y = 1 if x > 5 else 0 # 人工规则
data.append((x, y))
def encode(x):
return x
def model(x):
return w * x + b
def decode(y):
return 1 if y > 5 else 0
def loss_fn(y_pred, y_true):
return (y_pred - y_true) ** 2
lr = 0.01 # 学习率
def backward(x, y_pred, y_true):
global w, b
grad = 2 * (y_pred - y_true)
w -= lr * grad * x
b -= lr * grad
for epoch in range(50):
total_loss = 0
for x, y in data:
x_enc = encode(x)
y_pred = model(x_enc)
loss = loss_fn(y_pred, y)
backward(x_enc, y_pred, y)
total_loss += loss
print(f"epoch {epoch}, loss {total_loss:.2f}")
那 PyTorch / TensorFlow 干了什么？一句话：帮你自动写了 backward()。
现实模型：参数成千上万，梯度人算不可能
PyTorch 的核心价值只有一个：
loss.backward()
optimizer.step()
你刚才“手搓”的逻辑，它帮你自动化了。