本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：”Tango with Django”是一个基于Python的开源Web开发框架，采用MVT（Model-View-Template）架构模式，旨在帮助开发者快速构建高效、可扩展的Web应用。该框架以易用性和功能性著称，涵盖从数据库操作、URL路由、视图处理到模板渲染的完整Web开发流程。通过学习Django的核心组件如ORM、表单验证、用户认证和中间件机制，并结合manage.py、settings.py等关键文件的配置与使用，开发者可全面掌握现代Web应用的开发与部署方法。本项目适用于初学者及进阶开发者，助力构建真实场景中的动态网站系统。

Django 全栈开发深度解析：从 MVT 架构到生产部署

在当今的 Web 开发领域，Django 早已不是“又一个 Python 框架”那么简单。它更像是一套完整的工程解决方案，把“开箱即用”的理念玩到了极致——你刚喝完第一口咖啡，后台管理页面就已经 ready 了 😄。

但真正让开发者上头的，其实是它那套看似简单、实则暗藏玄机的设计哲学。尤其是那个让人初学时一脸懵的 MVT 架构 （Model-View-Template），表面看像是 MVC 的“改名大会”，深入之后才发现：这哪是改名？这是给 Web 场景量身定制的一整套协作协议！

今天咱们不讲干巴巴的概念堆砌，而是带你从零开始，亲手摸一遍 Django 的每一寸肌理。准备好了吗？我们直接进入实战节奏 🚀。

一、Django 的灵魂：MVT 到底是怎么跳舞的？

想象一下，用户点击了一个链接，比如 /blog/python-tips/ ，然后页面唰地一下加载出来了。这一瞬间背后发生了什么？很多人只看到结果，而高手关注的是整个“响应流水线”。

MVC 和 MVT 的“名字游戏”真相

先别急着写代码，咱们来搞清楚一个最基础也最容易混淆的问题：

为什么 Django 不叫 MVC，非要改成 MVT？

答案其实很接地气： 为了让命名更贴合 Web 开发的实际语义 。

传统 MVC 中：
- Model ：数据层 ✅
- View ：界面展示 👀
- Controller ：处理逻辑 💡

但在 Django 里，这三个角色被重新分配成了：

经典 MVC Django MVT 实际职责说明
Model Model 数据与业务规则不变
View Template 负责 HTML 渲染，也就是你看到的网页
Controller View 接收请求、调用模型、决定返回啥

所以你可以这样记一句话口诀：

🎯 “ Django 的 View 是控制器，Template 才是真正的 View。 ”

是不是顿时清晰多了？这个小小的命名调整，反而让项目结构变得更直观了。打开一个 views.py 文件，你知道里面全是控制逻辑；打开 templates/ 目录，就知道全是前端模板。

为了帮你建立视觉记忆，这里放个 Mermaid 流程图来对比两者的关系👇

graph TD
    subgraph "MVC 架构"
        A[Model] --> B[View]
        C[Controller] --> A
        C --> B
    end

    subgraph "Django MVT 架构"
        D[Model] --> E[Template]
        F[View] --> D
        F --> E
    end

    style A fill:#f9f,stroke:#333
    style B fill:#bbf,stroke:#333
    style C fill:#ff9,stroke:#333
    style D fill:#f9f,stroke:#333
    style E fill:#bbf,stroke:#333
    style F fill:#ff9,stroke:#333

    linkStyle 0 stroke:#666;
    linkStyle 1 stroke:#666;
    linkStyle 2 stroke:#666;
    linkStyle 3 stroke:#666;
    linkStyle 4 stroke:#666;

看出来没？虽然名字变了，但数据流动方向完全一致！这就是设计之美：形式服务于场景。

MVT 三剑客如何分工合作？

理解了命名逻辑后，我们来看看这三个组件是如何协同工作的。

1. Model：不只是数据库映射，更是业务心脏 💓

很多新手以为 Model 就是用来定义表结构的，比如：

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

没错，这是基本操作。但如果你只把它当“字段容器”用，那就太浪费了。

