OpenAI 在 2023 年 3 月份的博客 ChatGPT plugins 中提到 Code Interpreter 的时候，就说到了代码解释器的一些限制。具体如下：
We execute code in a secured environment and use strict network controls to prevent external internet access from executed code. Additionally, we have set resource limits on each session.
不过这里说的有点笼统，并没有说明具体什么资源的限制，在网上搜了一圈，也没找到有哪里提到这里的具体限制细节，比如：
最近刚拿到代码解释器的权限，于是来探究下这里的资源限制具体是怎么回事。
GPT4 作为一种先进的语言生成模型，目前在聊天场景中大放异彩，很多人通过问答来解决一些简单问题。然而，在实际程序开发工作中，我们面临着错综复杂的业务需求和丰富的上下文知识。在这种情况下，简单地将所有任务交给 GPT4 处理显然是不切实际的。
那么问题来了，在这个复杂的真实业务世界里，GPT4 究竟能在哪些方面发挥作用呢？首先，我们需要理解GPT-4的核心优势和局限性。作为一种语言模型，GPT-4擅长处理和生成文本，但在处理需要深入理解和复杂推理的任务时，它可能会遇到困难。因此，我们应该聚焦于那些可以充分利用 GPT4 文本处理能力的场景。
接下来，我们将深入探讨 GPT4 在复杂业务开发中的应用场景。通过几个具体的业务例子，分析如何结合人的专业知识和 GPT4 的文本生成能力，来更高效率、更高标准的完成工作任务。这里以后台开发业务场景为例，其他前端或者算法开发，应该也能有类似的 GPT4 使用场景。
(写这篇文章的时候，GPT4 即将对所有 Plus 用户开放 Code Interpreter，到时候可以直接上传文件，让 AI 写代码并且执行，来分析数据，创建表格等。到时候 GPT4 能完成的工作会更多了，可以期待。)
我们都知道，在开发和维护后台服务时，监控函数的执行时间是至关重要的。通过监控，我们可以及时发现性能瓶颈，优化代码，确保服务的稳定性和响应速度。然而，传统的方法通常涉及在代码中添加统计信息并上报，这种方法虽然有效，但往往只针对那些被认为是关键路径的函数。
假设在某个时刻，我们突然需要监控一个并非重点关注的函数的执行时间。在这种情况下，修改代码并重新部署服务可能是一项繁琐且耗时的任务。这时，eBPF（扩展的伯克利数据包过滤器）和 BCC（BPF 编译器集合）就派上了用场。通过使用 eBPF，我们可以在不修改代码和不重新部署服务的情况下，动态地插入探针来监控函数的执行时间。这不仅大大简化了监控过程，还减少了对服务性能的影响。
在接下来的文章中，将详细介绍如何利用 eBPF BCC 来无侵入地分析服务函数耗时，并通过实际示例来展示其强大的功能。