设计 Agent 系统提示词、上下文结构或按需加载的 Skill 时使用——覆盖 API 消息角色与「静态前缀 + 轨迹」结构、系统提示词写法（结构化、SOP、业务规则细化、few-shot）、Agent Skills 渐进式披露与 SKILL.md 编写、提示注入的上下文层防御，以及注意力位置偏好等布局原则。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
上下文是 Agent 在每个决策点实际「看到」的全部信息：系统提示词、工具定义、用户消息、模型回复、工具执行结果。上下文工程就是系统性设计、组织、供给这些信息——模型智力只是基础，上下文质量才是 Agent 能力的真正关键。一个中等能力的模型配上精心组织的上下文，往往胜过一个顶级模型在信息匮乏下的盲目摸索。
SKILL.md（元数据、路由描述、正文分层）tools 字段。 system（开发者规则，通常只有一条且在最前）、user（终端用户输入）、assistant（模型回复含 tool_calls）、tool（框架执行结果，靠 tool_call_id 与调用关联）；工具定义走请求顶层 tools 字段，不是消息角色。You MUST answer concisely with fewer than 4 lines；无法完成任务时 keep your response to 1-2 sentences 且不要解释为什么不能做。大写（NEVER do X）比 Please avoid doing X 更能引起注意，但过度使用会稀释效果，只留给真正关键的约束。#、##）提供人可读的层次，XML 标签提供机器可解析的精确语义（<file_operation>、<network_request>），标签名本身携带语义。双层配合：Markdown 管组织逻辑，XML 管语义边界。NEVER use percentage_based_one_time for refunds and service cancellations. Use fixed_fee instead.；成功率阈值直接映射到行为（>60% 可退款、<30% 拒绝任务）；计费粒度写死（每分钟 $0.05，汇总四舍五入到整数美元），并明确「节省」只基于现有账单计算。提示词由产品经理基于线上数据设计，工程师负责准确编码，不擅自决定业务逻辑。SKILL.md 顶部 YAML frontmatter 的 name + description，在正文加载前对 Agent 可见，用于路由判断。description 要写得像路由条件而非功能介绍：明确「何时使用」「何时不使用」的边界，给几条典型反例。写 help with backend 这种宽泛描述等于任何后端工作都能触发，路由必然失准。SKILL.md（斜杠命令由客户端本地拦截展开；模型自主触发则多一次 ReAct 往返，正文作为 user message 追加）。html2pptx.md、reference.md），Agent 按需选择性深入。stable_prefix = system_message # 定了就不改
stable_tools = core_tool_schemas # 固定顺序
trajectory = load_message_history(session)
status_message = make_status_message(derive_current_state(trajectory))
if estimated_tokens(stable_prefix, trajectory, status_message) > budget:
trajectory = compress_old_evidence(
trajectory, preserve=[decisions, constraints, failures, citations]
)
request.messages = [stable_prefix] + trajectory + [status_message]
request.tools = stable_tools
第一道防线是帮模型分清「指令」与「数据」：
<external_content source="webpage">...</external_content> 包裹并标注来源。kv-cache-design）。chapter1/context/ — 多 provider 上下文感知 Agent，消融实验 1-1 对比 full / no history / no reasoning / no tool calls / no tool results 五种上下文模式。chapter2/prompt-engineering/ — 实验 2-4：基于 Tau-Bench 的提示工程消融框架，量化语气风格、指令组织、工具描述三个维度对任务完成率的影响。book/chapter2.md「上下文：决定 Agent 能力上限的关键」book/chapter2.md「Agent 如何调用大模型：理解 API 的上下文结构」book/chapter2.md「提示工程：优化系统提示词」book/chapter2.md「动态提示词与 Agent Skills」まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
为 Agent 建立或改进评估体系时使用——设计评估指标（Pass@k/Pass^k/成本）、搭建可重复运行的评估环境、选择确定性验证器或 LLM-as-a-Judge 及各自适用边界、编写 Rubric、做失败归因与回归任务、评估驱动的模型选型、判断统计显著性、建设可观测性与内部评估基础设施（消融、AB 测试、特性开关、提示词回归）、从 Benchmark 报告走到系统改进。
日本語の概要は準備中です。原文の説明を表示しています。
让 Agent 从运行经验中持续学习、构建自进化闭环时使用——涵盖从运行轨迹提取学习信号（三层轨迹验证）、四种进化方式（经验知识库、Prompt/Skill、程序/Harness、模型参数）的适用边界与选择依据、Prompt 自动优化、轨迹编译为程序、Agent 自我修改与安全门禁、睡眠学习与长期分层评估。触发词：持续进化、自进化、经验学习、轨迹验证器、自我修改、进化闭环。
日本語の概要は準備中です。原文の説明を表示しています。
Agent 陷入无限循环、数不清工具调用次数、遗忘 TODO 或目标偏离、长任务中思考 token 持续膨胀时使用——Agent 状态栏机制、作为 user 消息注入末尾的 KV Cache 理由、每轮替换与持久追加两种实现及成本模型、五种状态栏技术（时间戳、工具计数器、TODO、详细错误、系统状态）与维护铁律。
日本語の概要は準備中です。原文の説明を表示しています。
中文文案去「AI 味」检查清单，由用户纠正反馈持续提炼而来
日本語の概要は準備中です。原文の説明を表示しています。
构建异步/事件驱动 Agent，或让 Agent 响应外部事件（新邮件、webhook 回调、IM 消息、定时器、系统告警）、 处理工具执行期间的用户打断与多任务并发时使用。覆盖事件循环与安全点、三类事件触发工具、用户沟通与多渠道召回、 虚拟身份与隔离执行环境、队列式/取消式/并行式三种事件处理策略及紧急度判定，以及模型原生异步与同步接口兼容两条路线。 触发词：异步 Agent、事件驱动、event-driven、webhook、定时器、心跳、任务句柄、打断、steering、并行工具执行。
日本語の概要は準備中です。原文の説明を表示しています。
把生产 bad case / 失败轨迹转成训练数据时使用——从失败归因、轨迹前缀截取、DPO 偏好对构造、LoRA 训练到边界集与保留集双集验证的完整链路；也用于判断某类问题该走 SFT、DPO、RL 还是先修 Harness/工具/tokenizer，以及如何从运行轨迹中提取带证据的结构化学习信号。触发词：bad case、失败归因、DPO、偏好对、轨迹前缀、拒绝采样、过度矫正、边界集、保留集、过早结束、reward hacking、LoRA 微调、训练评估隔离。
日本語の概要は準備中です。原文の説明を表示しています。