真正专业的做法是： 把业务逻辑封装进 Model 层 。

举个例子，一篇博客文章什么时候才算“已发布”？不仅要 published=True ，还得发布时间 ≤ 现在时间吧？

from django.utils import timezone

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published = models.BooleanField(default=False)
    publish_date = models.DateTimeField(null=True, blank=True)

    def is_published(self):
        return self.published and self.publish_date <= timezone.now()

    def __str__(self):
        return self.title

现在你在任何地方都可以安全调用 post.is_published() ，而不用到处写重复判断。这种设计不仅提高了可读性，还方便后期统一修改逻辑（比如加个审核状态）。

🔥 提示：永远不要让你的 views 或 templates 去判断复杂的业务条件，那是 Model 的责任！

2. View：不是函数也不是类，它是“调度中心”🚦

View 的任务很简单粗暴： 接请求 → 搞数据 → 选模板 → 出响应 。

但它有两个实现方式：函数视图（FBV）和类视图（CBV）。哪种更好？别争了，我告诉你真实使用场景：

  • 简单页面、快速原型 → 用 FBV
  • 复杂 CRUD、需要复用 → 用 CBV

来看个典型的 FBV 写法：

def post_list(request):
    posts = Post.objects.filter(published=True).order_by('-publish_date')
    return render(request, 'blog/post_list.html', {'posts': posts})

干净利落，适合教学也适合小项目。

但如果要做权限控制、分页、搜索过滤……很快就会变得臃肿。这时候 CBV 就派上用场了：

from django.views.generic import ListView

class PostListView(ListView):
    model = Post
    template_name = 'blog/post_list.html'
    context_object_name = 'posts'
    paginate_by = 10

    def get_queryset(self):
        qs = super().get_queryset().filter(published=True)
        q = self.request.GET.get('q')
        if q:
            qs = qs.filter(title__icontains=q)
        return qs

瞧见没？分页自动搞定，搜索灵活扩展，连上下文变量名都能自定义。这才是企业级项目的正确姿势。

3. Template：HTML 的“安全沙箱”🛡️

模板层最容易被忽视，但也最容易出问题。Django 的模板语言不是 Python，而是一种受限的 DSL（领域特定语言），目的就是防止你在模板里写一堆烂逻辑。

看看标准写法：

<!-- post_list.html -->
<h1>最新文章</h1>
{% if posts %}
  <ul>
    {% for post in posts %}
      <li>
        <a href="{% url 'post-detail' post.id %}">{{ post.title }}</a>
        发布于 {{ post.publish_date|date:"Y-m-d" }}
      </li>
    {% endfor %}
  </ul>
{% else %}
  <p>暂无文章。</p>
{% endif %}

几个关键点你要记住：
- {% %} 控制流程（if/for/include）
- {{ }} 输出变量（默认自动转义 XSS）
- | 是过滤器，比如 date , truncatechars , default

而且你不能在模板里调用任意方法或执行表达式，这就逼着你把逻辑往前推到 View 或 Model 层。

⚠️ 千万别为了图省事，在模板里做复杂判断或者数据库查询！那样只会埋下性能雷💣。

请求生命周期全景图：一次访问背后的旅程 🛤️

让我们完整走一遍从 URL 输入到页面渲染的全过程。假设用户访问 /blog/ ：

  1. URL 路由匹配
    python path('blog/', views.post_list, name='post-list')
    Django 根据配置找到对应的视图函数。

  2. 创建 HttpRequest 对象
    包含 method、GET/POST 参数、session、user 等信息。

  3. 进入 View 处理
    执行查询：
    python Post.objects.filter(published=True)

  4. 获取数据并准备上下文
    ORM 自动生成 SQL 查询数据库，拿到结果集。

  5. 渲染 Template
    把数据传入模板，引擎解析标签和变量，生成 HTML 字符串。

  6. 构造 HttpResponse 返回客户端

整个过程可以用下面这个序列图来概括👇

