[{"content":" Introduction # Retrieval-Augmented Generation (RAG) is a powerful pattern that combines the strengths of large language models with external knowledge retrieval. Instead of relying solely on a model\u0026rsquo;s training data, RAG pipelines fetch relevant documents from a vector store and inject them into the LLM context at query time. This approach dramatically reduces hallucinations and enables your application to reason over proprietary or up-to-date data.\nIn this tutorial, you will build a complete RAG application using LangChain, ChromaDB as the vector store, and OpenAI as the LLM provider. By the end, you will have a working command-line QA system that answers questions from your own documents.\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-build-rag-with-langchain/","section":"实战教程","summary":"","title":"Build a RAG Application with LangChain","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/langchain/","section":"Tags","summary":"","title":"Langchain","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/openai/","section":"Tags","summary":"","title":"Openai","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/rag/","section":"Tags","summary":"","title":"Rag","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/categories/tutorials/","section":"Categories","summary":"","title":"Tutorials","type":"categories"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/vectordb/","section":"Tags","summary":"","title":"Vectordb","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/","section":"实战教程","summary":"","title":"实战教程","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/news/","section":"AI 资讯","summary":"","title":"AI 资讯","type":"news"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/gpt-5/","section":"Tags","summary":"","title":"GPT-5","type":"tags"},{"content":" GPT-5 Arrives: A New Era of Multimodal Reasoning # OpenAI has officially launched GPT-5, marking what the company calls \u0026ldquo;the most significant capability leap since GPT-4.\u0026rdquo; The new model introduces native multimodal reasoning, seamlessly processing text, images, audio, and video within a unified architecture.\nKey Features # ","date":"2026年5月6日","externalUrl":null,"permalink":"/news/2026-05-06-gpt5-launch/","section":"AI 资讯","summary":"","title":"GPT-5 Officially Launches with Advanced Multimodal Reasoning","type":"news"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/llm/","section":"Tags","summary":"","title":"LLM","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/multimodal/","section":"Tags","summary":"","title":"Multimodal","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/categories/news/","section":"Categories","summary":"","title":"News","type":"categories"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/reasoning/","section":"Tags","summary":"","title":"Reasoning","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/agent%E8%AE%BE%E8%AE%A1/","section":"Tags","summary":"","title":"Agent设计","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai-agent/","section":"Tags","summary":"","title":"AI Agent","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/skill/","section":"Tags","summary":"","title":"Skill","type":"tags"},{"content":"现在但凡用 AI Agent 做点正事的人，手上都有几个自己写的 Skill。\n但说实话，大部分 Skill 写得跟 Prompt 没啥区别——把背景、规则、注意事项、示例一股脑塞进一个文件，看起来很完整，实际跑起来并不好用。\nSkill 和 Prompt 的区别不在于长度，在于架构。\n一、先搞清楚 Skill 到底是什么 # 三个概念容易混淆：\n系统提示词 / CLAUDE.md — 常驻上下文，一直在，一直影响模型行为 Slash Command — 手动触发，用户必须明确输入命令 Skill — 介于两者之间，按需加载 Skill 的核心机制是 on-demand loading。平时它的完整内容不在上下文里，只有当用户的输入和 Skill 的 description 匹配时，才会被加载进来。\n这意味着一件事：description 写得好不好，直接决定 Skill 会不会被正确触发。\n反面教材：一个封面图生成 Skill 的 description 只写 \u0026ldquo;Create an image\u0026rdquo;。\n正面教材：同一个 Skill，description 应该覆盖用户真实会说的各种表达——\n帮我做一张封面图 / 给这篇文章配个图 / 做一张小红书封面 / 按这个标题做一张科技感海报\n用户不会说\u0026quot;调用封面图 Skill\u0026quot;。他们用自然语言描述需求，你的 description 要能接住这些表达。\n低频 Skill 就别自动加载了 # 有个实用技巧：如果你有很多 Skill，或者某个 Skill 很长，可以设置 disable，关掉自动加载，降级为 slash command。\n为什么？因为自动加载类 Skill 至少要让 description 长期参与匹配。Skill 越多，常驻的匹配成本越高。年终总结 Skill 一年用几次、简历重写 Skill 找工作才用——这类东西没必要一直占着 context。\n降级为手动调用的好处是省 context、少误触发。代价是用户必须记得主动叫它。\n二、限制工具边界，最小权限原则 # Skill 可以配置允许使用的工具列表。这不是摆设。\n整理学习笔记的 Skill，只需要读和写：\nallowed-tools: - Read - Write - Grep 封面图生成的 Skill，需要读参考、写 prompt、调图片工具：\nallowed-tools: - Read - Write - ImageGenerate 批量处理数据的 Skill，才需要开放更多权限。\n核心原则：只给完成任务所需的最小权限。\n让只负责分析建议的 Skill 默认能改文件，让只读 Skill 默认能跑 Bash——这不是灵活，这是给自己埋雷。工具越多不一定越强，有时只是风险更大。\n三、不同 Skill 配不同模型 # 这一点经常被忽略。\n所有任务用同一个模型，要么浪费钱（简单任务用贵模型），要么质量差（复杂任务用便宜模型）。成熟的 Skill 系统应该根据任务类型选模型：\n任务类型 模型选择思路 写文档 表达清楚、结构稳定，中等模型即可 做图/设计 多模态能力，视觉理解强的模型 数据分析 推理不错但成本可控 信息爬取 批量抽取，便宜快的模型更合适 生成长文 写作节奏和观点判断，用写作能力强的 模型选择不是炫技，是成本和可靠性的平衡。\n四、SKILL.md 是入口文件，不是百科全书 # 这是最容易犯的错——把所有内容都塞进 SKILL.md。\n结果呢？Context 被瞬间占满，Agent 性能变差，思考时间变长，甚至触发 Compact 导致\u0026quot;失忆\u0026quot;。\nSKILL.md 应该只放这些：\n什么时候触发 做事原则 执行步骤 需要哪些工具 其他资料在哪里 最后怎么验证 其他的，分层存放：\n封面图生成/ ├── SKILL.md ← 入口，流程和原则 ├── references/ │ ├── 封面图风格参考.md │ ├── 常见平台尺寸.md │ └── 好坏案例对比.md ├── scripts/ │ ├── 检查图片尺寸.py │ └── 导出多平台版本.py └── assets/ ├── 封面图模板.md └── 字体与配色示例.json references/ 放长文档——风格参考、平台尺寸、详细案例。\nscripts/ 放可执行代码——检查图片尺寸、批量重命名、导出多平台版本。这些确定性操作用脚本比让模型每次现场生成更稳定。\nassets/ 放模板和样例——schema、图片示例、输出格式。\nAgent 先读 SKILL.md 知道流程，真的需要细节时再去读 reference，执行 script。按需读，按需执行。\n这就是渐进式披露（Progressive Disclosure）。SKILL.md 建议控制在 500 行以内。超过通常说明分层没做好。\n五、写完不等于能用——Skill 的验证闭环 # 很多人写完 Skill 就发布了。但你真的验证过吗？\n一个靠谱的 Skill 至少要过三关：\n第一关：能不能跑 # 最基础的执行能力验证：\n文件路径对不对？ 工具权限够不够？ 脚本能执行吗？ reference 能读到吗？ 输出格式符合预期吗？ 连真实任务都跑不通，后面谈触发和质量没意义。\n第二关：能不能正确触发 # 自动加载类 Skill 要测试触发准确性。\n不能只测\u0026quot;请运行 XX Skill\u0026quot;——真实用户不会这么说。应该准备一组真实表达：\n\u0026ldquo;把这个想法展开成一篇长推\u0026rdquo; \u0026ldquo;帮我写一篇 X 长文\u0026rdquo; \u0026ldquo;这个观点能不能写成一条长内容\u0026rdquo;\n该触发的不触发，说明 description 要补关键词。不该触发的触发了，说明 description 要收窄。\n第三关：结果是不是真的更好 # 最容易被忽略的一步。\n同一个任务跑两次——一次不用 Skill，一次用。然后打分（0-10）：\n分数 含义 0-2 完全没完成，方向错了 3-4 勉强相关，漏掉关键要求 5-6 基本可用，有明显问题 7-8 质量稳定，少量细节可改 9-10 非常符合预期，可做示范 如果不用 Skill 是 4 分，用了是 8 分——Skill 真的有用。\n如果都是 7 分——Skill 可能在做无用功，你只是把 Prompt 保存下来而已，并没有把经验固化进去。\n六、根据评分迭代 # 评分不是为了好看，是为了定位问题：\n触发失败 → description 补案例 误触发 → description 加排除条件 步骤遗漏 → 改 SKILL.md 步骤 输出格式不稳定 → 加 assets 模板 确定性检查不稳 → 写成 script 工具权限不对 → 调整 allowed-tools 模型能力不够 → 换模型 然后跑下一轮 eval。写 Skill → 测 → 打分 → 改 → 再测。这个闭环跑通了，Skill 才算真正可用。\n七、写 Skill 之前先问自己七个问题 # 别急着动笔。先想清楚：\n用户说出哪些话时，这个 Skill 应该出现？ 它出现后，应该按什么流程做？ 它允许用哪些工具，不允许做什么？ 它适合什么模型？ 哪些内容留主文件，哪些拆出去？ 怎么证明它真的有效？ 后续怎么持续维护让它更好用？ 能回答完这七个问题，写出来的才是 Skill。回答不了，大概率只是一个穿了马甲的 Prompt。\nSkill 的本质不是\u0026quot;把提示词写长保存下来\u0026quot;。它是把经验固化成可触发、可执行、可测试、可维护的工作流。这两者的差距，就跟脚本和正儿八经的工程一样大。\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-industrial-skill-design/","section":"实战教程","summary":"AI Agent Skill 不是 Prompt 的加长版。本文从按需加载、工具边界、模型选择、渐进式披露、验证迭代五个维度，拆解如何写出真正能在生产环境稳定运行的工业级 Skill。","title":"别把 Skill 写成 Prompt：工业级 AI Agent Skill 的七个设计原则","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%B7%A5%E4%BD%9C%E6%B5%81/","section":"Tags","summary":"","title":"工作流","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%B7%A5%E7%A8%8B%E5%8C%96/","section":"Tags","summary":"","title":"工程化","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B/","section":"Tags","summary":"","title":"提示词工程","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%95%99%E7%A8%8B/","section":"Tags","summary":"","title":"教程","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/","section":"Tags","summary":"","title":"最佳实践","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai%E7%A0%94%E7%A9%B6/","section":"Tags","summary":"","title":"AI研究","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/feynman/","section":"Tags","summary":"","title":"Feynman","type":"tags"},{"content":" 前置准备 # 你需要的：\nmacOS 或 Linux（Windows 也可以，用 PowerShell） 能联网 一个 LLM API Key（推荐先用 DeepSeek 或 OpenAI，便宜效果好） 不需要 GPU，不需要 Python 环境，不需要装 Node.js。\n第一步：安装 # 打开终端，一行搞定：\ncurl -fsSL https://feynman.is/install | bash 这条命令会自动检测你的系统和架构（macOS Intel/Apple Silicon、Linux x64/ARM64），下载对应的预编译包。自带 Node.js 运行时，不会跟你系统的 Node 冲突。\nWindows 用户用 PowerShell：\nirm https://feynman.is/install.ps1 | iex 装完验证一下：\nfeynman --version 第二步：配置 # 第一次用需要设置模型和搜索源：\nfeynman setup 交互式引导会问你几个问题：\n选模型 # 方案 A：云模型（推荐新手）\n选 OpenAI 或 DeepSeek，输入 API Key 就行。DeepSeek V4 的性价比很高，做研究任务完全够用。\n方案 B：本地模型（隐私优先）\n选 LM Studio，保持默认 http://localhost:1234/v1。你需要提前在 LM Studio 里加载一个模型，推荐 14B 参数以上的。\nOllama 用户选 \u0026ldquo;Custom provider\u0026rdquo;，填 openai-completions，指向 http://localhost:11434/v1。\n配搜索源 # 至少配一个 Web 搜索引擎：\nExa — 质量最高，适合学术搜索，有免费额度 Perplexity — 综合搜索，速度快 Gemini — Google 的搜索 API 论文搜索走 alphaXiv，feynman setup 会帮你配好。没登录 alphaXiv 也能用基础搜索功能。\n验证配置 # feynman doctor 这个命令会检查模型连通性、搜索源状态、alphaXiv 登录情况，有问题会直接告诉你怎么修。\n第三步：跑一次深度研究 # 来个实际的例子。假设你想了解 \u0026ldquo;MoE（混合专家模型）的最新进展\u0026rdquo;：\nfeynman deepresearch \u0026#34;Mixture of Experts recent advances 2025 2026\u0026#34; Feynman 会这样做：\nResearcher Agent 启动，同时搜论文（alphaXiv）和网页（Exa/Perplexity） 找到的资料被分成多个子问题，并行调查 Verifier Agent 逐条验证来源链接和引用准确性 Writer Agent 把所有发现组织成结构化报告 输出一份带完整引用的研究简报 整个过程可能需要 2-5 分钟，取决于你的模型和搜索源。终端里会实时显示进度。\n看结果：\nfeynman outputs 浏览所有生成的研究产出，支持导出为 Markdown 或 PDF。\n第四步：做一次文献综述 # 深度研究偏\u0026quot;广\u0026quot;，文献综述偏\u0026quot;深\u0026quot;：\nfeynman lit \u0026#34;RLHF alternatives: DPO, GRPO, KTO\u0026#34; Feynman 会输出：\n共识 — 哪些结论是学术界普遍认同的 分歧 — 哪些问题还有争议，不同论文的观点是什么 开放问题 — 还没人搞明白的方向 这个输出比你自己一篇篇读论文整理出来的要快得多，而且结构更清晰。当然，你需要自己判断 AI 整理的内容是否准确——建议挑几个关键引用回原文核实。\n第五步：审计一篇论文 # 这是 Feynman 最有意思的功能之一。拿到一篇论文的 arXiv ID：\nfeynman audit 2501.12345 Feynman 会：\n读论文摘要和核心声明 找到对应的代码仓库（如果有的话） 逐条对比论文声称的 vs 代码实际实现的 标记不一致的地方 学术圈经常有论文写得天花乱坠但代码对不上的情况，这个功能帮你自动做\u0026quot;事实核查\u0026quot;。\n进阶：配置 GPU 实验复现 # 如果你想让 Feynman 帮你跑实验：\nModal（推荐，按秒计费）：\npip install modal modal token new 配置好之后，feynman replicate 会自动把实验部署到 Modal 的云端 GPU 上跑。\nRunPod（适合长时间实验）：\n在 RunPod 租一个 GPU Pod，Feynman 通过 SSH 连上去跑。适合需要跑几小时的训练任务。\n本地 GPU：\n如果你自己有显卡，用 Docker 隔离执行：\nfeynman setup # 选择 Docker 作为执行环境 常用命令速查 # 命令 用途 feynman \u0026quot;问题\u0026quot; 快速研究，30秒-3分钟 feynman deepresearch \u0026quot;主题\u0026quot; 多Agent深度调查 feynman lit \u0026quot;主题\u0026quot; 文献综述 feynman audit \u0026lt;arxiv_id\u0026gt; 论文审计 feynman replicate \u0026quot;实验\u0026quot; 复现实验 feynman compare \u0026quot;主题\u0026quot; 多源对比 feynman /watch \u0026quot;主题\u0026quot; 持续跟踪（每天自动跑） feynman outputs 查看所有产出 feynman doctor 检查配置状态 feynman search status 检查搜索源 几个实用技巧 # 1. 用英文提问效果更好\nFeynman 搜索的论文和文档主要是英文的，用英文提问搜到的资料更全面。你可以在 prompt 里加 \u0026ldquo;answer in Chinese\u0026rdquo; 让它用中文输出。\n2. 加时间限定\nfeynman \u0026quot;MoE scaling laws 2025 2026\u0026quot; 比 feynman \u0026quot;MoE scaling laws\u0026quot; 效果好，因为会优先搜近期的论文。\n3. 会话可以断点续传\n研究跑到一半可以中断，下次 feynman 启动时会提示恢复之前的会话。长课题不怕断。\n4. 省钱模式\n简单问题用 feynman \u0026quot;问题\u0026quot; 就够了，别什么都上 deepresearch。flash 模型 + 快速搜索，30 秒出结果，成本几乎为零。\n参考来源：getcompanion-ai/feynman · feynman.is/docs\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-feynman-tutorial/","section":"实战教程","summary":"Feynman 实战教程：一行命令安装，三步完成配置，分别演示深度研究（deepresearch）、文献综述（lit）和论文审计（audit）三个核心工作流，附带本地模型和云 GPU 的配置方法。","title":"Feynman 实战：用 AI Agent 半小时搞定一篇文献综述","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%AD%A6%E6%9C%AF%E5%B7%A5%E5%85%B7/","section":"Tags","summary":"","title":"学术工具","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%AE%89%E8%A3%85%E6%95%99%E7%A8%8B/","section":"Tags","summary":"","title":"安装教程","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%96%87%E7%8C%AE%E7%BB%BC%E8%BF%B0/","section":"Tags","summary":"","title":"文献综述","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E7%BB%88%E7%AB%AF%E5%B7%A5%E5%85%B7/","section":"Tags","summary":"","title":"终端工具","type":"tags"},{"content":"做学术研究的人都知道，调研一个新方向有多痛苦——搜论文、读摘要、下 PDF、整理笔记、交叉验证引用，搞完一天就过去了。\nGitHub 上有个项目叫 Feynman（对，就是那个费曼），试图用 AI Agent 把这整个流程自动化。目前 6500+ Star，MIT 协议，TypeScript 写的。\n不只是\u0026quot;AI 搜论文\u0026quot; # 市面上的\u0026quot;AI 学术助手\u0026quot;大多是套了一层壳的搜索工具。Feynman 不太一样，它是一个完整的研究工作流引擎：\n一句话能触发的事：\nfeynman \u0026#34;scaling laws 有什么新进展\u0026#34; → 搜论文 + 搜网页 → 生成带引用的研究简报 feynman deepresearch \u0026#34;机械可解释性\u0026#34; → 多 Agent 并行调查 → 综合 → 交叉验证 feynman lit \u0026#34;RLHF 的替代方案\u0026#34; → 文献综述：共识、分歧、开放问题 feynman audit 2401.12345 → 论文声称的 vs 代码仓库实际做的，逐条对比 feynman replicate \u0026#34;chain-of-thought 提升数学推理\u0026#34; → 在本地或云 GPU 上复现实验 最后那条是真的能跑实验，不是嘴上说说。\n四个 Agent 各司其职 # Feynman 内置了四个专业化 Agent，根据你的指令自动调度：\nAgent 干什么 Researcher 搜集证据：论文、网页、代码仓库、文档 Reviewer 模拟同行评审，按严重程度分级给出反馈 Writer 把研究笔记组织成结构化草稿 Verifier 逐条验证引用、检查链接是否失效 不是一个大模型在那自说自话，而是四个角色分工协作。Researcher 找到的资料，Verifier 会交叉验证；Writer 写出来的东西，Reviewer 会挑刺。这种多 Agent 架构比单轮问答靠谱得多。\n工具链做得很实在 # Feynman 不是光靠大模型脑补，它接入了真实的研究工具：\nalphaXiv — 论文搜索、问答、代码阅读、标注，通过 alpha CLI 调用 Docker — 隔离容器执行实验，不污染你的机器 Web 搜索 — 支持 Exa、Perplexity、Gemini API 三种引擎 Modal / RunPod — 云 GPU 计算，复现实验用 会话搜索 — 之前做过的研究会被索引，下次能直接调用 每个输出的结论都带来源链接——论文 URL、文档地址、代码仓库，点开就能验证。\n十个研究命令覆盖主要场景 # 命令 场景 /deepresearch 多源深度调查 /lit 文献综述 /review 模拟同行评审 /audit 论文 vs 代码审计 /replicate 复现实验 /compare 多源对比矩阵 /draft 从研究笔记生成论文草稿 /autoresearch 自主实验循环 /watch 持续跟踪某个研究方向 /outputs 浏览所有研究产出 基本上把学术研究的核心环节都覆盖了。\n安装和使用 # 一行命令搞定：\n# macOS / Linux curl -fsSL https://feynman.is/install | bash # Windows PowerShell irm https://feynman.is/install.ps1 | iex 装完运行 feynman setup 配置模型和搜索。支持 OpenAI、Anthropic 等云端模型，也支持 LM Studio、Ollama、vLLM 跑本地模型。\n如果你只是想用它的研究技能（不装完整终端），还有个轻量安装方式，只下载 skills 和 prompts 到 ~/.codex/skills/feynman，可以配合 Codex CLI 使用。\n我的看法 # 学术研究的 AI 工具越来越多了，但大多数停留在\u0026quot;帮你搜一搜\u0026quot;的层面。Feynman 做得比较深——多 Agent 协作、实验复现、引用验证、持续跟踪，这些是真正做研究的人需要的。\n尤其论文审计（audit）这个功能挺有意思。学术界论文和代码不一致的问题一直存在，Feynman 能自动对比论文声称和代码实现之间的差异，这个对研究者来说很实用。\n当然，深度研究功能的效果很依赖底层模型的能力和搜索源的质量。alphaXiv 的覆盖范围目前主要还是 CS 领域，其他学科的论文支持可能没那么好。\n但方向是对的。学术研究本来就是一个信息密集、流程标准化的工作，非常适合 AI Agent 来做。Feynman 至少在这个方向上迈出了扎实的一步。\n参考来源：getcompanion-ai/feynman · feynman.is\n","date":"2026年5月6日","externalUrl":null,"permalink":"/projects/2026-05-06-feynman-research-agent/","section":"开源项目","summary":"发现一个叫 Feynman 的开源 AI 研究助手，6.5k Star。不是普通的搜索增强，而是能做文献综述、论文审计、实验复现的终端 Agent。四个内置 Agent 分工协作，搜索论文用 alphaXiv，GPU 实验跑 Modal/RunPod，所有结论都带来源链接。","title":"Feynman：把学术研究搬进终端的 AI Agent","type":"projects"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/hermes/","section":"Tags","summary":"","title":"Hermes","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/opc/","section":"Tags","summary":"","title":"OPC","type":"tags"},{"content":" 一个 Agent 干所有事，为什么不行 # OPC（One-Person Company，一人公司）最近很火。核心思路是一个人借助多个 Agent，像管理团队一样完成复杂任务。\n但如果你只用一个 Agent 全包，长期运行会遇到三个致命问题。\n幻觉问题 # 一个 Agent 自己写、自己审、自己觉得自己没问题。没有第二视角的交叉验证，错误会一路滑过去。\n记忆污染 # 一个 Agent 同时做所有项目，记忆全混在一起。写代码时带着内容创作的习惯，写文章时带着工程思维，做研究时提前下结论——每条经验都没错，但放在一起就互相打架。\n角色混乱 # 该研究的时候它开始写结论，该写作的时候它重新查资料，该审查的时候它替自己辩护。一个 Agent 扮演太多角色，每个都做不深。\n所以多 Agent 协作的本质不是\u0026quot;更多 Agent\u0026quot;，而是更清晰的角色边界。\n四个概念先搞清楚 # 搭建之前，先分清 Profile、Subagent、Project、Wiki——混了后面的系统一定乱。\n概念 类比 特点 Profile 长期员工 独立身份、记忆、技能 Subagent 临时工 干完就走，不需要长期人格 Project 项目空间 同一套 Profile 团队服务多个项目 Wiki 共享文档 多 Profile 的共享记忆层 关键原则：\n不要为每个项目复制一套 Profile。 同一套 Profile 团队服务多个 Project folder。 多 Profile 记忆不相通，靠 Wiki 同步。 Wiki 记录项目进度、决策记录、知识沉淀。 四角色模型 # 推荐一个经过验证的分工模型：Coordinator、Researcher、Writer、Builder。\n对应真实公司里的项目经理、研究员、作家、工程师。\nCoordinator（协调员 / 项目经理） # 核心职责：\n定义目标 — 明确最终要达成什么 拆分任务 — 把大目标拆成可执行的小任务 路由任务 — 判断每个任务该交给谁 汇总结果 — 把不同角色的产出整合成最终成果 检查边界 — 避免记忆污染和文件冲突 Coordinator 不亲自查资料、写文章、写代码。它最重要的事是让整个系统有序运行。\nResearcher（研究员） # 核心职责：\n收集证据 — 从多个来源获取信息 对比来源 — 交叉验证，确保可靠 标记不确定性 — 明确哪些信息尚未验证 提炼事实 — 区分事实、观点和推测 好的 Researcher 能显著降低整个系统的幻觉。它不写最终稿，不做决策，只提供可靠的原材料。\nWriter（作家） # 核心职责：\n搭建文章结构 优化表达方式 提炼主线和观点 让内容适合目标读者 把复杂概念讲清楚 当 Writer 不用负责规划和查资料，它的输出质量会明显提升——因为它只专注一件事：把内容讲清楚。\nBuilder（构建者 / 工程师） # 核心职责：\n实现 — 把计划变成可运行的代码或系统 调试 — 定位并修复问题 测试 — 确保输出稳定可靠 交付 — 生成最终可用的结果 当 Builder 不用讲故事、做研究、定方向，它可以专注于落地。\n完整工作流 # 一套典型的多 Profile 工作流：\n1. Coordinator → 拆解任务、规划项目 2. Researcher → 收集来源、验证主张 3. Writer → 把研究结果转化成清晰内容 4. Builder → 实现代码、落地交付 5. Coordinator → 检查、汇总、归档 这个结构之所以强大，是因为它反映了真实工作流程。现实里也不会让同一个人同时当项目经理、研究员、作家和工程师。\n每个 Profile 由什么组成 # 确定角色分工后，开始构建每个 Profile。以 Coordinator 为例：\nsoul.md — Profile 的身份文件 # 定义这个 Agent 是谁、负责什么、有什么边界、不该做什么。\n# Coordinator soul.md（示例） 你是协调员。 你负责拆分任务、规划项目、汇总结果。 你不直接执行研究任务。 你不直接写最终内容。 你不直接实现代码。 注意： 不要把具体项目内容写进 soul.md，否则会造成角色污染。soul.md 回答的是\u0026quot;这个 Agent 是谁\u0026quot;，不是\u0026quot;这个项目在做什么\u0026quot;。\nUSER.md — 对用户的理解 # 记录这个 Profile 对用户的理解：语言偏好、输出格式、沟通风格等。\nmemory.md — 通用经验 # 记录长期工作中总结的通用经验，比如\u0026quot;复杂任务先拆解\u0026quot;、\u0026ldquo;不同 Profile 不要同时改同一个文件\u0026rdquo;。\n不放项目状态。 \u0026ldquo;今天写了 3 条推文\u0026quot;这类内容放到项目空间里。\nskills — 技能库 # 可复用的任务流程。Coordinator 的技能可以是任务拆解、优先级判断、交接单生成、周复盘等。\nconfig.yaml — 运行配置 # 规定这个 Profile 用什么模型、工作目录在哪、能读写哪些文件。\n.env — 密钥 # 只放 API Key、Token、SMTP 密码等凭证。不要放进 soul.md、memory.md 或 Wiki——这些文件会进入模型上下文。\n小结 # 搭建多 Agent 协作团队，核心三步：\n明确为什么不能一个 Agent 全包 — 幻觉、记忆污染、角色混乱 区分 Profile、Subagent、Project、Wiki — 四个概念各有边界 搭建四角色模型 — Coordinator 统筹、Researcher 验证、Writer 表达、Builder 落地 但团队要长期运行，光有人还不够。还需要共享文档、项目空间、任务看板、决策记录和复盘机制——也就是 Wiki 共享记忆系统。\n下一篇文章会详细讲：如何用 Wiki 构建你的 OPC 共享记忆层。\n参考来源：@knoYee_ 推文\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-opc-multi-agent-collaboration/","section":"实战教程","summary":"详解 Hermes 多 Profile 协作架构：为什么一个 Agent 不够、Profile/Subagent/Project/Wiki 四个概念怎么区分、Coordinator/Researcher/Writer/Builder 四角色模型如何搭建。","title":"OPC 实战：如何用 Hermes 搭建多 Agent 协作团队","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/categories/projects/","section":"Categories","summary":"","title":"Projects","type":"categories"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E4%B8%80%E4%BA%BA%E5%85%AC%E5%8F%B8/","section":"Tags","summary":"","title":"一人公司","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%A4%9Aagent%E5%8D%8F%E4%BD%9C/","section":"Tags","summary":"","title":"多Agent协作","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/projects/","section":"开源项目","summary":"","title":"开源项目","type":"projects"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%BC%80%E6%BA%90%E9%A1%B9%E7%9B%AE/","section":"Tags","summary":"","title":"开源项目","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E8%87%AA%E5%8A%A8%E5%8C%96/","section":"Tags","summary":"","title":"自动化","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E8%AE%BA%E6%96%87/","section":"Tags","summary":"","title":"论文","type":"tags"},{"content":"你有没有遇到过这种情况：花了一周时间调 AI Agent，换了最强的模型、写了上百版 Prompt，demo 演示的时候效果惊艳，但一到真实场景就翻车——有时候聪明绝顶，有时候莫名其妙地跑偏、死循环、甚至胡编乱造。\n成功率死活卡在 70% 左右，怎么调都不上去。\n问题大概率不在模型，也不在 Prompt。你缺的是一套 Harness。\nAgent = Model + Harness # 先建立一个直觉：模型是大脑，Harness 是让大脑驱动身体稳定工作的神经系统和骨架。\n没有 Harness 的 Agent 就像一个天才但没有自律能力的人——偶尔灵光一现，但大多数时候在摸鱼。Harness 的作用就是让这个天才稳定产出，而不是靠运气。\n北大博士后卢菁和多个一线工程团队的实践总结出了一套成熟的 Harness 六层架构，下面逐层拆解。\n第一层：信息边界 — 给模型一个干净的\u0026quot;工作台\u0026quot; # 模型在噪音里是没法思考的。你有没有试过往 Prompt 里塞了十几页的规则文档，结果模型反而更蠢了？\nHarness 的第一件事就是给信息划边界：\n角色隔离：这个 Agent 现在是谁？做什么事？成功标准是什么？ 信息分层：哪些是规章制度（不能改），哪些是当前任务（经常变），哪些是中间产物（用完可能要丢） 防止自我污染：模型自己生成的错误推理，如果不清理，会在后续轮次中被当成\u0026quot;事实\u0026quot;继续引用 实际操作中，这意味着你要把上下文分成几个独立区块，而不是把所有东西堆在一起。\n第二层：工具系统 — 别让模型被返回结果淹没 # 大模型本质上是个文本预测器，给它接上工具才有手有脚。但这里有个反直觉的陷阱：工具给多了，模型会乱用；工具返回的内容多了，模型会被淹没。\n举个例子：你让 Agent 查数据库，SQL 查询返回了 200 行结果。如果你把这 200 行原封不动地丢回给模型，它的注意力会被分散，核心信息反而被淹没。\n好的 Harness 会做二次过滤：先把工具返回的结果提炼、摘要，只把模型需要的\u0026quot;干货\u0026quot;喂回去。这就像一个优秀的助理——不是把所有邮件都转发给老板，而是先筛选、归纳，只给老板看真正需要决策的内容。\n第三层：执行编排 — 给 Agent 铺一条铁轨 # 没有编排的 Agent 是\u0026quot;想到哪做到哪\u0026quot;，有编排的 Agent 是沿着轨道走。\n一个靠谱的执行流程应该是：\n理解：先消化任务，确认理解无误 分析：拆解步骤，制定计划 执行：按计划逐步操作 自检：检查结果是否达标 关键在于自检不通过时的处理：不是让模型\u0026quot;再试一次\u0026quot;（它大概率会犯同样的错），而是强制回退到上一个稳定状态，换个策略重新来。\n这和传统软件的 try-catch 逻辑一样——不是出了错就重试，而是要有明确的回滚策略。\n第四层：记忆与状态 — 让 Agent 不再\u0026quot;失忆\u0026quot; # 你跟 Agent 说\u0026quot;帮我改一下刚才那段代码\u0026quot;，它问你\u0026quot;哪段？\u0026quot;——这就是状态管理缺失的典型症状。\nHarness 需要管理三层记忆：\n层级 内容 生命周期 对话状态 当前在做什么、用户刚说了什么 单次对话 执行结果 上一步跑了什么、成功还是失败 单次任务 用户偏好 这个用户喜欢什么风格、常用什么技术栈 跨会话 三层记忆要隔离管理，否则短期的执行噪音会污染长期的用户画像。\n第五层：评估与观测 — 别让 Agent 自己给自己打分 # Agent 有个致命问题：它总是\u0026quot;自我感觉良好\u0026quot;。你让它写代码，它写了，然后告诉你\u0026quot;完成了\u0026quot;——但你跑一下发现根本编译不过。\n成熟的 Harness 会引入一个独立的 Evaluator（评估者）。这个评估者不是 Agent 自己，而是另一个独立的模块，甚至可以是另一个 LLM：\n代码生成场景：Evaluator 跑一下测试用例，看覆盖率 Web 操作场景：让 AI 模拟用户去点击页面、检查结果 内容生成场景：检查事实准确性、格式合规性 核心理念：运动员和裁判不能是同一个人。\n第六层：校验与恢复 — 失败不是终点，重头再来才是 # 真实世界里，API 超时、格式错误、网络抖动是常态。Harness 的核心价值在于：失败后不慌，自动恢复。\n输出格式不对？自动解析 + 重试 API 超时？换一个备用方案 执行到一半崩了？回滚到最后一个检查点，从那里继续 这就像游戏里的自动存档——死了不用从头开始，从上一个存档点继续就好。\n硅谷怎么做的？两个典型案例 # Anthropic：换个\u0026quot;脑子\u0026quot;继续干 # Anthropic 发现一个很有意思的现象：模型在执行长任务时会出现**\u0026ldquo;上下文焦虑\u0026rdquo;**——上下文窗口快满了的时候，模型开始丢细节、急着收尾、草草了事。\n他们的解法很激进：Context Reflection。不是在原地压缩上下文，而是直接开一个全新的 Agent 实例，把关键状态交接过去，让新 Agent 在干净的环境里继续工作。\n同时他们严格遵守生产与验收分离：Planner（计划者）和 Generator（执行者）负责干活，Evaluator（独立评估者）只盯着环境反馈打分。干活的人和检查的人是分开的。\nOpenAI：工程师变成了\u0026quot;环境设计师\u0026quot; # OpenAI 的 Agent 团队里，工程师已经不写业务代码了。他们的日常工作变成了三件事：\n把模糊的需求拆解成 AI 能理解的小任务 当 Agent 失败时，不问\u0026quot;模型哪里不够努力\u0026quot;，而是问**\u0026ldquo;环境里缺了什么结构性能力\u0026rdquo;** 把数万字的规则文档做成目录，让 AI 按需查询（类似 Skills 理念），避免一股脑全塞进上下文 这背后的思维转变是：不再优化模型的行为，而是优化模型工作的环境。\n你的 Agent 卡在哪一层？ # 最后给一个快速自查清单：\n📍 信息混乱 → 第一层（信息边界）没做好 📍 工具调用乱七八糟 → 第二层（工具系统）需要二次过滤 📍 执行没章法 → 第三层（执行编排）缺少流程约束 📍 多轮对话就失忆 → 第四层（记忆与状态）没有隔离管理 📍 自以为做完了其实没做对 → 第五层（评估与观测）缺少独立评估者 📍 一错就崩、从头再来 → 第六层（校验与恢复）缺少容错机制 不要一上来就六层全做。先定位卡在哪一层，单点突破，效果立竿见影。\n参考来源：code秘密花园 欢老师分享 —《最近爆火的 Harness Engineering 到底是个啥？》及 AI 工程化相关讲座\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-harness-engineering-six-layers/","section":"实战教程","summary":"AI Agent 频繁跑偏、死循环、成功率卡在 70%？北大博士后卢菁和一线团队的经验表明，真正的瓶颈是 Harness——模型外面的运行系统。本文详解六层架构设计。","title":"AI Agent 动不动就翻车？六层 Harness 架构让你告别玄学调参","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai%E5%B7%A5%E7%A8%8B%E5%8C%96/","section":"Tags","summary":"","title":"AI工程化","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai%E6%9E%B6%E6%9E%84/","section":"Tags","summary":"","title":"AI架构","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai%E7%BC%96%E7%A8%8B/","section":"Tags","summary":"","title":"AI编程","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/anthropic/","section":"Tags","summary":"","title":"Anthropic","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/context-engineering/","section":"Tags","summary":"","title":"Context Engineering","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/deepseek/","section":"Tags","summary":"","title":"DeepSeek","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/deepseek-v4/","section":"Tags","summary":"","title":"DeepSeek V4","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/github-trending/","section":"Tags","summary":"","title":"GitHub Trending","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/harness-engineering/","section":"Tags","summary":"","title":"Harness Engineering","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/tui/","section":"Tags","summary":"","title":"TUI","type":"tags"},{"content":"今天刷 GitHub Trending 的时候被吓了一跳——一个叫 DeepSeek TUI 的项目，单日暴涨 6000+ Star，直接冲上 Trending 榜首。\n看了一眼，确实有点东西。\n终端里的编程 Agent，不是玩具 # DeepSeek TUI 是一个跑在终端里的编程 Agent，基于 DeepSeek V4 模型（deepseek-v4-pro 和 deepseek-v4-flash）。但它不是那种简单的终端聊天机器人，而是真的能干活的编程助手：\n读写文件、执行 Shell 命令、管理 Git 联网搜索、浏览网页 调度子 Agent 协同工作 每次编辑完自动跑 LSP 诊断（rust-analyzer、pyright、tsc 等都支持），报错直接喂回模型上下文 最夸张的是上下文窗口 100 万 token。这意味着你可以把一整个中大型项目丢进去，它不会说着说着就忘了前面在干啥。\nAuto 模式：AI 自己决定用不用脑 # 这个功能挺聪明的。打开 --model auto 之后，DeepSeek TUI 会在每次对话前先做一个轻量级路由判断——\n简单问题（比如\u0026quot;这个函数干嘛的\u0026quot;）→ 用 Flash 模型 + 不开思考模式，省钱省时间。\n复杂任务（比如\u0026quot;重构这个模块\u0026quot;或\u0026quot;review 这个 PR\u0026quot;）→ 自动切到 Pro 模型 + 开启深度思考。\n你不需要纠结\u0026quot;这次该用哪个模型\u0026quot;，AI 自己判断。路由判断本身用的是 Flash，成本几乎可以忽略。\n三种模式对应三种心态 # 模式 适合场景 Plan 🔍 只看不改。让 AI 先探索代码库，出一个方案，你不满意它可以接着改 Agent 🤖 默认模式。AI 干每一步都要你批准，适合改关键代码 YOLO ⚡ 全自动批准。信任 AI 的话直接放手让它干，干完你 review 还有一个贴心的设计——每次对话前后自动创建 Git 快照（不影响你自己的 .git），搞砸了一行命令 /restore 回滚。\n安装简单到离谱 # npm install -g deepseek-tui deepseek --model auto 第一次启动会问你 API Key，之后保存在 ~/.deepseek/config.toml 里。也支持 Cargo、Homebrew、Scoop 安装，还有国内镜像加速。\n除了 DeepSeek 官方 API，还支持 NVIDIA NIM、Fireworks、自建 SGLang/vLLM 端点。Linux ARM64 也能跑（树莓派、华为鸿蒙 PC 都行）。\n支持 MCP，生态打通了 # DeepSeek TUI 接入了 MCP（Model Context Protocol），可以连各种外部工具服务。还支持 Skills 系统——可以安装别人打包好的指令包，直接增强 AI 的能力，不需要后端服务。\n另外它还暴露了 HTTP/SSE API 和 ACP stdio 协议，可以嵌入到其他工作流里，比如在 Zed 编辑器里直接调用。\n为什么火得这么快？ # 我觉得几个原因：\nDeepSeek V4 本身就是热门话题。 国产大模型里 DeepSeek 的技术实力和性价比有目共睹，V4 更是上了 100 万上下文。给它做一个好用的终端 Agent，关注度自然高。\n时机好。 Claude Code、Cursor、Windsurf 这些编程 Agent 都很火，但要么贵要么绑 GUI。一个轻量、便宜、跑终端里的 Agent 刚好填了这个空位。\n质量确实不错。 Rust 写的，TUI 界面用 ratatui，响应快；功能完整（LSP 诊断、会话保存/恢复、子 Agent、成本追踪）；文档也写得清楚。不是 MVP 玩票项目。\n当然，现在火不代表以后也火。编程 Agent 这个赛道卷得厉害，DeepSeek TUI 能不能持续迭代、把体验打磨好，才是关键。但至少目前的起点非常高。\n参考来源：Hmbown/DeepSeek-TUI\n","date":"2026年5月6日","externalUrl":null,"permalink":"/projects/2026-05-06-deepseek-tui/","section":"开源项目","summary":"GitHub 上一个叫 DeepSeek TUI 的项目一天拿下 6000+ Star，它把 DeepSeek V4 包装成终端里的编程 Agent——自动选模型和思考深度、100 万 token 上下文、LSP 实时报错、MCP 工具扩展，还能跑在树莓派上。","title":"一天 6000 Star：DeepSeek TUI 把编程 Agent 塞进了终端","type":"projects"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E7%BC%96%E7%A8%8Bagent/","section":"Tags","summary":"","title":"编程Agent","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/prompt-engineering/","section":"Tags","summary":"","title":"Prompt Engineering","type":"tags"},{"content":"做 AI Agent 的团队都有一个通病：模型表现不好，第一反应就是改 Prompt。加约束、换话术、写更长的指令……改了十几版还是不行，最后得出结论——\u0026ldquo;模型不行\u0026rdquo;。\n但真相往往是：你的 Prompt 没问题，问题出在你根本没注意的地方。\n北大博士后卢菁博士最近提出了一个很清晰的框架：AI 工程化已经经历了三个阶段，每个阶段的\u0026quot;主战场\u0026quot;完全不同。2026 年还在死磕 Prompt 的团队，本质上是在用 2023 年的方法解决 2026 年的问题。\n第一阶段：学会\u0026quot;怎么问\u0026quot;（2020-2023） # GPT-3 刚出来的时候，所有人都在玩一个游戏：同一个模型，换个问法，结果天差地别。\n这个阶段的核心技能就是 Prompt Engineering：\n角色设定：告诉模型\u0026quot;你是一个资深的 XX 专家\u0026quot; 少样本提示：给几个例子，让模型照着做 思维链（CoT）：让模型\u0026quot;一步一步思考\u0026quot; 格式约束：规定输出必须是 JSON / Markdown 等格式 说白了，这个阶段是在学习怎么做一个会提问的人。\n但问题来了——当你的任务从\u0026quot;帮我写封邮件\u0026quot;升级到\u0026quot;帮我处理一个完整的开发流程\u0026quot;时，一句精心设计的 Prompt 根本撑不住这种复杂度。你不可能在一句话里塞进所有的状态管理、错误处理和工具调用逻辑。\n第二阶段：学会\u0026quot;给什么\u0026quot;（2024-2025） # 大模型的上下文窗口从 4K 飙到 128K 甚至 200K+，很多人觉得\u0026quot;终于可以把所有信息都塞进去了\u0026quot;。\n但 Context Engineering 的核心理念恰恰相反：这是一门减法的艺术。\n往上下文里塞一堆无关信息，不仅浪费 Token（浪费钱），更致命的是会干扰模型的注意力机制。LLM 本质上是在做注意力加权，信息越多，注意力越分散，输出质量反而下降。\nContext Engineering 要解决的问题是：\n检索什么知识？ 从知识库里找到真正相关的片段，而不是一股脑全丢进去 保留什么记忆？ 多轮对话中哪些历史信息有价值，哪些该丢掉 裁剪什么噪声？ 用完即删，保持上下文的\u0026quot;干净度\u0026quot; 打个比方：Prompt Engineering 是在研究\u0026quot;怎么跟模型说话\u0026quot;，Context Engineering 是在研究\u0026quot;让模型在什么环境里工作\u0026quot;。一个好的工作环境，比一句好的指令重要得多。\n第三阶段：学会\u0026quot;搭环境\u0026quot;（2025 至今） # 这是当前正在爆发的阶段，也是最被低估的。\nHarness Engineering 里的 Harness 原意是马具——套在马身上控制方向、保持稳定的装备。在 AI 领域，它指的是围绕大模型搭建的整套\u0026quot;脚手架\u0026quot;系统。\n现在的 Agent 不只是聊天，它要干活：读写代码、跑测试、查数据库、调 API、在多个子任务之间跳转。这种复杂度下，纯靠指令已经摸到天花板了。\nHarness 要管的事情包括：\n任务编排：把一个大任务拆成多步，按顺序执行，处理分支和依赖 状态管理：Agent 执行到哪一步了？中间结果是什么？失败了从哪里恢复？ 工具调用协议：模型怎么知道什么时候该调哪个工具？参数怎么传？ 输出验证：模型返回的结果是否合规？格式对不对？有没有幻觉？ 安全护栏：不能让 Agent 越权操作，不能泄露敏感信息 一句话总结：决定 Agent 表现上限的，不是模型本身，而是你为它搭建的运行环境。\n诊断：你的 Agent 到底卡在哪？ # 如果你的 AI 应用效果不好，别急着改 Prompt，先按这个框架排查：\n症状 可能原因 解法方向 回复不准确、答非所问 没检索到正确的知识 优化 Context：改进 RAG 检索策略 执行一步就卡住 缺少状态管理和任务编排 优化 Harness：加工作流引擎 胡说八道、编造事实 缺少输出验证和安全护栏 优化 Harness：加校验层 格式不对、不稳定 Prompt 约束不够 优化 Prompt：但这是最简单的部分 大多数团队的问题其实卡在 Context 和 Harness 层，但他们一直在改 Prompt。就像车开不快，拼命调座椅，却没发现是发动机和变速箱的问题。\n写在最后 # 从 2023 年的\u0026quot;简单对话\u0026quot;到 2026 年的\u0026quot;全能代理\u0026quot;，AI 工程的重心已经从模型本身转移到了模型之外。\n早期的思路是：模型不行就换大的。中期的思路是：模型大了就写更好的 Prompt。而现在的现实是：模型已经够强了，真正卡住你的是上下文管理和系统架构。\n如果你正在做 AI Agent，建议先停下来审视一下：你的上下文pipeline 够不够精炼？你的 Harness 够不够完善？把这两层搞好了，效果提升会比改 100 版 Prompt 都来得明显。\n参考来源：2026 年还玩 Prompt Engineering？架构师都在卷这两个新东西！ — Dr.LuAIclass 卢菁（北大博士后、AI 专家）\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-beyond-prompt-engineering/","section":"实战教程","summary":"很多团队做 AI Agent 效果不好就疯狂改 Prompt，但问题往往出在上下文和框架层。本文拆解 AI 工程化的三个阶段，帮你定位 Agent 拉胯的真正原因。","title":"别再死磕 Prompt 了：2026 年 AI 工程化的真正战场在哪？","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/","section":"Tags","summary":"","title":"架构设计","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/claude-code/","section":"Tags","summary":"","title":"Claude Code","type":"tags"},{"content":" 你可能一直在\u0026quot;浪费\u0026quot; Claude Code # 用 Claude Code 的人越来越多，但大部分人的用法还很原始：打开终端 → 输需求 → 等结果 → 上下文满了重开 session。\nClaude Code 内置了 50 多个 slash 命令，真正决定效率的不是记住多少命令，而是掌握几套组合打法。\n这篇文章不列清单，直接讲 5 个实战场景。每个场景告诉你什么时候该用什么命令，以及为什么这么用。\n场景一：上下文快爆了，怎么抢救 # 跑了一个复杂的调试 session，来来回回十几轮，突然发现 Claude 开始变蠢——忘了前面的结论，重复已经试过的方案。大概率是上下文窗口快满了。\n系统会在 92% 时自动压缩，但自动压缩是\u0026quot;无差别删减\u0026quot;，它不知道哪些信息对你重要。\n正确打法：\n/context ← 先看一眼，上下文占了多少 /compact keep all api decisions and error patterns ← 带提示词手动压缩 /cost ← 压缩后确认 token 消耗下来了没 关键是 /compact 后面跟的那句话。不加提示词的 /compact 和自动压缩没区别，但加上 keep all api decisions 这种指示，Claude 就知道什么该留什么该删。\n好习惯：上下文到 50% 就手动 compact 一次。 压缩本身也消耗 token，越早做越便宜，留下的有效信息也越多。等到 92% 再触发，该丢的不该丢的一起被削了。\n场景二：简单任务别烧最贵的模型 # 很多人不知道 Claude Code 可以中途切换模型和推理深度。一个 session 从头到尾都用 Opus + max，简单任务也烧最贵的配置，纯浪费。\n/model sonnet ← 写简单工具函数、改样式、跑格式化 /effort low ← 搭配低推理深度，快且便宜 /model opus ← 遇到架构决策、复杂 bug 时切回来 /effort max ← 最强配置 /fast on ← 需要快速迭代时开启（Opus 4.6 跑 2.5 倍速） 切换模型不会丢上下文。同一个 session 里灵活调整：写样板代码用 Sonnet low 省钱，遇到真正需要深度思考的问题再切 Opus max。\n算笔账： 假设一个 session 里 60% 的对话是简单任务，全程 Opus 意味着 60% 的钱花在了不需要 Opus 的地方。光这一个习惯，一个月能省 40% 的费用。\n场景三：方向不确定，怎么低成本试错 # 有个需求，但不确定该用方案 A 还是方案 B。传统做法是选一个跑，跑完发现不对再回来跑另一个，前面的 token 全浪费。\n/plan implement caching with Redis vs in-memory LRU ← 先不动手，让 Claude 出对比方案 /branch redis-approach ← 分叉出去跑 Redis 方案 /branch lru-approach ← 再分叉跑 LRU 方案 /plan 是最被低估的命令。它让 Claude 进入\u0026quot;只想不做\u0026quot;模式——写出完整方案但不碰任何文件。方向如果不对，只浪费了几百 token 的 plan，而不是几万 token 的完整实现。\n/branch 更进一步——直接分叉对话，两个方向同时跑，互不干扰，跑完比较结果。\n还有一个容易忽略的：/rewind。跑了一半发现方向错了，不需要新开 session，直接回退到之前的 checkpoint，保留前面正确的上下文，只回退错误的部分。\n场景四：大项目怎么不让上下文互相污染 # 做一个大功能，涉及前端、后端、数据库三块。在一个对话里全部搞定，后端代码细节会占满上下文，等做前端的时候 Claude 已经\u0026quot;忘了\u0026quot;前端约定。\n/agents ← 把后端、前端、数据库拆成三个 subagent /add-dir ./frontend ← 只让 Claude 看到前端目录 /add-dir ./backend ← 切到后端时再加 /review ← 每个模块写完后跑一次 code review /simplify ← 最后精简一遍 /agents 的精髓不是并行（虽然确实能并行），而是上下文隔离。每个 subagent 在独立空间里工作，消耗几万 token，但返回给主会话的只是一两句结论，主会话的上下文始终保持干净。\n推荐习惯： 写完一个模块就 /review 一次查问题，最后整体 /simplify 去掉 Claude 特有的\u0026quot;过度抽象\u0026quot;毛病。\n场景五：让 Claude 融入你的日常工作流 # 大部分人把 Claude Code 当独立工具用，但它可以和 IDE、Git、CI/CD 深度打通。\n日常开发：\n/init — 新项目第一件事，生成 CLAUDE.md /memory — 随时更新项目约定 /ide — 连上 VS Code / Cursor，获取当前打开文件的上下文 /hooks — 配置自动化：保存文件后自动跑 lint，提交前自动 review PR 工作流：\n/pr-comments #42 — 把 reviewer 的评论直接拉进来，Claude 读完直接改 /summary — 生成变更摘要，贴到 PR description /diff — 最后确认一遍改了什么 团队协作：\n/share — 把 session 分享给同事 /rc — 让同事远程控制你的 session /export — 导出 session 做技术文档 其中 /hooks 是真正能改变工作方式的。配置好之后：每次 Claude 修改文件就自动跑类型检查，每完成一轮对话就自动跑测试，把手动检查全部自动化。\n总结：记住这 9 个核心命令 # 50 个命令看着多，核心逻辑就三点：\n省钱： /model 切模型 + /effort 调深度 + /compact 控上下文——这三个加起来能砍掉一半费用。\n提效： /plan 先想后做 + /branch 并行试错 + /agents 拆分任务——从\u0026quot;线性工作\u0026quot;变成\u0026quot;并行工作\u0026quot;。\n自动化： /hooks 绑事件 + /init + /memory 维护项目记忆——从\u0026quot;被动响应\u0026quot;变成\u0026quot;主动协作\u0026quot;。\n把这 9 个命令用熟，其他的慢慢探索就行。\n参考来源：@sitinme 推文\n","date":"2026年5月6日","externalUrl":null,"permalink":"/tutorials/2026-05-06-claude-code-advanced-commands/","section":"实战教程","summary":"Claude Code 内置 50 多个 slash 命令，本文通过 5 个实战场景讲解 /compact、/model、/plan、/branch、/agents 等核心命令的组合用法，帮你省一半 Token、效率翻倍。","title":"Claude Code 高手进阶：5 个实战场景帮你省一半 Token","type":"tutorials"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/token%E4%BC%98%E5%8C%96/","section":"Tags","summary":"","title":"Token优化","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%95%88%E7%8E%87/","section":"Tags","summary":"","title":"效率","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ai%E5%B7%A5%E5%85%B7/","section":"Tags","summary":"","title":"AI工具","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/chatgpt/","section":"Tags","summary":"","title":"ChatGPT","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/github/","section":"Tags","summary":"","title":"GitHub","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/prompt/","section":"Tags","summary":"","title":"Prompt","type":"tags"},{"content":"用 AI 的人越来越多，但大多数人的 Prompt 水平停留在\u0026quot;帮我写个XX\u0026quot;。不是不想写好，是真的不知道怎么写。\nGitHub 上刚冒出来一个项目叫 yao-open-prompts，做的事情很直接——把散落在互联网各处的优质中文提示词收拢到一起，按场景分好类，开箱即用。\n它到底收了些什么 # 项目目前整理了 27 个核心 Prompt，分六大类：\n开发类（6 个） — 代码审查、Debug 助手、API 设计、SQL 优化、测试生成、重构建议。基本上覆盖了日常开发的几个高频场景。比如 code-review 这个 Prompt，直接丢给 AI 就能按最佳实践做代码审查，比自己从零写 Prompt 省事太多。\n写作类（5 个） — 博客写作（带 SEO 优化）、邮件撰写、技术文档、社交媒体内容、翻译。写作场景的 Prompt 质量差距很大，这个库里至少帮你筛选过一轮。\n分析类（4 个） — 数据分析、市场调研、文档摘要、事实核查。做研究、做竞品分析的时候直接拿来用。\n创意类（4 个） — 故事创作、头脑风暴、诗歌、歌词。玩票用的，但确实有人需要。\n商业类（4 个） — 商业计划、投资 Pitch Deck、SWOT 分析、项目管理。创业团队写 BP 的时候可以参考。\n教育类（4 个） — 个性化辅导、测验生成、学习计划、记忆卡片。教育场景的 Prompt 其实很有讲究，好的辅导 Prompt 能让 AI 从泛泛而谈变成针对性教学。\n不止这些，还聚合了社区资源 # 27 个核心 Prompt 是项目自己整理的，但它还收录了几个经典的社区 Prompt 合集：\nawesome-chatgpt-prompts — 180+ 个角色扮演 Prompt，从 Linux 终端模拟器到苏格拉底式哲学家，啥都有 awesome-system-prompts — 各大 AI 产品（OpenAI、Anthropic 等）的系统提示词合集，研究各家怎么设计 System Prompt 的好材料 awesome-llm-role-playing-prompts — 专门的角色扮演 Prompt 收集 这些社区资源已经帮你筛选过一轮了，不用自己去大海捞针。\n项目架构做得挺认真 # 说几个细节，能看出这个项目不是随便搞的：\n标准化模板 — templates/ 目录下有 Prompt 模板，规定每个提示词必须包含标题、描述、内容、使用示例、标签这些字段。这意味着每个 Prompt 的质量有基本保障，不像某些仓库就是一个 TXT 往里扔。\n贡献流程规范 — 有完整的 CONTRIBUTING.md，Fork → Branch → PR 的标准开源工作流。文件命名用小写加连字符（code-review.md），不是随便起名字。\n双语支持 — 文档分 docs/en/ 和 docs/zh/ 两个目录，中英双语都有。不过看内容重心还是在中文用户。\nMIT 协议 — 这一点很关键。很多 Prompt 合集用的 CC 协议，商用有限制。MIT 协议意味着你可以自由使用、修改、商业化，只需要保留版权声明。\n我的看法 # 说实话，Prompt 库这个赛道已经不新鲜了。awesome-chatgpt-prompts 几年前就有了，各种提示词网站也一大堆。但 yao-open-prompts 有几个点我觉得值得关注：\n中文优先 — 大多数高质量的 Prompt 资源都是英文的，对中文用户不太友好。这个项目直接面向中文场景，光是这点就有价值。\n场景分类比角色分类实用 — 很多 Prompt 库按\u0026quot;角色\u0026quot;分类（比如\u0026quot;你是一个XX专家\u0026quot;），但实际使用中，你是按需求场景来找 Prompt 的（\u0026ldquo;我要写一封邮件\u0026rdquo;），不是按角色找。这个项目的分类逻辑更贴近真实使用习惯。\n开源可贡献 — 那些提示词网站大多是闭源的，你只能用不能改。GitHub 上开源意味着社区可以持续优化每个 Prompt，质量会越来越好。\n当然，目前 27 个核心 Prompt 数量还不多，刚开源嘛。项目也才 5 个 commit，一天前刚建。但结构搭好了，后面就看社区贡献者的了。\n如果你平时经常用 AI 干活，建议 clone 下来翻翻，挑几个常用的 Prompt 先试试。比自己瞎写强。\n参考来源：yaojingang/yao-open-prompts\n","date":"2026年5月6日","externalUrl":null,"permalink":"/projects/2026-05-06-yao-open-prompts/","section":"开源项目","summary":"发现一个刚开源的中文 Prompt 提示词库 yao-open-prompts，把 AI 常用场景按开发、写作、分析、创意、商业、教育六类整理了 27 个高质量提示词，还有 180+ 角色扮演 Prompt 和系统提示词合集，MIT 协议随便用。","title":"Prompt 也要开源？这个中文提示词库把 AI 玩法整理明白了","type":"projects"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E5%BC%80%E6%BA%90/","section":"Tags","summary":"","title":"开源","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/%E6%8F%90%E7%A4%BA%E8%AF%8D/","section":"Tags","summary":"","title":"提示词","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/announcement/","section":"Tags","summary":"","title":"Announcement","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/distributed-inference/","section":"Tags","summary":"","title":"Distributed-Inference","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/local-ai/","section":"Tags","summary":"","title":"Local-Ai","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/ollama/","section":"Tags","summary":"","title":"Ollama","type":"tags"},{"content":" Ollama v4 Brings Distributed Inference to Everyone # The Ollama project has released v4.0, a landmark update that introduces native distributed inference support. Users can now split large language model workloads across multiple machines on the same network, making it feasible to run 70B+ parameter models on clusters of consumer hardware.\nKey Features # ","date":"2026年5月6日","externalUrl":null,"permalink":"/projects/2026-05-06-ollama-v4/","section":"开源项目","summary":"","title":"Ollama v4: Distributed Inference Across Multiple Machines","type":"projects"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open-Source","type":"tags"},{"content":"","date":"2026年5月6日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"This is the first post on RekCore! Stay tuned for the latest AI news, trending GitHub projects, and tutorials.\n","date":"2026年5月6日","externalUrl":null,"permalink":"/posts/test/","section":"Posts","summary":"","title":"Welcome to RekCore","type":"posts"},{"content":" Introduction # Fine-tuning large language models used to require multi-GPU clusters and massive memory. QLoRA (Quantized Low-Rank Adaptation) changed that by combining 4-bit quantization with Low-Rank Adaptation (LoRA), enabling you to fine-tune a 7-billion-parameter model on a single 24 GB GPU. The technique freezes the base model weights, loads them in 4-bit precision, and trains only small adapter layers — reducing memory usage by over 60%.\nThis tutorial walks you through fine-tuning Mistral-7B on a custom instruction dataset using the Hugging Face ecosystem.\n","date":"2026年5月5日","externalUrl":null,"permalink":"/tutorials/2026-05-05/fine-tune-llm-qlora/","section":"实战教程","summary":"","title":"Fine-Tune an LLM with QLoRA on a Single GPU","type":"tutorials"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/fine-tuning/","section":"Tags","summary":"","title":"Fine-Tuning","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/gpu/","section":"Tags","summary":"","title":"Gpu","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/peft/","section":"Tags","summary":"","title":"Peft","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/qlora/","section":"Tags","summary":"","title":"Qlora","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/ai-agents/","section":"Tags","summary":"","title":"AI Agents","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/android/","section":"Tags","summary":"","title":"Android","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/gemini/","section":"Tags","summary":"","title":"Gemini","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/google-i/o/","section":"Tags","summary":"","title":"Google I/O","type":"tags"},{"content":" Google I/O 2026: The Year of the AI Agent # Google kicked off its annual I/O conference with a barrage of AI announcements, headlined by Gemini Ultra 2.0 and a suite of autonomous AI agents designed to act on users\u0026rsquo; behalf across the web.\nGemini Ultra 2.0 # ","date":"2026年5月5日","externalUrl":null,"permalink":"/news/2026-05-05-google-io-2026/","section":"AI 资讯","summary":"","title":"Google I/O 2026: Gemini Ultra 2.0 and Autonomous AI Agents Take Center Stage","type":"news"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/project-mariner/","section":"Tags","summary":"","title":"Project Mariner","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/cuda/","section":"Tags","summary":"","title":"Cuda","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/inference/","section":"Tags","summary":"","title":"Inference","type":"tags"},{"content":" llama.cpp CUDA 12 Backend Delivers Massive Performance Gains # The llama.cpp project has merged full CUDA 12 backend support into its mainline branch, unlocking significant performance improvements for NVIDIA GPU owners. Benchmarks show up to 3x speedup for popular models like LLaMA 3.1, Qwen 2.5, and Mistral when running on Ada Lovelace and Hopper architectures.\nKey Features # ","date":"2026年5月5日","externalUrl":null,"permalink":"/projects/2026-05-05/llamacpp-cuda-12/","section":"开源项目","summary":"","title":"llama.cpp Adds Full CUDA 12 Support — Up to 3x Speedup","type":"projects"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/llamacpp/","section":"Tags","summary":"","title":"Llamacpp","type":"tags"},{"content":"","date":"2026年5月5日","externalUrl":null,"permalink":"/tags/nvidia/","section":"Tags","summary":"","title":"Nvidia","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/development/","section":"Tags","summary":"","title":"Development","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/privacy/","section":"Tags","summary":"","title":"Privacy","type":"tags"},{"content":" Introduction # Running AI models locally gives you complete control over your data, eliminates API costs, and removes dependency on external services. This tutorial sets up a production-grade local AI stack using Docker Compose with Ollama for model serving, Open WebUI for a ChatGPT-like interface, ChromaDB for vector storage, and a Python FastAPI backend for custom integrations.\nBy the end, you will have a local environment suitable for prototyping RAG applications, testing models, and building AI-powered tools — all without sending data to the cloud.\n","date":"2026年5月4日","externalUrl":null,"permalink":"/tutorials/2026-05-04-local-ai-stack/","section":"实战教程","summary":"","title":"Set Up a Complete Local AI Development Stack","type":"tutorials"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/ai-research/","section":"Tags","summary":"","title":"AI Research","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/community/","section":"Tags","summary":"","title":"Community","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/gpt-4/","section":"Tags","summary":"","title":"GPT-4","type":"tags"},{"content":" Open-Source Community Achieves GPT-4 Parity # A consortium of academic and independent researchers has released Oryx-72B, an open-source large language model that matches GPT-4\u0026rsquo;s performance across multiple standardized benchmarks. The release is being hailed as a turning point for open AI development.\nBenchmark Results # ","date":"2026年5月4日","externalUrl":null,"permalink":"/news/2026-05-04-open-source-llm-breakthrough/","section":"AI 资讯","summary":"","title":"Open-Source LLM Matches GPT-4 Performance in Landmark Release","type":"news"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/agents/","section":"Tags","summary":"","title":"Agents","type":"tags"},{"content":"","date":"2026年5月4日","externalUrl":null,"permalink":"/tags/ai-framework/","section":"Tags","summary":"","title":"Ai-Framework","type":"tags"},{"content":" LangChain v1.0 Stable Is Here # After years of rapid iteration and community feedback, LangChain has officially released v1.0. This stable milestone brings a cleaned-up API surface, hardened production abstractions, and a commitment to backward compatibility that enterprises have been waiting for.\nKey Features # ","date":"2026年5月4日","externalUrl":null,"permalink":"/projects/2026-05-04-langchain-v1/","section":"开源项目","summary":"","title":"LangChain v1.0: The Stable Release the AI Ecosystem Needed","type":"projects"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":" Introduction # AI agents go beyond simple chat interfaces. An agentic workflow lets a language model autonomously decide which tools to call, chain multiple actions together, and reason about complex tasks. The key enabler is function calling (also called tool use), where the model outputs structured JSON that maps to executable functions in your code.\nThis tutorial shows you how to build a practical agent that can look up weather data, search the web, and perform calculations — all within a single conversational loop using OpenAI\u0026rsquo;s function calling API.\n","date":"2026年5月3日","externalUrl":null,"permalink":"/tutorials/2026-05-03-agentic-workflows/","section":"实战教程","summary":"","title":"Building Agentic Workflows with Function Calling","type":"tutorials"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/function-calling/","section":"Tags","summary":"","title":"Function-Calling","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/tools/","section":"Tags","summary":"","title":"Tools","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/ai-governance/","section":"Tags","summary":"","title":"AI Governance","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/compliance/","section":"Tags","summary":"","title":"Compliance","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/eu-ai-act/","section":"Tags","summary":"","title":"EU AI Act","type":"tags"},{"content":" EU AI Act Enforcement Is Now Active # As of May 2026, the European Union AI Act has entered its enforcement phase, making it the world\u0026rsquo;s first comprehensive legal framework for artificial intelligence to be actively policed. Companies deploying AI systems within the EU must now comply or face significant penalties.\nWhat the AI Act Covers # ","date":"2026年5月3日","externalUrl":null,"permalink":"/news/2026-05-03-eu-ai-act-enforcement/","section":"AI 资讯","summary":"","title":"EU AI Act Enforcement Begins: What Companies Need to Know","type":"news"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/policy/","section":"Tags","summary":"","title":"Policy","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/regulation/","section":"Tags","summary":"","title":"Regulation","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/code-completion/","section":"Tags","summary":"","title":"Code-Completion","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/copilot/","section":"Tags","summary":"","title":"Copilot","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/developer-tools/","section":"Tags","summary":"","title":"Developer Tools","type":"tags"},{"content":"","date":"2026年5月3日","externalUrl":null,"permalink":"/tags/localpilot/","section":"Tags","summary":"","title":"Localpilot","type":"tags"},{"content":" LocalPilot — Your Private, Local Copilot Alternative # LocalPilot is a new open-source project that brings GitHub Copilot-style code completion to your machine without sending a single line of code to the cloud. It acts as a drop-in proxy for the Copilot API, routing requests to any local model served by Ollama, llama.cpp, vLLM, or even remote OpenAI-compatible endpoints.\nKey Features # ","date":"2026年5月3日","externalUrl":null,"permalink":"/projects/2026-05-03-localpilot/","section":"开源项目","summary":"","title":"LocalPilot: Run GitHub Copilot Locally with Any Model","type":"projects"},{"content":" Introduction # Prompt engineering is the art and science of designing inputs to large language models to produce consistent, high-quality outputs. While basic prompts work for simple tasks, production systems require structured, repeatable patterns that minimize hallucination and maximize reliability.\nThis tutorial covers four advanced techniques: system prompt design, few-shot learning, chain-of-thought reasoning, and structured output enforcement. Each technique includes practical examples you can apply immediately.\n","date":"2026年5月2日","externalUrl":null,"permalink":"/tutorials/2026-05-02-prompt-engineering-guide/","section":"实战教程","summary":"","title":"Advanced Prompt Engineering Techniques","type":"tutorials"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/chain-of-thought/","section":"Tags","summary":"","title":"Chain-of-Thought","type":"tags"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/few-shot/","section":"Tags","summary":"","title":"Few-Shot","type":"tags"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/ai-coding/","section":"Tags","summary":"","title":"AI Coding","type":"tags"},{"content":" AI Coding Agents: From Assistants to Autonomous Developers # The landscape of software development is undergoing a seismic shift as AI coding agents move beyond simple autocomplete to become autonomous contributors capable of designing, implementing, and debugging entire features.\nThe Current State # ","date":"2026年5月2日","externalUrl":null,"permalink":"/news/2026-05-02-ai-coding-agents-2026/","section":"AI 资讯","summary":"","title":"AI Coding Agents Reshape Software Development in 2026","type":"news"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/software-development/","section":"Tags","summary":"","title":"Software Development","type":"tags"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/ai-platform/","section":"Tags","summary":"","title":"Ai-Platform","type":"tags"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/dify/","section":"Tags","summary":"","title":"Dify","type":"tags"},{"content":" Dify: The Self-Hosted AI Application Platform Hitting Its Stride # Dify has officially crossed the 80,000 star milestone on GitHub, solidifying its position as the leading open-source platform for building, deploying, and managing AI-powered applications. With a visual workflow editor, built-in RAG engine, and multi-model support, Dify enables teams to go from idea to production AI app in hours, not weeks.\nKey Features # ","date":"2026年5月2日","externalUrl":null,"permalink":"/projects/2026-05-02-dify-self-hosted/","section":"开源项目","summary":"","title":"Dify Self-Hosted AI App Platform Surpasses 80k GitHub Stars","type":"projects"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/self-hosted/","section":"Tags","summary":"","title":"Self-Hosted","type":"tags"},{"content":"","date":"2026年5月2日","externalUrl":null,"permalink":"/tags/workflow/","section":"Tags","summary":"","title":"Workflow","type":"tags"},{"content":"","externalUrl":null,"permalink":"/en/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/en/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/en/","section":"RekCore","summary":"","title":"RekCore","type":"page"},{"content":"","externalUrl":null,"permalink":"/en/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/en/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]