欢迎来到我的博客！这里是我记录编程世界旅程的开始 🎉

本博客的目的

在这个博客中，我将记录我的课程学习记录，展示我的项目，并分享我在编程过程中个人的反思。我的目标是创造一个供学习和分享知识的空间，与同样热爱编程的朋友们交流。

期待的内容

• 学习记录 🗒️: 来自我课程的笔记和见解。
• 项目展示 💻: 对我个人项目及其开发过程的详细介绍。
• 个人反思 📓: 在我编程旅程中所学到的思想和经验。

陈若尘

• 邮箱: [email protected]
• 电话: +86 13738337771
• 位置: 上海

---

教育背景

信息技术硕士，计算方向
墨尔本大学
2024年2月 - 2025年12月
相关课程: 编程与软件开发，计算机网络，数据结构与算法，数据库系统，分布式系统，集群与云计算，声明式编程，机器学习，软件过程与管理，信息可视化

大模型（包括 Claude Agent、所有LLM）的最大上下文长度，核心就是：Transformer 架构的「注意力机制」决定物理上限，再由训练+工程锁死实际可用长度。

---

一、最核心：为什么是「架构」决定上限？

所有现代大模型都是 Transformer，关键模块：

1. 自注意力 Self-Attention（致命关键）

注意力的本质：

序列里每一个字（token），都要和前面所有字做一次计算、关联、理解

三大底层基石

• MCP 协议：Anthropic 2024 年底牵头制定的 Agent 工具标准，类似 “USB 接口”，实现工具代码跨框架复用。2026 年 10 个主流框架中 8 个原生支持，工具生态壁垒基本消失，工具数量不再是选型核心考量。
• A2A 协议：Google 2025 年推出的 Agent 间通信标准，类似 “普通话”，解决跨框架 Agent 协作问题。大厂框架（微软、Google SDK、阿里 AgentScope）原生支持，CrewAI、LangGraph 等依赖社区插件，普及速度较 MCP 慢，但互操作是必然趋势。
• 上下文工程（Context Engineering）：2025 年行业共识，通过管理大模型 “内存条” 信息（质量、结构）提升性能，推动框架在记忆压缩、上下文过滤、动态工具选择等底层创新。

PE和PB是啥

1. GAAP净利润（Net Income）

是什么：按照**美国公认会计原则（GAAP）**算出来的、公司最终赚的“账面纯利润”。

• 它是利润表的“底线”，公式： 净利润 = 总收入 - 所有成本、费用、税费、利息、折旧摊销等
• 特点：非常严谨、标准化，包含所有一次性/非经常性损益（比如资产减值、政府补贴、重组费用），是最合规、最能反映公司整体账面盈利情况的数字。
• 注意：有时候公司会用“非GAAP净利润”剔除一些费用来美化业绩，GAAP净利润是监管认可的“官方版本”。

行业内部也似乎正在形成一种新的共识：决定 AI 编程上限的，不再是模型本身的单次生成能力，而是 Harness Engineering。

在 Anthropic 最近的工程文章展示了他们对 Long-running Agent（长时运行智能体）的深度探索。为了解决 AI 在长时间任务中“脱轨”的问题，他们构建了一套极其严密的 Harness：

• 结构化交接（Structured Handoff）：强制 AI 在上下文耗尽前生成“进度文件”，将状态外置。
• 多智能体协作：引入 Planner（规划器）、Generator（生成器）、Evaluator（评估器）分工。
• 上下文重置机制：为了避免“上下文焦虑”，直接清空对话历史，仅保留结构化产物，给新智能体一张“白板”。

提升森林算法（Boosted Forest / Gradient Boosting Decision Trees, GBDT），是集成学习（Ensemble Learning）的一种，核心思想是串行训练多棵决策树，每棵树都专注于修正前面所有树的预测误差，最终将所有树的结果加权累加，得到极强的预测能力。 它是目前结构化/表格数据（非图像、非文本）领域精度最高、工业界最常用的算法。

---

一、核心原理（通俗版）

假设你要猜一个人的年龄：

用途：面向分享与复习。本文主线按「Learn Claude Code」课程的四阶段、十九步来讲清 Claude Code 作为一类 Code Agent 的本质；泄露事件与工程深挖仅作补充。
说明：正文不夹带网址；需要延伸阅读与引用时，见文末「附录：链接索引」。材料性质（官方文档 / 社区解读 / 个人笔记）分享时需口头区分，产品行为以 Anthropic 官方为准。

---

最想先讲清楚的：Claude Code 是什么

（下文基于公开技术梳理；产品名以官方为准。）

概述

上下文管理是工程含量很高的子系统：约 15 个文件、15000+ 行代码，多来自生产踩坑与修补。

曾暴露的问题（量级）：例如 1279 个会话出现 50+ 次连续自动压缩失败，单次最多约 3272 次；由此导致全区每天约 25 万 次无效 API 调用。修复思路：连续失败超过 3 次则停止重试，避免空转。