sequenceDiagram
    participant Client
    participant Django as Django Framework
    participant URL as URL Dispatcher
    participant View
    participant Model
    participant DB as Database
    participant Template

    Client->>Django: GET /blog/
    Django->>URL: Resolve URL
    URL-->>Django: Matched view.post_list
    Django->>View: Call post_list(request)
    View->>Model: Post.objects.filter(published=True)
    Model->>DB: Execute SQL
    DB-->>Model: Return result set
    Model-->>View: QuerySet
    View->>Template: render(template, context)
    Template->>Template: Process tags & variables
    Template-->>View: Rendered HTML
    View-->>Client: HttpResponse(HTML)

每一环都只关心自己的事，上下游解耦得明明白白。这种“流水线式”架构，才是中大型项目能长期维护的根本保障。

二、ORM 玩得转吗？这才是 Django 的核心竞争力 🔥

如果说路由是入口，模板是脸面，那么 ORM 就是 Django 的内功心法。

不会 ORM？那你等于只学会了敲回车运行 startproject ……

模型定义的艺术：不只是字段堆砌

我们再来看一次 Post 模型，这次加上 Meta 配置和索引优化：

class Post(models.Model):
    STATUS_CHOICES = [
        ('draft', '草稿'),
        ('published', '已发布'),
        ('archived', '归档')
    ]

    title = models.CharField(max_length=200, verbose_name="标题")
    slug = models.SlugField(unique_for_date='publish_date', help_text="URL友好标识")
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
        related_name='posts'
    )
    content = models.TextField(verbose_name="正文")
    status = models.CharField(max_length=10, choices=STATUS_CHOICES, default='draft')
    publish_date = models.DateTimeField(null=True, blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        db_table = 'blog_post'
        verbose_name = '文章'
        verbose_name_plural = '文章管理'
        ordering = ['-publish_date']
        indexes = [
            models.Index(fields=['-publish_date']),
            models.Index(fields=['author', '-publish_date']),
            models.Index(fields=['status']),
        ]
        constraints = [
            models.UniqueConstraint(
                fields=['title', 'author'],
                name='unique_title_per_author'
            )
        ]

    def __str__(self):
        return self.title

    def save(self, *args, **kwargs):
        if not self.slug:
            self.slug = slugify(self.title)
        super().save(*args, **kwargs)

有几个细节值得你反复品味：

  • unique_for_date='publish_date' ：保证同一天内标题唯一（防止 SEO 冲突）
  • on_delete=models.CASCADE ：作者删了，他的文章也跟着删
  • related_name='posts' ：反向查询更自然， user.posts.all()
  • Meta.indexes ：提前为高频查询字段建索引，避免慢查询
  • UniqueConstraint ：强约束比应用层判断更可靠
  • save() 方法重写：自动生成 slug，减少前端负担

这些都不是“必须”的，但正是这些细节决定了你的系统能不能扛住高并发。

多对多关系怎么玩才高级？

博客少不了标签功能，一篇文章可以有多个标签，一个标签也能出现在多篇文章里。

简单版：

class Tag(models.Model):
    name = models.CharField(max_length=50, unique=True)

class Post(models.Model):
    # ...
    tags = models.ManyToManyField(Tag, blank=True)

Django 会自动创建中间表 blog_post_tags ，包含 post_id 和 tag_id 。

但如果你想记录更多信息呢？比如某个标签被使用的次数、权重、添加时间？

那就得手动定义中间模型：

class TaggedItem(models.Model):
    tag = models.ForeignKey(Tag, on_delete=models.CASCADE)
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    content_object = GenericForeignKey('content_type', 'object_id')

    tagged_at = models.DateTimeField(auto_now_add=True)
    weight = models.PositiveSmallIntegerField(default=1)

    class Meta:
        unique_together = ('tag', 'content_type', 'object_id')

这叫“泛型多对多”，适用于插件化系统。不过对于普通博客，还是老老实实用 through 吧：

class PostTag(models.Model):
    post = models.ForeignKey(Post, on_delete=models.CASCADE)
    tag = models.ForeignKey(Tag, on_delete=models.CASCADE)
    added_by = models.ForeignKey(User, on_delete=models.SET_NULL, null=True)
    added_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        unique_together = ('post', 'tag')

class Post(models.Model):
    tags = models.ManyToManyField(Tag, through='PostTag', related_name='posts')

这样一来，你就可以追踪谁在什么时候给文章打了什么标签，审计日志轻松搞定 ✅。

QuerySet 的惰性机制：别被它骗了！

这是每个 Django 开发者必踩的坑之一： 你以为没查库，其实已经查了五次 。

看这段代码：

posts = Post.objects.all()

print(posts.count())  # 第一次查询 COUNT(*)
print(posts.first())  # 第二次查询 SELECT * LIMIT 1
for p in posts:       # 第三次查询完整列表
    print(p.title)

明明是同一个 posts 变量，却触发了三次不同的 SQL 查询！

这是因为 QuerySet 是“惰性的”——直到真正要数据时才会执行 SQL。

解决办法有两个：

  1. 缓存结果 ：
    python posts_list = list(Post.objects.all()) # 立即执行并缓存

  2. 使用 select_related / prefetch_related 提前加载关联数据

最常见的性能陷阱是 N+1 查询：

# ❌ 错误示范：N+1 查询
posts = Post.objects.all()
for p in posts:
    print(p.author.username)  # 每循环一次就查一次 author 表！

正确的做法：

# ✅ 正确做法：一次 JOIN 解决
posts = Post.objects.select_related('author').all()
for p in posts:
    print(p.author.username)  # 数据已在内存中

如果是多对多关系，则用 prefetch_related ：

# ✅ 预取标签数据
posts = Post.objects.prefetch_related('tags').all()
for p in posts:
    print([t.name for t in p.tags.all()])

这两个方法是你对抗性能瓶颈的第一道防线。上线前一定要用 Django Debug Toolbar 检查 SQL 数量！

三、类视图真的比函数视图强吗？答案在这里 💡

我知道你现在心里在想：“我用函数视图挺好的啊，为啥要学 CBV？”

好问题。让我给你三个无法拒绝的理由：

  1. 代码复用率飙升
    Mixin 让你可以像搭积木一样组合功能。

  2. 内置功能齐全
    分页、表单验证、CRUD 操作全都有现成的类。

  3. 团队协作更顺畅
    新人一看 UpdateView 就知道这是编辑页面，不用猜逻辑。

自定义 Mixin：打造你的专属武器库 🛠️

比如你要做一个“只有作者才能编辑”的功能，可以这样写：

from django.core.exceptions import PermissionDenied

class AuthorRequiredMixin:
    def dispatch(self, request, *args, **kwargs):
        obj = self.get_object()
        if obj.author != request.user:
            raise PermissionDenied("您没有权限操作此内容")
        return super().dispatch(request, *args, **kwargs)

然后随便哪个视图都能用：

class EditPostView(AuthorRequiredMixin, UpdateView):
    model = Post
    fields = ['title', 'content', 'tags']
    template_name = 'blog/edit_post.html'

class DeletePostView(AuthorRequiredMixin, DeleteView):
    model = Post
    success_url = reverse_lazy('post-list')

是不是比在每个函数里写 if request.user != post.author: 干净太多了？

还有更多实用 Mixin 推荐：
- LoginRequiredMixin ：登录保护
- UserPassesTestMixin ：细粒度权限
- CsrfExemptMixin ：API 接口免 CSRF
- CacheResponseMixin ：视图级缓存

这些组合拳打下来，你会发现原来写十个相似页面的时间，现在一个小时就能搞定 😎。

四、模板系统：不只是 HTML 注入，而是工程化思维 🧱

别再把 templates 当成“放 HTML 的文件夹”了。现代 Django 项目的模板结构应该是这样的：

templates/
├── base.html                 # 主布局
├── includes/                 # 可复用组件
│   ├── header.html
│   ├── footer.html
│   └── sidebar.html
├── blog/
│   ├── post_list.html
│   ├── post_detail.html
│   └── components/
│       ├── post_card.html
│       └── comment_form.html
└── registration/
    ├── login.html
    └── register.html

模板继承：告别复制粘贴噩梦 🔄

base.html 定义骨架：

<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}我的博客{% endblock %}</title>
    {% block extra_css %}{% endblock %}
