<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <author>
    <name>finisky</name>
  </author>
  <generator uri="https://hexo.io/">Hexo</generator>
  <icon>https://finisky.github.io/icon.png</icon>
  <id>https://finisky.github.io/</id>
  <link href="https://finisky.github.io/" rel="alternate"/>
  <link href="https://finisky.github.io/atom.xml" rel="self"/>
  <rights>All rights reserved 2026, finisky</rights>
  <subtitle>NLP, 软件工程, 产品设计</subtitle>
  <title>Finisky Garden</title>
  <updated>2026-04-09T10:36:07.000Z</updated>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/prompt-context-harness-engineering/</id>
    <link href="https://finisky.github.io/en/prompt-context-harness-engineering/"/>
    <published>2026-04-08T16:19:33.000Z</published>
    <summary>
      <![CDATA[<p>Last June, Shopify CEO Tobi Lutke posted that he preferred "context
engineering" over "prompt engineering." Karpathy retweeted with a +1.
Simon Willison wrote a blog post saying the term might actually stick.
Phil Schmid published a full definition. Half the AI community switched
terminology within a week.</p>
<p>By early 2026, Phil Schmid introduced another term: Agent Harness. It
didn't generate the same buzz, but anyone building Coding Agents quietly
nodded along.</p>]]>
    </summary>
    <title>Three Evolutions of Agent Engineering</title>
    <updated>2026-04-09T10:36:07.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/prompt-context-harness-engineering/</id>
    <link href="https://finisky.github.io/prompt-context-harness-engineering/"/>
    <published>2026-04-08T16:15:33.000Z</published>
    <summary>
      <![CDATA[<p>去年 6 月 Shopify CEO Tobi Lutke 发了条推，说他觉得 context
engineering 比 prompt engineering 好。Karpathy 转发 +1。Simon Willison
写了篇博客说这个词可能真能立住。Phil Schmid 做了完整定义。半个 AI
圈在一周之内集体换了术语。</p>
<p>到了 2026 年初，Phil Schmid 又抛了一个新词：Agent
Harness。这次没有上一轮那么热闹，但写 Coding Agent
的人几乎都默默点了头。</p>]]>
    </summary>
    <title>Agent 工程的三次进化</title>
    <updated>2026-04-09T10:36:07.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/openclaw-vs-claude-code-agent-arch/</id>
    <link href="https://finisky.github.io/en/openclaw-vs-claude-code-agent-arch/"/>
    <published>2026-04-07T15:49:33.000Z</published>
    <summary>
      <![CDATA[<p>After OpenClaw crossed 350K stars, a narrative started forming in the
community: since both run on Opus 4.6 under the hood, the open-source
option should be on par with Claude Code. Anyone who has actually used
both probably shares the same observation — in long sessions, OpenClaw
starts losing context, forgetting files it already read, redoing work it
already did. Claude Code does too, but noticeably later, and it recovers
much better.</p>
<p>Same model, different experience. Why?</p>]]>
    </summary>
    <title>Context Management in Claude Code vs OpenClaw</title>
    <updated>2026-04-07T15:54:16.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/openclaw-vs-claude-code-agent-arch/</id>
    <link href="https://finisky.github.io/openclaw-vs-claude-code-agent-arch/"/>
    <published>2026-04-07T14:15:33.000Z</published>
    <summary>
      <![CDATA[<p>OpenClaw 拿下 35 万 Star 之后，社区开始出现一种论调：底层都是 Opus
4.6，开源方案应该能对标 Claude
Code。实际用过两边的人大概都有同一个感受，长会话跑到后半段，OpenClaw
开始丢上下文，忘记之前读过的文件，重复做已经做过的事。Claude Code
也会，但明显晚得多，而且恢复能力强很多。</p>
<p>模型一样，体验不一样。差在哪？</p>]]>
    </summary>
    <title>Claude Code 和 OpenClaw 的上下文管理对比</title>
    <updated>2026-04-07T15:54:16.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/foundation-model-plateau-application-era/</id>
    <link href="https://finisky.github.io/en/foundation-model-plateau-application-era/"/>
    <published>2026-04-06T16:21:45.000Z</published>
    <summary>
      <![CDATA[<p>Cursor's parent company Anysphere has about 150 employees. In
November 2025, its <a
href="https://e.vnexpress.net/news/tech/personalities/4-mit-graduates-who-built-the-popular-ai-coding-tool-cursor-become-billionaires-4965462.html">ARR
crossed $1 billion</a>. OpenAI, as of early 2026, has <a
href="https://www.ft.com/content/7ffea5b4-e8bc-47cd-adb4-257f84c8028b">4,500
employees</a>. Its 2025 revenue was $13.1 billion, but according to
Fortune, it <a
href="https://fortune.com/2025/11/12/openai-cash-burn-rate-annual-losses-2028-profitable-2030-financial-documents/">lost
roughly $9 billion</a> and doesn't expect to turn profitable until
2028.</p>
<p>An application company that trains zero models is outproducing, per
capita, the company that trains them. This is the most telling signal in
AI for 2025.</p>]]>
    </summary>
    <title>Foundation Models Plateau, Applications Take Off</title>
    <updated>2026-04-06T16:40:41.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/foundation-model-plateau-application-era/</id>
    <link href="https://finisky.github.io/foundation-model-plateau-application-era/"/>
    <published>2026-04-06T16:16:45.000Z</published>
    <summary>
      <![CDATA[<p>Cursor 的母公司 Anysphere 大概 150 人，2025 年 11 月<a
href="https://e.vnexpress.net/news/tech/personalities/4-mit-graduates-who-built-the-popular-ai-coding-tool-cursor-become-billionaires-4965462.html">年收入突破
10 亿美元</a>。OpenAI 到 2026 年初有 <a
href="https://www.ft.com/content/7ffea5b4-e8bc-47cd-adb4-257f84c8028b">4500
名员工</a>，2025 年收入 131 亿美元，但据 Fortune 报道，<a
href="https://fortune.com/2025/11/12/openai-cash-burn-rate-annual-losses-2028-profitable-2030-financial-documents/">亏损约
90 亿美元</a>，而且预计一直亏到 2028 年。</p>
<p>一个不训练任何模型的应用公司，人均产出碾压了训练模型的公司。这组数字是
2025 年 AI 行业最值得琢磨的信号。</p>]]>
    </summary>
    <title>基模到顶，应用起飞</title>
    <updated>2026-04-06T16:40:41.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="Product" scheme="https://finisky.github.io/categories/Product/"/>
    <category term="Product" scheme="https://finisky.github.io/tags/Product/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="Software Engineering" scheme="https://finisky.github.io/tags/Software-Engineering/"/>
    <id>https://finisky.github.io/en/openclaw-why-viral/</id>
    <link href="https://finisky.github.io/en/openclaw-why-viral/"/>
    <published>2026-04-05T16:16:37.000Z</published>
    <summary>
      <![CDATA[<p>In late November 2025, an open-source project called OpenClaw went
live on GitHub. Four and a half months later, it had 350K stars, 70K
forks, 81 releases, and sponsorships from OpenAI, NVIDIA, and Vercel.
For comparison: Open WebUI took two and a half years to reach 130K
stars; NextChat took three years to hit 88K. Growth like OpenClaw's is
rare in GitHub's history.</p>
<p>It isn't a new model, a training framework, or even a "technical
breakthrough" in the traditional sense. It's a personal AI assistant
that runs on your own machine and talks to you through the chat apps you
already use: WhatsApp, Telegram, Slack, Discord, WeChat, Feishu,
iMessage, Matrix, and over 25 platforms in total, all connected to a
single backend.</p>
<p>Why did it break out of the developer bubble?</p>]]>
    </summary>
    <title>How OpenClaw Hit 350K Stars in 4 Months</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="Product" scheme="https://finisky.github.io/categories/Product/"/>
    <category term="Product" scheme="https://finisky.github.io/tags/Product/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="Software Engineering" scheme="https://finisky.github.io/tags/Software-Engineering/"/>
    <id>https://finisky.github.io/openclaw-why-viral/</id>
    <link href="https://finisky.github.io/openclaw-why-viral/"/>
    <published>2026-04-05T16:12:37.000Z</published>
    <summary>
      <![CDATA[<p>2025 年 11 月底，一个叫 OpenClaw 的开源项目在 GitHub 上线。4
个半月后，它有 35 万 Star，7 万 Fork，81
个发布版本，OpenAI、NVIDIA、Vercel 做它的赞助商。同期对比：Open WebUI
用了两年半才到 13 万，NextChat 三年到 8.8 万。OpenClaw 的增速在 GitHub
历史上都不多见。</p>
<p>它不是一个新模型，不是一个训练框架，甚至不是一个传统意义上的"技术突破"。它是一个个人
AI
助手，跑在你自己的机器上，通过你已经在用的聊天工具跟你对话。WhatsApp、Telegram、Slack、Discord、微信、飞书、iMessage、Matrix，25
个以上的平台，同时接入，一个后台。</p>
<p>这篇聊聊它为什么能出圈。</p>]]>
    </summary>
    <title>OpenClaw 为什么能 4 个月拿下 35 万 Star</title>
    <updated>2026-04-05T16:32:48.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-deferred-tools/</id>
    <link href="https://finisky.github.io/en/claude-code-deferred-tools/"/>
    <published>2026-04-05T13:37:24.000Z</published>
    <summary>
      <![CDATA[<p>When you use Claude Code, there's something you probably never
notice: it has over 40 registered tools, but when you ask it to read a
file or edit a few lines of code, it only uses three or four. The
definitions for the remaining 30-plus tools, each around 500 tokens, add
up to over 10,000 tokens of fixed overhead per request. You just want to
change one line of CSS, but you're paying for WebSearch, NotebookEdit,
CronCreate, and a bunch of tools you'll never touch.</p>]]>
    </summary>
    <title>Deferred Tool Loading in Claude Code</title>
    <updated>2026-04-09T03:09:38.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-deferred-tools/</id>
    <link href="https://finisky.github.io/claude-code-deferred-tools/"/>
    <published>2026-04-05T13:33:24.000Z</published>
    <summary>
      <![CDATA[<p>用 Claude Code 写代码的时候，你大概不会注意到一件事：它注册了超过 40
个工具，但你让它读个文件、改几行代码，它只用到三四个。剩下那三十多个工具的定义，每个大约
500 个 token，全塞进上下文就是一万多 token 的固定开销。你只想改一行
CSS，却要为 WebSearch、NotebookEdit、CronCreate
这些完全用不到的工具买单。</p>]]>
    </summary>
    <title>Claude Code 的工具按需加载</title>
    <updated>2026-04-09T03:09:38.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-edit-tool/</id>
    <link href="https://finisky.github.io/en/claude-code-edit-tool/"/>
    <published>2026-04-05T13:21:51.000Z</published>
    <summary>
      <![CDATA[<p>Claude Code's Edit tool has a deceptively simple interface: give it
an old_string, give it a new_string, and it finds the former in a file
and replaces it with the latter. Sounds like nothing more than a
<code>str.replace()</code>. But in the context of an LLM Agent, this
seemingly trivial operation is backed by an entire engineering pipeline
spanning string sanitization to concurrency safety. The model stuffs
line numbers into its replacement strings. It conjures curly quotes out
of thin air. External tools modify the target file while the user is
still reviewing the permission dialog. The Edit tool has to stay correct
through all of this — far more than find-and-replace can handle.</p>
<p>From observing its behavior, the Edit tool's execution breaks down
into three phases: API-layer preprocessing (before the tool even
receives input), input validation (before the permission dialog is
shown), and the actual write (after the user approves). Each phase
handles a distinct class of problems and maintains deliberate sync/async
boundaries.</p>]]>
    </summary>
    <title>Why Claude Code's Edit Tool Doesn't Mangle Your Files</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-edit-tool/</id>
    <link href="https://finisky.github.io/claude-code-edit-tool/"/>
    <published>2026-04-05T13:17:51.000Z</published>
    <summary>
      <![CDATA[<p>Claude Code 的 Edit 工具接口极简: 给一个 old_string, 给一个
new_string, 在文件里找到前者替换成后者。听上去就是一个
<code>str.replace()</code> 的事。但在 LLM Agent 的语境下,
这个看似平凡的操作背后藏着一整套从字符串清洗到并发安全的工程。模型会把行号塞进替换字符串,
会凭空产生弯引号, 会在用户审批的间隙里被外部工具改了目标文件。Edit
工具要在这些情况下保持正确, 比 find-and-replace 复杂得多。</p>
<p>从行为上观察, Edit 工具的执行可以拆成三个阶段: API
层预处理(在工具拿到输入之前), 输入校验(展示权限对话框之前),
和实际写入(用户同意之后)。每个阶段各自处理一类问题,
且刻意保持了特定的同步/异步边界。</p>]]>
    </summary>
    <title>Claude Code 的 Edit 工具为什么不会改错文件</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-undercover/</id>
    <link href="https://finisky.github.io/en/claude-code-undercover/"/>
    <published>2026-04-05T13:06:08.000Z</published>
    <summary>
      <![CDATA[<p>Claude Code has a mode that appears in no documentation whatsoever.
When active, it systematically erases every trace of AI involvement. No
Co-Authored-By trailer, no "Generated with Claude Code" footer, and the
system prompt itself doesn't even tell the model what it is. This mode
is called <strong>Undercover Mode</strong>. It exists only in
Anthropic's internal builds; external users will never see it, because
dead code elimination strips the entire feature out during public
builds.</p>
<p>The behavioral implications are telling: this mechanism exists
because Anthropic employees routinely use Claude Code to commit to
public repositories. Without some form of protection, commit messages
might contain unreleased model codenames, PR descriptions might expose
internal project names, and model identifiers in the system prompt could
leak through some vector or another. Undercover Mode is designed to plug
all of these holes.</p>]]>
    </summary>
    <title>Claude Code's Undercover Mode: When AI Learns to Hide Itself</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-undercover/</id>
    <link href="https://finisky.github.io/claude-code-undercover/"/>
    <published>2026-04-05T13:02:08.000Z</published>
    <summary>
      <![CDATA[<p>Claude
Code有一个从未出现在任何文档中的模式,在这个模式下,它会系统性地抹除一切AI参与的痕迹。不写Co-Authored-By,不写Generated
with Claude Code的footer,甚至连system
prompt里都不告诉模型它自己是什么型号。这个模式叫<strong>Undercover
Mode</strong>,只存在于Anthropic内部构建版本中,外部用户永远看不到它,因为整个功能在公开构建时会被dead
code elimination彻底剔除。</p>
<p>从行为推断,这个机制的存在意味着Anthropic员工日常使用Claude
Code向公开仓库提交代码。如果没有某种保护措施,commit
message里可能出现未发布模型的代号,PR描述里可能暴露内部项目名称,system
prompt里的模型标识可能通过某种方式泄露。Undercover
Mode就是为了堵住这些口子。</p>]]>
    </summary>
    <title>Claude Code的Undercover Mode：当AI学会隐藏自己</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-fork-cache/</id>
    <link href="https://finisky.github.io/en/claude-code-fork-cache/"/>
    <published>2026-04-05T12:50:42.000Z</published>
    <summary>
      <![CDATA[<p>When tackling complex tasks, Claude Code spawns multiple sub-agents
in parallel, each of which needs the full parent conversation context to
do its job effectively. This creates a real cost problem: if the parent
conversation has accumulated 100K tokens of context and three sub-agents
are spawned simultaneously, a naive implementation would charge 100K
tokens of input for each one, 300K total. Anthropic's API offers a
<strong>Prompt Cache</strong> mechanism that gives a 90% discount on the
cached prefix portion, but only if the prefix bytes are exactly
identical across requests. From observable behavior, Claude Code's
forked sub-agents are carefully constructed so that over 99% of the
bytes are identical across all parallel forks, compressing the effective
input cost of three sub-agents to roughly 120K token-equivalent (100K at
full price + 2 × 100K × 10%).</p>]]>
    </summary>
    <title>How Claude Code's Forked Sub-Agents Share Prompt Cache</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-fork-cache/</id>
    <link href="https://finisky.github.io/claude-code-fork-cache/"/>
    <published>2026-04-05T12:46:42.000Z</published>
    <summary>
      <![CDATA[<p>Claude Code在执行复杂任务时会并行派生多个子agent,
每个子agent都需要完整的父对话上下文才能有效工作.
这带来一个现实的成本问题: 假设父对话积累了100K token的上下文,
并行派生3个子agent, 朴素实现需要为每个子agent支付100K token的输入费用,
合计300K. Anthropic API的<strong>Prompt
Cache</strong>机制对缓存命中的前缀部分提供90%的价格折扣,
但前提是多个请求之间的前缀字节完全一致. 从行为上观察, Claude
Code的fork子agent在构造API请求时做了精心设计,
使得所有并行子agent之间99%以上的字节完全相同,
从而将3个子agent的实际输入成本压缩到约120K token等价价格(100K全价 + 2 *
100K * 10%).</p>]]>
    </summary>
    <title>Claude Code Fork子Agent的Prompt Cache共享机制</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-context-compaction/</id>
    <link href="https://finisky.github.io/en/claude-code-context-compaction/"/>
    <published>2026-04-05T12:35:17.000Z</published>
    <summary>
      <![CDATA[<p>A 200K context window sounds generous — until you're in a moderately
complex coding session. Read a few dozen files, run several rounds of
grep, execute some bash commands, and you've already burned through most
of it. Compaction is inevitable, but compaction itself costs money: you
need an LLM call to generate a summary, and the input to that call is
the very context you're trying to compress. This creates a fascinating
engineering trade-off: compact too early and you lose useful
information; compact too late and the window overflows; and the cost of
compaction itself can't be ignored. Claude Code's answer is a
multi-layer cascade: avoid compaction if you can, do it cheaply if you
must, and only call the LLM as a last resort.</p>]]>
    </summary>
    <title>Context Compaction in Claude Code: A Five-Layer Cascade and the Art of Free Summaries</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-context-compaction/</id>
    <link href="https://finisky.github.io/claude-code-context-compaction/"/>
    <published>2026-04-05T12:31:17.000Z</published>
    <summary>
      <![CDATA[<p>200K context window 听起来很大, 但一个中等复杂度的编程 session,
读几十个文件, 跑几轮 grep, 执行一些 bash 命令, 就能轻松吃掉大半个窗口.
压缩是必须的, 但压缩本身又要花钱: 你需要一次 LLM 调用来生成摘要,
而这次调用的输入就是你要压缩的那整段上下文. 这形成了一个有趣的工程权衡:
压得太早浪费信息, 压得太晚窗口爆了, 压缩本身的成本也不能忽略. Claude
Code 对此给出的答案是一套多层级联系统: 能不压就不压, 能便宜压就便宜压,
实在不行才动用 LLM.</p>]]>
    </summary>
    <title>Claude Code 的上下文压缩:五层级联与免费摘要的艺术</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/en/claude-code-bash-security/</id>
    <link href="https://finisky.github.io/en/claude-code-bash-security/"/>
    <published>2026-04-05T12:19:33.000Z</published>
    <summary>
      <![CDATA[<blockquote>
<p>The security challenge of AI-executed Bash commands isn't "should we
trust the model" — it's "how do we make sure a command actually means
what it looks like."</p>
</blockquote>
<p>Claude Code lets AI execute Bash commands directly. Not through a
structured interface like MCP; it literally gives the model a shell.
MCP's approach wraps tools into JSON schemas, which is safe enough, but
you can't realistically write adapters for thousands of CLI tools. The
capability ceiling is obvious. A raw shell can do anything; the tradeoff
is that the security problem shifts from "controlling interface
permissions" to "figuring out what a command actually does." In the
previous post, I covered how YOLO Classifier uses AI to review AI, but
the Classifier works with the full command string and makes a semantic
judgment: is this operation dangerous? Before that judgment even
happens, there's a deeper question that needs answering: does this
command actually mean what it appears to mean?</p>]]>
    </summary>
    <title>How Claude Code Defends Against Bash Injection</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>finisky</name>
    </author>
    <category term="NLP" scheme="https://finisky.github.io/categories/NLP/"/>
    <category term="NLP" scheme="https://finisky.github.io/tags/NLP/"/>
    <category term="LLM" scheme="https://finisky.github.io/tags/LLM/"/>
    <category term="LLM Agent" scheme="https://finisky.github.io/tags/LLM-Agent/"/>
    <id>https://finisky.github.io/claude-code-bash-security/</id>
    <link href="https://finisky.github.io/claude-code-bash-security/"/>
    <published>2026-04-05T12:15:33.000Z</published>
    <summary>
      <![CDATA[<blockquote>
<p>AI 执行 Bash
命令的安全问题，不是"该不该信任模型"，而是"怎么确认命令的含义和它看起来的一样"。</p>
</blockquote>
<p>Claude Code 允许 AI 直接执行 Bash 命令。不是通过 MCP
那样的结构化接口间接调用，是真给模型开了一个 shell。MCP
的思路是把工具封装成 JSON schema，安全是安全了，但你不可能为几千个 CLI
工具逐个写 adapter，能力天花板肉眼可见。直接给
Bash，什么都能干，代价是安全问题从"接口权限控制"变成了"搞懂这条命令到底在干嘛"。上一篇聊了
YOLO Classifier 怎么用 AI 审查 AI，但 YOLO Classifier
看到的是完整的命令字符串，它做的是语义判断：这个操作危不危险。在那之前，还有一层更底层的问题需要回答：这个命令真的是它看起来的那个意思吗？</p>]]>
    </summary>
    <title>Claude Code 怎么防住 Bash 注入</title>
    <updated>2026-04-06T12:13:18.000Z</updated>
  </entry>
</feed>
