C++虚函数表与虚基表内存布局深度解析:从原理到调试实践
1. 项目概述从内存布局理解C多态的本质如果你写过C并且用过继承和多态那你大概率听说过“虚函数表”这个词。但很多时候我们只是停留在“知道有这么个东西用来实现多态”的层面。当面试官追问“虚函数表具体存在哪里”、“多重继承下有几个虚表”、“菱形继承里的虚基表又是什么”时很多人就开始含糊其辞了。我自己在早期也经历过这个阶段直到后来为了排查一个诡异的内存越界问题不得不深入对象的内存布局才真正把这两张“表”给搞明白了。这次我们不谈枯燥的理论直接从内存的角度用调试器“看见”虚函数表和虚基表。我会带你一步步拆解在单继承、多继承、特别是烦人的菱形继承场景下一个C对象在内存里究竟长什么样编译器为我们默默创建了哪些隐藏的指针以及这些指针如何指引程序在运行时找到正确的函数和基类子对象。理解这些不仅是应付面试的“八股文”更是你写出高效、正确C代码尤其是进行底层优化、内存分析和问题排查的必备内功。你会发现很多看似玄学的问题比如“为什么dynamic_cast在某些情况下比较慢”、“多继承下指针偏移的秘密是什么”其答案都藏在这两张表里。2. 核心概念拆解虚函数表与虚基表到底是什么在开始看内存之前我们必须先统一思想搞清楚这两个概念究竟是为了解决什么问题而生的。它们都是C实现其核心特性——运行时多态和复杂继承关系——的底层机制但分工明确。2.1 虚函数表动态绑定的调度中心想象一下你是一个公司的调度员手下管理着多种类型的司机比如货车司机、客车司机。每个司机都能执行“驾驶”这个动作但具体怎么驾驶开什么车步骤各不相同。你手里有一份花名册虚函数表上面记录了每个司机对应的“驾驶”方法的具体地址。当有运输任务函数调用来时你不需要在编译时就决定派谁去而是根据来接任务的司机具体是谁对象的动态类型临时去查花名册找到对应的方法地址然后派他执行。这就是动态绑定。在C中任何一个包含虚函数的类或者从包含虚函数的类派生而来编译器都会为它生成一个虚函数表。这张表是一个静态的数组存放在程序的只读数据段如.rodata。表中的每一项都是一个指向该类某个虚函数实际代码的指针。类的每个对象实例中则会包含一个隐藏的指针通常称为vptr它指向该对象所属类的虚函数表。关键点一表多用同一个类的所有对象实例共享同一张虚函数表。vptr是每个对象的“私有财产”但指向的是“公共资源”。继承与覆盖当派生类覆盖了基类的虚函数时派生类的虚函数表中对应项会被更新为派生类函数的地址。未覆盖的项则保留指向基类函数的地址。多态调用成本通过基类指针或引用调用虚函数时实际执行的是两次间接寻址第一次通过对象的vptr找到虚表第二次通过虚表中的偏移找到函数地址。这比直接调用静态绑定多了一次指针解引用这就是多态的运行时开销。2.2 虚基表解决菱形继承的共享困局虚函数表解决的是“行为”的动态分派问题而虚基表解决的是“数据”的共享和布局问题。它专为“虚继承”而生。考虑经典的菱形继承问题B和C都虚继承自AD又继承自B和C。如果没有虚继承D对象里会有两份A的子对象这会导致二义性。虚继承保证了在整个继承体系中虚基类A只有一个共享实例。但这就带来了新的挑战B和C的实例中如何定位到那个唯一的、可能存储在D对象内存布局中某个位置的A子对象这个偏移量在编译时是无法确定的因为它取决于最终派生类比如D的整体布局。于是编译器引入了虚基表。对于含有虚基类的类如B和C编译器会为其生成一张虚基表。同时该类的对象实例中会包含一个隐藏的指针vbptr指向这张表。虚基表中存储的关键信息就是从当前对象位置到其虚基类子对象位置的偏移量。关键点按需创建只有涉及到虚继承的类其对象中才会有vbptr和虚基表。偏移寻址通过vbptr找到虚基表再从中读取偏移量加上当前对象的地址就能计算出虚基类子对象的绝对地址。这使得通过B*或C*访问A的成员成为可能。与虚函数表独立一个对象可以同时拥有vptr和vbptr它们指向不同的表解决不同的问题。在多重继承中一个对象甚至可能有多个vptr。3. 内存布局实战用调试器窥探对象内部理论说再多不如亲眼所见。我们接下来用实际的代码和调试器以GCC/LLVM环境为例来观察不同继承模式下对象的内存布局。我会假设你使用g编译并使用gdb进行调试。3.1 实验准备编译器与调试命令首先我们需要让编译器不要优化掉我们的对象结构并生成带有调试信息的代码。使用-fdump-class-hierarchy选项GCC特有可以输出类的内存布局这是我们的“上帝视角”。g -stdc11 -fdump-class-hierarchy -c test.cpp -o test.o编译后会生成一个test.cpp.002t.class文件用文本编辑器打开可以看到编译器计算的详细布局。在调试时我们主要关心对象的起始地址和其内存内容。在gdb中我们可以print obj打印对象。print /x obj以十六进制打印对象地址。x /[数量][格式][单位] 地址检查内存。例如x /8xg 0x7fffffffdcc0表示从该地址开始以8字节为单位g以十六进制x显示8个值。将指针强制转换为void**再解引用可以查看vptr指向的虚表内容。3.2 场景一单继承与虚函数表让我们从一个最简单的例子开始。class Base { public: virtual void vfunc1() { std::cout Base::vfunc1\n; } virtual void vfunc2() { std::cout Base::vfunc2\n; } int data1 10; }; class Derived : public Base { public: void vfunc1() override { std::cout Derived::vfunc1\n; } // 覆盖 virtual void vfunc3() { std::cout Derived::vfunc3\n; } // 新增 int data2 20; };内存布局分析概念模型Derived 对象内存布局 (假设64位系统vptr占8字节) ----------------------- | vptr (指向Derived的虚表) | // 8字节 ----------------------- | Base::data1 (10) | // 4字节 4字节对齐填充 ----------------------- | Derived::data2 (20) | // 4字节 可能的结构体尾部填充 ----------------------- Derived的虚函数表内容 ----------------------- | Derived::vfunc1 | // 覆盖了Base::vfunc1 ----------------------- | Base::vfunc2 | // 未覆盖继承基类版本 ----------------------- | Derived::vfunc3 | // 派生类新增的虚函数 -----------------------实操要点你可以通过(void*)obj或(void**)(obj)来获取对象的起始地址也就是vptr的地址。解引用vptr即*(void**)obj得到的是虚表的地址。虚表本身是一个函数指针数组。通过gdb的info symbol 地址命令可以查询一个函数地址对应的符号名从而验证虚表中的函数。注意直接解引用虚表指针并调用函数是极度危险且平台相关的行为仅用于学习理解。在实际代码中永远通过合法的虚函数调用机制来使用。3.3 场景二多重继承与多个虚函数表多重继承让情况变得复杂因为派生类对象内部包含了多个基类子对象。class Base1 { public: virtual void f1() {} int b1_data; }; class Base2 { public: virtual void f2() {} int b2_data; }; class MI : public Base1, public Base2 { public: virtual void f1() override {} // 覆盖Base1的f1 virtual void f3() {} // 新增 int mi_data; };内存布局分析概念模型MI 对象内存布局 ----------------------- | vptr1 (指向MI-for-Base1的虚表) | // 属于Base1子对象部分 ----------------------- | Base1::b1_data | ----------------------- | vptr2 (指向MI-for-Base2的虚表) | // 属于Base2子对象部分 ----------------------- | Base2::b2_data | ----------------------- | MI::mi_data | ----------------------- MI-for-Base1虚表 ----------------------- | MI::f1 (覆盖) | ----------------------- | MI::f3 (新增) | // 注意f3被放到了第一个基类的虚表中 ----------------------- MI-for-Base2虚表 ----------------------- | Base2::f2 (未覆盖) | // 可能后跟一个调整用this指针的thunk -----------------------关键点与避坑指南多个vptrMI对象包含两个vptr分别位于Base1和Base2子对象的起始处。this指针调整这是多重继承最易出错的地方。当你有一个MI对象并将其地址赋给Base2*指针时编译器会自动将指针值调整增加一个偏移量使其指向Base2子对象的起始位置即vptr2所在处。这个偏移量通常是Base1子对象的大小。MI obj; Base2* pb2 obj; // 编译器隐式执行pb2 (Base2*)((char*)obj sizeof(Base1));虚函数表内容派生类新增的虚函数如f3的指针通常会被放入第一个基类Base1对应的虚函数表中。Base2的虚表可能只包含它自己的虚函数或者包含一个特殊的跳转代码块thunk用于在调用派生类覆盖的函数时正确调整this指针。dynamic_cast与指针调整dynamic_cast在多重继承层次中转换时其内部逻辑就需要计算这些复杂的偏移。这也是为什么在深层次、多继承体系中dynamic_cast可能比static_cast开销更大的原因之一。3.4 场景三菱形继承与虚基表登场这是最复杂也最体现虚基表价值的部分。class VirtualBase { public: virtual void vb_func() {} int vb_data 100; }; class Middle1 : virtual public VirtualBase { // 虚继承 public: virtual void m1_func() {} int m1_data 200; }; class Middle2 : virtual public VirtualBase { // 虚继承 public: virtual void m2_func() {} int m2_data 300; }; class DiamondDerived : public Middle1, public Middle2 { public: virtual void dd_func() {} int dd_data 400; };内存布局分析概念模型一种可能的编译器实现DiamondDerived 对象布局 (简化示意) -------------------------------- | vptr_Middle1 (指向Middle1虚表) | // Middle1子对象 -------------------------------- | Middle1::m1_data | -------------------------------- | vptr_Middle2 (指向Middle2虚表) | // Middle2子对象 -------------------------------- | Middle2::m2_data | -------------------------------- | DiamondDerived::dd_data | // 派生类自有数据 -------------------------------- | vbptr (可能由DiamondDerived管理) | // 指向虚基表 -------------------------------- | VirtualBase::vb_data | // 唯一的虚基类子对象 -------------------------------- | vptr_VirtualBase (指向VirtualBase虚表)| // 虚基类的vptr -------------------------------- Middle1的虚函数表及关联的虚基表 [虚函数表部分] ----------------------- | Middle1::m1_func | ----------------------- | ... | ----------------------- [虚基表部分] (通常紧挨着虚函数表或通过vptr的负偏移访问) ----------------------- | offset_to_top | // 到对象顶部的偏移用于dynamic_cast ----------------------- | offset_to_virtual_base| // 从当前子对象到VirtualBase的偏移 -----------------------核心机制解读共享的虚基类VirtualBase子对象在DiamondDerived对象中只有一份通常被放置在派生类部分之后。vbptr的归属谁负责存储指向虚基类的指针这取决于编译器实现。可能是每个虚继承的中间类Middle1,Middle2都有自己的vbptr指向各自的虚基表也可能在最终派生类DiamondDerived中统一管理。上图中展示了一种可能。虚基表的内容最关键的一项就是“到虚基类的偏移量”offset_to_virtual_base。当通过Middle1*指针访问VirtualBase的成员vb_data时过程如下通过Middle1对象的vbptr或某个特定指针找到虚基表。从虚基表中取出偏移量X。计算目标地址(char*)middle1_ptr X。这个地址就指向了共享的VirtualBase子对象。虚函数表的融合DiamondDerived覆盖的虚函数包括从VirtualBase继承的vb_func的地址需要更新到相关的虚函数表中。由于VirtualBase是共享的其虚函数表通常也只有一份。实操心得菱形继承的内存布局是编译器相关的GCC、Clang、MSVC的实现细节可能有差异。-fdump-class-hierarchy的输出是理解你当前编译器行为的最准确依据。不要死记硬背一种布局模型。4. 常见问题与排查技巧实录理解了原理我们来看看在实际开发和调试中会遇到哪些相关问题以及如何应对。4.1 问题一通过无效指针调用虚函数导致崩溃这是最经典的崩溃场景之一。Base* p nullptr; p-vfunc(); // 崩溃崩溃原因程序会尝试从p指向的地址此时为nullptr读取vptr。解引用空指针必然导致段错误。排查技巧核心转储分析如果程序生成了core dump用gdb加载后bt查看堆栈崩溃点通常就在虚函数调用处。检查指针生命周期最常见的根源是对象已销毁如局部对象离开作用域、手动delete后但指针未被置空成为了“悬垂指针”。使用智能指针std::unique_ptr,std::shared_ptr可以极大缓解此类问题。内存损坏更隐蔽的情况是对象内存被意外覆盖如数组越界、使用已释放内存导致vptr被破坏指向了非法地址。这时崩溃可能发生在解引用vptr之后。工具如AddressSanitizer(-fsanitizeaddress) 或Valgrind是排查此类问题的利器。4.2 问题二对象切片导致虚函数表现异常class Base { public: virtual void foo() { cout Base\n; } }; class Derived : public Base { public: void foo() override { cout Derived\n; } }; void func(Base b) { b.foo(); } // 按值传递发生切片 int main() { Derived d; func(d); // 输出“Base”而不是“Derived” }问题原因func(Base b)按值传参会发生对象切片。编译器用Derived对象d中的Base子对象部分拷贝构造了一个全新的、独立的Base对象b。这个新对象的vptr指向的是Base的虚函数表因此调用foo()时自然调用的是Base::foo。解决方案使用指针或引用传参void func(Base b)或void func(Base* b)。这是实现多态的基础。理解拷贝/赋值的局限性默认的拷贝构造函数和赋值运算符只进行浅拷贝对于包含指针的类需要实现深拷贝。对于多态类型按值拷贝通常不是你想要的行为。4.3 问题三在构造函数/析构函数中调用虚函数class Base { public: Base() { init(); } virtual void init() { cout Base init\n; } }; class Derived : public Base { public: void init() override { cout Derived init\n; } }; int main() { Derived d; // 输出什么 }输出结果是Base init。原理剖析在对象的构造过程中vptr是逐步初始化的。当进入Base的构造函数时Derived对象中的vptr被设置为指向Base的虚函数表。因此此时调用的init()是Base版本的。直到Base构造函数完成开始执行Derived的构造函数体时vptr才会被重新设置为指向Derived的虚函数表。析构过程则相反顺序是反过来的。最佳实践避免在构造/析构函数中调用虚函数因为此时无法实现你期望的多态行为。如果基类构造需要一些定制化初始化可以考虑使用“传递参数”或“两阶段初始化”模式。如果非用不可请明确知晓其行为知道它调用的是当前构造函数所属类版本的虚函数。4.4 问题四多继承下的指针转换与dynamic_castclass B1 { public: virtual ~B1() {} }; class B2 { public: virtual ~B2() {} }; class D : public B1, public B2 {}; D* d new D; B1* b1 d; // 隐式转换指针值不变指向D对象中的B1子对象起始处 B2* b2 d; // 隐式转换编译器调整指针指向D对象中的B2子对象起始处 std::cout (d b1) std::endl; // 输出 1 (true) std::cout (d b2) std::endl; // 输出 1 (true)但b2的值和d、b1不同 std::cout (b1 b2) std::endl; // 输出 0 (false)因为它们指向对象内不同子对象。排查技巧当调试多继承相关问题时不要仅凭指针的值是否相等来判断它们是否指向同一对象。上面的例子清晰地展示了这一点。dynamic_cast在涉及多继承时内部会进行复杂的vptr和偏移量检查以确保转换的安全性。这也是它比static_cast慢的原因。在性能敏感的代码中如果确信转换是安全的可以使用static_cast但必须非常小心。使用typeid运算符或dynamic_cast来在运行时确认对象的真实类型是更安全的方式。4.5 性能考量与使用建议空间开销每个有虚函数的对象至少多一个vptr通常8字节。每个涉及虚继承的层次对象可能多一个或多个vbptr。在内存极度受限的嵌入式系统或需要存储海量小对象的场景下需谨慎使用。时间开销虚函数调用比非虚函数多一次间接寻址。在大多数应用中这可以忽略不计。但在最内层的热循环中如果虚函数调用成为瓶颈可以考虑使用模板策略模式编译期多态替代运行时多态。清晰度优先不要为了“可能”的性能提升而放弃虚函数带来的清晰设计。多态是面向对象设计的基石在绝大多数场景下其带来的收益远大于微小的开销。理解代价正如本文所探讨的深入理解虚函数表、虚基表、多重继承下的内存布局是为了让你在遇到诡异问题时不抓瞎而不是鼓励你写出依赖这些底层细节的晦涩代码。良好的抽象和清晰的接口设计永远是第一位的。5. 总结与延伸思考走完这一趟内存之旅我们再回头看“虚函数表”和“虚基表”它们不再是神秘的黑盒而是编译器为了实现C语言承诺的抽象多态、共享基类而采用的精巧工程方案。虚函数表是“行为分派表”虚基表是“地址偏移表”它们共同协作在运行时将高级语言的概念映射到底层的机器指令和内存访问上。掌握这些知识给你带来的最大好处是“确定性”。当你的程序出现与多态、继承相关的bug时你不会再感到迷茫。你可以理性地分析崩溃点的含义。理解调试器中看到的奇怪指针值。预测dynamic_cast在不同继承关系下的成功与否。在需要极致性能或与C语言代码交互时能安全地进行类型擦除和转换。最后记住一点C给了你接近底层的能力也要求你承担相应的责任。虚函数表、虚基表这些机制是强大的工具但最好的使用方式往往是“知其所以然而后优雅地运用其然”。在99%的业务代码中你只需要遵循良好的面向对象设计原则放心地使用虚函数和继承编译器会为你处理好这一切。而那剩下的1%正是你作为资深开发者能够深入问题本质、解决复杂难题的价值所在。

相关新闻

本地部署AI编程助手Codex:从环境配置到开发流程集成实战

本地部署AI编程助手Codex:从环境配置到开发流程集成实战

在实际项目开发中,我们经常需要处理复杂的代码生成、文档补全或自动化脚本编写任务。传统的代码片段库和模板引擎虽然能提供一定帮助,但往往缺乏对上下文的理解和动态生成能力。Codex 作为基于大型语言模型的 AI 编程助手,能够理解自然语言指…

2026/8/9 5:10:20 阅读更多 →
3分钟掌握FF14动画跳过插件:告别冗长副本等待,畅享丝滑游戏体验

3分钟掌握FF14动画跳过插件:告别冗长副本等待,畅享丝滑游戏体验

3分钟掌握FF14动画跳过插件:告别冗长副本等待,畅享丝滑游戏体验 【免费下载链接】FFXIV_ACT_CutsceneSkip 项目地址: https://gitcode.com/gh_mirrors/ff/FFXIV_ACT_CutsceneSkip 还在为《最终幻想14》国服副本中那些无法跳过的冗长过场动画而烦…

2026/8/9 5:10:20 阅读更多 →
LabVIEW虚拟键盘开发:工业触摸屏输入解决方案

LabVIEW虚拟键盘开发:工业触摸屏输入解决方案

1. 项目概述:LabVIEW虚拟键盘程序开发 在工业控制和自动化测试领域,触摸屏设备正逐渐取代传统键盘成为主流交互方式。最近接到一个医疗设备控制系统的需求,需要在LabVIEW环境下开发一套专用的虚拟键盘程序。这个键盘需要同时支持字符和数字输…

2026/8/9 5:10:20 阅读更多 →

最新新闻

若依AI助手部署灾难复盘:从环境依赖到容器化重构的实战教训

若依AI助手部署灾难复盘:从环境依赖到容器化重构的实战教训

1. 项目概述:一次由“若依 AI 助手”引发的部署灾难复盘那天下午,我正兴致勃勃地准备将一个内部孵化的“若依 AI 助手”项目(内部代号 AI-Plus4Me)从开发环境推向准生产环境。这个项目旨在为基于若依框架的后台管理系统集成智能问…

2026/8/9 6:05:45 阅读更多 →
AI时代团队创造力诊断:警惕工具依赖,重塑人机协作

AI时代团队创造力诊断:警惕工具依赖,重塑人机协作

1. 当AI成为团队“新成员”:一场关于创造力的静默革命最近和几个不同行业的朋友聊天,发现一个挺有意思的现象:以前大家开会,白板上画满了各种天马行空的草图,争论得面红耳赤;现在开会,经常是先有…

2026/8/9 6:05:45 阅读更多 →
C语言项目实战:控制台扫雷游戏开发与核心算法解析

C语言项目实战:控制台扫雷游戏开发与核心算法解析

很多同学在初学C语言时,常常感觉语法枯燥,学完指针、数组后不知道能做什么。其实,通过一个完整的项目实战,是巩固知识、提升编程思维的最佳途径。扫雷游戏就是一个经典的选择,它几乎涵盖了C语言初级阶段的所有核心知识…

2026/8/9 6:04:44 阅读更多 →
AI编程工具可观测性实战:用AgentsView构建本地会话分析与成本监控仪表盘

AI编程工具可观测性实战:用AgentsView构建本地会话分析与成本监控仪表盘

1. 项目概述:为什么我们需要一个AI编程工具的“仪表盘”?最近几个月,我几乎把所有主流的AI编程工具都试了个遍。从Cursor、GitHub Copilot到Windsurf、Bolt.new,再到各种集成了大模型能力的IDE插件。工具多了,问题也跟…

2026/8/9 6:04:44 阅读更多 →
游戏赛季化与阵营系统后端架构实战:数据驱动玩法焕新

游戏赛季化与阵营系统后端架构实战:数据驱动玩法焕新

最近在整理明日方舟的赛季化更新内容时,发现“卫戍协议”这个玩法模式即将迎来重大调整,很多玩家都在讨论“乌萨斯阵营”加入的可能性。这背后其实涉及到游戏运营中一个非常经典的技术与设计话题:如何通过数据驱动的方式,对已有的…

2026/8/9 6:04:44 阅读更多 →
基于RAG与Agent技术构建垂直领域专业内容生成系统

基于RAG与Agent技术构建垂直领域专业内容生成系统

1. 这篇文章真正要解决的问题“影视门外汉尬黑超人”,这个标题乍一看像是个娱乐话题,但它精准地戳中了一个在技术圈、尤其是AI内容生成领域日益凸显的痛点:如何让一个通用大模型(“超人”)去理解和执行一个高度垂直、专…

2026/8/9 6:04:44 阅读更多 →

日新闻

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁 【免费下载链接】baidupankey 在线查询网盘提取码(维护中 rm repo) 项目地址: https://gitcode.com/gh_mirrors/ba/baidupankey 你是否曾经在深夜寻找一份重要资料&#x…

2026/8/9 0:01:47 阅读更多 →
如何快速生成中国车牌图片:Python开源工具完整指南

如何快速生成中国车牌图片:Python开源工具完整指南

如何快速生成中国车牌图片:Python开源工具完整指南 【免费下载链接】chinese_license_plate_generator 中国车牌生成器 项目地址: https://gitcode.com/gh_mirrors/ch/chinese_license_plate_generator 中国车牌生成器是一个基于Python的开源项目&#xff0c…

2026/8/9 0:01:47 阅读更多 →
收藏!小白程序员轻松入门大模型,从Harness工程开始实践

收藏!小白程序员轻松入门大模型,从Harness工程开始实践

文章强调学习大模型不应只关注模型本身,而应重视模型外的系统搭建,即Harness。提出AgentModelHarness的实用公式,详细介绍Harness的四个层次:持久化层、执行层、控制层和观察与验证层。文章还探讨了上下文工程、工具设计、AGENTS.…

2026/8/9 0:03:48 阅读更多 →

周新闻

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁

5分钟告别提取码焦虑:baidupankey如何智能破解百度网盘资源锁 【免费下载链接】baidupankey 在线查询网盘提取码(维护中 rm repo) 项目地址: https://gitcode.com/gh_mirrors/ba/baidupankey 你是否曾经在深夜寻找一份重要资料&#x…

2026/8/9 0:01:47 阅读更多 →
如何快速生成中国车牌图片:Python开源工具完整指南

如何快速生成中国车牌图片:Python开源工具完整指南

如何快速生成中国车牌图片:Python开源工具完整指南 【免费下载链接】chinese_license_plate_generator 中国车牌生成器 项目地址: https://gitcode.com/gh_mirrors/ch/chinese_license_plate_generator 中国车牌生成器是一个基于Python的开源项目&#xff0c…

2026/8/9 0:01:47 阅读更多 →
收藏!小白程序员轻松入门大模型,从Harness工程开始实践

收藏!小白程序员轻松入门大模型,从Harness工程开始实践

文章强调学习大模型不应只关注模型本身,而应重视模型外的系统搭建,即Harness。提出AgentModelHarness的实用公式,详细介绍Harness的四个层次:持久化层、执行层、控制层和观察与验证层。文章还探讨了上下文工程、工具设计、AGENTS.…

2026/8/9 0:03:48 阅读更多 →

月新闻

免费解锁百度网盘SVIP加速:macOS用户必备的下载提速终极指南

免费解锁百度网盘SVIP加速:macOS用户必备的下载提速终极指南

免费解锁百度网盘SVIP加速:macOS用户必备的下载提速终极指南 【免费下载链接】BaiduNetdiskPlugin-macOS For macOS.百度网盘 破解SVIP、下载速度限制~ 项目地址: https://gitcode.com/gh_mirrors/ba/BaiduNetdiskPlugin-macOS 还在为百度网盘macOS版的龟速下…

2026/8/8 17:02:44 阅读更多 →
终极ncmdump指南:3分钟实现网易云NCM音乐解密与格式转换

终极ncmdump指南:3分钟实现网易云NCM音乐解密与格式转换

终极ncmdump指南:3分钟实现网易云NCM音乐解密与格式转换 【免费下载链接】ncmdump 项目地址: https://gitcode.com/gh_mirrors/ncmd/ncmdump 还在为网易云音乐下载的NCM格式文件无法在其他播放器播放而烦恼吗?ncmdump解密工具帮你轻松解决这个困…

2026/8/9 0:45:04 阅读更多 →
HarmonyOS 应用开发《掌上英语》第81篇: 智能体卡片:为英语学习 App 打造桌面级学习助手

HarmonyOS 应用开发《掌上英语》第81篇: 智能体卡片:为英语学习 App 打造桌面级学习助手

AgentCard 智能体卡片:为英语学习 App 打造桌面级学习助手适用平台:HarmonyOS 7.0 (API 26 Beta)一、引言 HarmonyOS 7.0(API 26 Beta)新增了 AgentCard 智能体卡片能力,这是继 HMAF(鸿蒙智能体框架&#x…

2026/8/8 17:02:44 阅读更多 →