</head>
<body>
    <header>{% include "includes/header.html" %}</header>
    <main>{% block content %}{% endblock %}</main>
    <footer>{% include "includes/footer.html" %}</footer>
    {% block extra_js %}{% endblock %}
</body>
</html>

子模板只需重写区块：

{% extends "base.html" %}
{% load static %}

{% block title %}{{ post.title }} - {{ block.super }}{% endblock %}

{% block content %}
<article>
    <h1>{{ post.title }}</h1>
    <div class="content">{{ post.body|safe }}</div>
    {% include "blog/components/comment_form.html" %}
</article>
{% endblock %}

{% block extra_js %}
<script src="{% static 'js/comments.js' %}"></script>
{% endblock %}

注意这里的技巧：
- {{ block.super }} 保留父级内容
- {% load static %} 加载静态资源
- |safe 过滤器慎用，确保内容可信

上下文处理器：全局变量的优雅注入方式 🌐

有些数据每个页面都需要，比如导航菜单、当前用户信息、站点配置……

难道要在每个 view 里都加一遍 {'menu': ..., 'user': ...} 吗？当然不！

用上下文处理器：

# context_processors.py
from .models import Category, SiteConfig

def global_context(request):
    return {
        'categories': Category.objects.active(),
        'SITE_CONFIG': SiteConfig.load(),
        'is_mobile': 'Mobile' in request.META.get('HTTP_USER_AGENT', ''),
    }

注册到 settings：

TEMPLATES = [
    {
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'myapp.context_processors.global_context',
            ],
        },
    },
]

从此以后，所有模板都能直接使用 {{ categories }} 和 {{ SITE_CONFIG.site_title }} ，彻底解放 views 层！

五、URL 设计：不仅仅是路径映射，更是 API 规范 🧭

好的 URL 设计能让整个项目气质都不一样。

path() vs url()：告别正则地狱

以前我们这么写：

url(r'^post/(?P<year>\d{4})/(?P<month>\d{2})/(?P<slug>[-\w]+)/$', views.PostDetailView.as_view())

现在只需要：

path('post/<int:year>/<int:month>/<slug:slug>/', views.PostDetailView.as_view(), name='post-detail')

类型转换器 <int> 、 <slug> 、 <uuid> 让路由既简洁又安全。

命名空间：多人协作不打架

多人开发最怕什么？URL 名称冲突！

解决办法： 命名空间 + 子路由拆分 

# urls.py (project level)
urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls', namespace='blog')),
    path('user/', include('users.urls', namespace='user')),
]

# blog/urls.py
app_name = 'blog'
urlpatterns = [
    path('', views.BlogIndexView.as_view(), name='index'),
    path('post/<int:pk>/', views.PostDetailView.as_view(), name='detail'),
]

模板中引用：

<a href="{% url 'blog:detail' post.pk %}">阅读全文</a>

再也不用担心两个 app 都有个叫 detail 的页面了 ✅。

六、生产级部署：从本地开发到百万流量 💼

写得再漂亮，不上线都是耍流氓。来聊聊真实的部署流程。

配置分离：一套代码，多套环境

别再把 DEBUG = True 推到生产环境了！😭

推荐结构：

# settings/
├── __init__.py
├── base.py          # 公共配置
├── dev.py           # 开发环境
├── prod.py          # 生产环境
└── test.py          # 测试环境

base.py 放通用设置， prod.py 覆盖敏感项：

# prod.py
from .base import *

DEBUG = False
ALLOWED_HOSTS = ['yourdomain.com', 'www.yourdomain.com']

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'myblog',
        'USER': 'dbuser',
        'PASSWORD': env('DB_PASSWORD'),
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

SECURE_BROWSER_XSS_FILTER = True
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True

启动时指定配置：

python manage.py runserver --settings=myproject.settings.prod

Gunicorn + Nginx：黄金搭档出场 🏆

runserver 只能用于开发！生产必须用 WSGI 服务器。

Gunicorn 启动命令：

gunicorn myproject.wsgi:application \
  --bind 127.0.0.1:8000 \
  --workers 3 \
  --worker-class sync \
  --timeout 30 \
  --log-level info

Nginx 反向代理配置：

server {
    listen 80;
    server_name yourdomain.com;

    location /static/ {
        alias /var/www/myblog/static/;
    }

    location /media/ {
        alias /var/www/myblog/media/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这样既能静态资源直出，又能负载均衡，还能 HTTPS 终止，完美！

日志与监控：出了问题怎么办？

最后一步往往是缺失的： 可观测性建设 。

至少要有这些日志配置：

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '{levelname} {asctime} {module} {process:d} {thread:d} {message}',
            'style': '{',
        },
    },
    'handlers': {
        'file': {
            'level': 'INFO',
            'class': 'logging.FileHandler',
            'filename': '/var/log/django/app.log',
            'formatter': 'verbose',
        },
    },
    'root': {
        'handlers': ['file'],
        'level': 'INFO',
    },
}

再加上 Sentry 或 Logstash 实时报警，你才算真正做到了“心里有底”。

七、总结：Django 的终极价值是什么？

写到这里，我想你应该明白了：

Django 的真正优势，从来不是“自带 Admin”或者“ORM 好用”，而是它提供了一套 清晰的工程规范 。

这套规范告诉我们：
- 数据应该放在哪里？
- 逻辑应该怎么分层？
- 错误该如何处理？
- 项目该如何组织？

当你一个人开发时，它帮你少犯错；
当你们十个人协作时，它让每个人都能读懂彼此的代码。

这才是 Django 经久不衰的秘密 🤫。

所以别再说“Django 太重”了。轻的东西往往需要你自己造轮子，而重的背后是无数经验沉淀下来的最佳实践。

下次有人问你为什么要学 Django，你就告诉他：

“因为它教会你怎么写出别人也能维护的代码。” 💯

🎯 彩蛋时间 ：想知道怎么用 Django 快速做出一个支持 Markdown 编辑、标签云、RSS 订阅的完整博客吗？评论区留言 “求源码”，我会悄悄发你 GitHub 链接 😉

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：”Tango with Django”是一个基于Python的开源Web开发框架，采用MVT（Model-View-Template）架构模式，旨在帮助开发者快速构建高效、可扩展的Web应用。该框架以易用性和功能性著称，涵盖从数据库操作、URL路由、视图处理到模板渲染的完整Web开发流程。通过学习Django的核心组件如ORM、表单验证、用户认证和中间件机制，并结合manage.py、settings.py等关键文件的配置与使用，开发者可全面掌握现代Web应用的开发与部署方法。本项目适用于初学者及进阶开发者，助力构建真实场景中的动态网站系统。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

AI智能体落地复盘：跨境业务提效多少？以及未来AI Agent的优化方向

avatar AI Agent技术社区
cover

LangChain核心组件深入理解第四篇 -- Tool Agent运行的手和脚

avatar AI Agent技术社区

AI Agent 技术在汽车智驾平台中的应用与底层 Infra 技术栈全景

注：本文由AI辅助生成从“训练模型”转向“构建系统” —— 把大模型作为大脑，通过工程手段让其自主调用工具、记忆信息，稳定可靠地完成复杂任务。答案：不是全部部署，量产方案是“端云协同”——部分放车端，部分放云端。结论：对于底层智驾岗位，“车端部署 + 实时通信 + 智能路由”是核心护城河，Agent 搭建是基本功（默认必须会）。一句话总结：AI Agent 是“用模型”，AI Infra 是“供模

avatar AI Agent技术社区