Replit与Slack合作背后：手把手搭建聊天窗口中的代码智能体

当代码智能体开始进入团队协作工具，开发方式就会发生一个很微妙的变化：开发动作不再只发生在 IDE、终端或者浏览器里，而是出现在团队成员每天都要打开的聊天窗口中。近来 Replit 与 Slack 在代码智能体方向上的合作，让很多做 AI 应用的同学开始重新思考一个问题：如果 Agent 不再只存在于编辑器侧边栏，而是直接可以接收同事的指令、写代码、跑结果并把输出丢回频道里，团队协作的节奏和边界会变成什么样？

这篇文章不打算只停留在新闻解读层面，我会从工程实践角度出发，围绕“Replit 与 Slack 合作推出 Code 智能体”背后的技术形态展开，带你拆解 AI 代码智能体的运行原理，并基于 Slack 的 Bot 能力亲手实现一个极简版“聊天窗口中的代码执行智能体”。你还会看到这一类智能体在环境准备、沙箱隔离、权限控制、超时处理上最常见的坑，以及我在落地这类需求时整理的排查清单和工程建议。

如果你正在做 AI Agent 相关的开发，或者想把代码执行能力接入到团队协作工具中，这篇文章会比较合你的胃口。

1. 为什么值得关注：Replit 与 Slack 的组合逻辑

1.1 Replit 是什么

Replit 是一个浏览器端的一体化开发平台，提供在线 IDE、云端运行环境、自动部署和一键分享能力。和传统的“本地安装 IDE + 自己维护环境”相比，Replit 把项目创建、依赖安装、代码运行、网页部署整个流程都放到了浏览器中，大大降低了编程环境管理的门槛。

我早期在给团队做内部工具演示时用过类似在线环境，最直观的感受是：它把“环境”变成了和代码一样可以复制、分享的资源。一个新同事想复现你的项目，不再需要照着 README 一步步装依赖，而是直接 Fork 一个 Replit 环境就能跑起来。这种依托云运行时的思路，天然适合作为 AI 智能体的“手和脚”。

也就是说，Replit 本身不只是一个代码编辑器，它更接近一个“可以运行代码的云执行环境”。这一点，对代码智能体来说非常重要。

1.2 Slack 是什么

Slack 是团队协作沟通工具，以 Channel 为核心组织沟通单元。很多人把它理解成“聊天软件”，但它其实有很强的扩展能力：

• Slack App，可以在工作区中注册应用并绑定机器人。
• Slash Command，通过/命令唤起自定义功能。
• Socket Mode，让应用不暴露公网地址也能实时监听消息事件。
• 丰富的 API，可发送消息、读取频道、响应事件。

这些能力组合在一起，让 Slack 成为一个天然的“开发者操作入口”。业务人员发起一个/code 运行一份报表脚本，后端 Bot 收到指令后开始执行，再把结果以文本或文件形式回复到频道。这种体验有点像“团队里的代码助手”，而不只是“聊天机器人”。

1.3 Code 智能体解决什么问题

传统开发流程中，想法转变成可运行结果，通常要经历：打开 IDE、写代码、装依赖、运行、调试、让别人看结果。这个过程对非技术背景的同事并不友好，也容易把开发者的时间切得很碎。

Code 智能体想解决的，就是把“意图到结果”的过程压缩：

• 用户用自然语言描述需求：计算这个 CSV 的平均值。
• 智能体解析意图，生成代码，在沙箱中执行。
• 执行结果或错误日志返回给用户。

放在团队协作场景里，它不只是一个效率工具，还有一层管理价值：需求、代码、执行结果、讨论过程都能沉淀在同一条 Slack 消息线程中。这比开发者在本地终端里折腾完，再截一张图发到群里要完整得多。

1.4 合作形态意味着什么

Replit 擅长提供在线运行环境和部署链路，Slack 擅长提供团队协作入口，两者结合后，最直接的技术信号就是：代码智能体正在从“单人编辑器工具”走向“多人协作基础设施”。

可以大胆推测，基于这种合作，未来团队可能会在 Slack 中发起一个/code 写一个 Python 脚本处理这份日志的指令，由智能体在云端环境中生成代码、执行任务，再把产品结果或部署地址回传到当前频道。整个流程不再需要开发者切换到命令行去敲python或git push。

这件事的技术门槛其实不低，因为它涉及几个关键点：自然语言意图识别、代码生成、安全的代码执行环境、权限控制、异步任务调度、结果回传。幸运的是，这些点我们可以在本地用一套最小工程复现，这也是后面章节的重点。

2. 理解 AI 代码智能体的工作原理

2.1 从“聊天助手”到“执行助手”

很多同学最早接触的是 ChatGPT 这类问答型助手，它只返回文本。代码智能体则不同，它的核心不是“回答问题”，而是“完成任务”，并且这个任务是可执行、可验证、可产生副作用的。

举个例子：

• 普通聊天助手：帮我写一个 Python 脚本，读取 CSV 并计算平均分。它给你一段代码，你自己复制、保存、运行。
• 代码智能体：同样的请求，它自己创建脚本文件，在沙箱中执行，然后把平均分结果告诉你。如果报错，它还会读取堆栈信息尝试修改后重跑。

要实现“自己执行”，智能体就必须具备工具调用能力，比如 Shell 工具、文件读写工具、网络请求工具。这也是当前 AI Agent 开发中常说的 Function Calling 或 Tool Use。理解这一点非常重要，因为后面我们在设计极简实例时，就是围绕“Agent + 工具”来组织的。

2.2 智能体运行闭环：感知、规划、行动、反馈

一个典型的代码智能体执行链路，通常包括以下五个步骤：

1. 接收请求：从 Slack 消息、Web 页面或 API 中拿到用户指令。
2. 意图解析：判断用户是想执行代码、生成文件，还是回答一个问题。
3. 任务拆解：如果是复杂任务，拆成多个子步骤，例如“先下载数据文件，再执行分析脚本”。
4. 工具执行：调用沙箱运行代码、操作文件系统或请求外部 API。
5. 结果反馈：把 stdout、stderr、文件链接或部署地址返回给用户。

这个闭环里最容易出问题的是第 4 步。因为让大模型生成代码很容易，但让代码稳定、安全地在隔离环境中运行却需要大量工程保障。这也是为什么 Replit 这类自带云端运行时和沙箱的平台，在代码智能体方向上具备天然优势。

2.3 Replit 代码智能体与传统 IDE 插件的区别

传统代码补全插件，比如你在 VS Code 中使用的 AI 助手，工作方式是以“编辑器”为中心：

• 你正在写代码，AI 给出补全建议或对话建议。
• AI 不直接改动你的项目结构，也不负责部署。
• 执行和部署仍然由你手动操作。

Replit 这类平台型代码智能体不一样，它的能力边界扩展到了整个项目生命周期：

• 可以根据需求自动创建项目结构。
• 可以安装依赖、执行测试、运行服务。
• 可以把结果部署到公网地址。

当一个 Slack 机器人成为这类智能体的前端时，用户的使用姿势就从“在编辑器里辅助我写代码”变成“在聊天频道中指挥它办事”。从产品体验上看，前者是 Copilot，后者更像是一个拥有独立执行能力的 Agent。

2.4 同类产品形态速览

最近这段时间，代码智能体赛道非常热闹。为了帮你建立坐标系，我把目前常见的几种形态整理成了一张表：

这张表不用记死，因为这类产品迭代非常快。你需要抓住的核心判断维度是三点：有没有自己的代码执行环境，能不能在隔离沙箱里运行，能不能和外部协作工具打通。Replit 与 Slack 的合作，正是第三条边上的典型探索。

3. 环境准备：搭建一个可复现的开发实验环境

在开始写代码之前，我们先把实验环境准备好。这一节会带你从零创建一个 Slack App，并把本地项目结构搭好。

3.1 需要准备的工具

本文示例以 Python 为主，你需要准备以下内容：

• 一个 Slack 工作区，建议直接创建一个测试团队。
• Python 3.10 或更高版本。
• pip 与虚拟环境。
• 可选：一个公网可访问的模型服务；如果没有，先用规则逻辑代替 LLM 决策。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路，不绑定某个固定版本号。后续安装依赖时也建议查阅各库官方文档确认当前稳定版本。

3.2 创建 Slack App 的前置步骤

我们选择 Socket Mode 而不是传统的 Request URL 回调，原因是 Socket Mode 不需要把本地服务暴露到公网，对新手更友好。

操作步骤如下：

1. 打开 Slack API 管理后台，点击 Create New App。
2. 选择 From scratch，填写应用名称并选择目标工作区。
3. 左侧进入 Socket Mode，开启 Enable Socket Mode，然后创建一个 App-Level Token，Scope 选择connections:write。这个 Token 是我们本地建立长连接的凭证。
4. 进入 OAuth & Permissions，在 Bot Token Scopes 中添加：chat:write、commands、app_mentions:read。
5. 点击 Install to Workspace，完成授权后复制 Bot User OAuth Token。
6. 在左侧 Slash Commands 中创建/code命令，Description 可以写“在沙箱中执行代码”，命令回调 URL 暂时可以不填。

这里有两个容易踩的细节：

• Bot Token 和 App-Level Token 不是同一个东西，别混用。
• 新增 Scope 后，需要重新 Install to Workspace，Token 才会生效。

完成后，你在管理后台能看到两种 Token：

• SLACK_BOT_TOKEN：以xoxb-开头，Bot 身份的凭证。
• SLACK_APP_TOKEN：以xapp-开头，Socket Mode 用的凭证。

3.3 项目目录结构

为了保证代码清晰，我们创建一个最小项目，目录结构如下：

slack-code-agent/ ├── .env.example ├── requirements.txt ├── app/ │ ├── __init__.py │ ├── main.py │ ├── agent.py │ └── sandbox.py └── README.md

各文件职责：

• main.py：Slack 事件入口，负责接收命令和发送结果。
• agent.py：智能体决策模块，模拟意图识别和任务调度。
• sandbox.py：代码沙箱模块，安全地执行用户提交的 Python 代码。
• .env.example：环境变量模板，记录需要注入的密钥。

4. 实战案例：做一个极简 Slack 代码智能体雏形

下面我们开始动手实现。先说明一点：这个 demo 不会调用真实的大模型，而是把“意图识别”做成规则逻辑，重点演示 Slack 消息事件、代码执行、结果回传这条链路。你可以在此基础上替换为任意 LLM 服务或 Replit 云端执行接口。

4.1 初始化项目与依赖

在项目根目录创建虚拟环境并激活：

mkdir slack-code-agent && cd slack-code-agent python -m venv .venv source .venv/bin/activate

安装依赖：

pip install slack-bolt python-dotenv

然后创建requirements.txt，内容如下：

slack-bolt python-dotenv

这里不锁定具体版本号，因为 Slack SDK 迭代较快，安装时以官方最新兼容版本为准即可。

4.2 配置环境变量

在项目根目录创建.env.example文件：

# Slack 相关配置 SLACK_BOT_TOKEN=xoxb-你的bot-token SLACK_APP_TOKEN=xapp-你的app-level-token

创建.env并填写真实 Token。注意.env文件不要提交到 Git 仓库，可以顺手在.gitignore里加一行：

.env .venv/ __pycache__/

环境变量的作用是把密钥和代码分离，避免把敏感信息硬编码到源码中。真实项目中，这些变量应该放在机密管理服务或 CI/CD 的 Secrets 中。

4.3 沙箱模块

先来实现app/sandbox.py。这个模块的作用是接收一段代码，在临时 Python 进程中执行，并捕获输出。

# 文件路径：app/sandbox.py import os import subprocess import tempfile class PythonSandbox: """极简代码沙箱，把用户提交的代码放入临时文件后以 subprocess 执行。 注意：subprocess 本地执行仅用于学习演示， 生产环境必须使用 Docker 容器、Firecracker/gVisor 等更强隔离的手段。 """ MAX_TIMEOUT = 10 def run(self, code: str) -> str: # 去除 markdown 代码块包裹 code = code.strip() if code.startswith("```python"): code = code.removeprefix("```python") if code.endswith("```"): code = code.removesuffix("```") code = code.strip() # 写入临时脚本文件 with tempfile.NamedTemporaryFile( "w", suffix=".py", delete=False, encoding="utf-8" ) as f: f.write(code) script_path = f.name try: # 在受限 PATH 下执行，并设置超时时间 proc = subprocess.run( ["python3", script_path], capture_output=True, text=True, timeout=self.MAX_TIMEOUT, env={"PATH": "/usr/bin:/bin", "HOME": "/tmp"}, ) if proc.returncode == 0: output = proc.stdout.strip() return output if output else "执行成功，无输出" return f"执行出错：\n{proc.stderr.strip()}" except subprocess.TimeoutExpired: return f"执行超时（{self.MAX_TIMEOUT} 秒）" finally: # 执行完删除临时文件，避免堆垃圾 if os.path.exists(script_path): os.unlink(script_path)

这个模块有两点必须提醒你。

第一，subprocess.run只能隔离文件系统层面的临时文件，并不能提供真正的安全隔离。一段恶意代码仍然可以读取宿主机环境变量或发起网络请求。所以我在代码注释中反复强调：它只适合学习演示。

第二，临时文件的回收使用finally块保证最终删除，避免多次调用后磁盘上堆积脚本文件。这一点在实际项目中容易被忽略。

4.4 智能体决策模块

接下来实现app/agent.py。这个模块的职责是接收用户文本，判断应该执行代码还是返回帮助信息。

# 文件路径：app/agent.py from .sandbox import PythonSandbox class CodeAgent: """极简代码智能体。 当前版本用规则函数模拟意图识别流程， 真实项目可在此处接入大模型 Function Calling， 由模型从请求中提取代码片段和任务参数。 """ def __init__(self, executor: PythonSandbox): self.executor = executor def run(self, text: str) -> str: # 支持多种触发写法，例如 "运行 print(1+1)" 或 "执行 1+1" text = text.strip() if text.startswith("运行 "): code = text[2:].strip() return self.executor.run(code) if text.startswith("执行 "): code = text[3:].strip() return self.executor.run(code) if text == "help" or text == "帮助": return self._help() return "我暂时理解不了这个请求。试试发送：运行 print(1+1)" @staticmethod def _help() -> str: return "用法：\n/code 运行 <Python代码>\n/code 执行 <Python代码>\n/code help"

如果你准备接入大模型，替换run方法的核心逻辑即可。思路是：

def run_with_llm(self, text: str) -> str: """接入大模型时的示例思路，需要按你实际使用的模型服务调整。""" from .llm import llm_complete # 伪代码，需自行实现 system_prompt = ( "你是一个代码智能体。请从用户请求中提取一段 Python 代码并直接返回。" ) reply = llm_complete(system_prompt, text) return self.executor.run(reply)

这里的llm_complete只是示意接口，真实项目中需要根据你所在团队可用的大模型服务来实现鉴权、超时、重试和 Token 消耗统计。不要把它当成某个确定 SDK 的固定 API。

4.5 Slack 事件入口

现在实现app/main.py，把 Slack 事件和智能体串起来。

# 文件路径：app/main.py import os from dotenv import load_dotenv from slack_bolt import App from slack_bolt.adapter.socket_mode import SocketModeHandler from .agent import CodeAgent from .sandbox import PythonSandbox load_dotenv() app = App(token=os.environ["SLACK_BOT_TOKEN"]) sandbox = PythonSandbox() agent = CodeAgent(executor=sandbox) @app.command("/code") def handle_code_command(ack, respond, command): # 先 ack，告诉 Slack 请求已收到，避免出现超时 ack() user_text = command.get("text", "").strip() if not user_text: respond("请输入要执行的内容，例如：运行 print(1+1)") return result = agent.run(user_text) respond(result) @app.event("app_mention") def handle_app_mention(event, say): """支持在频道中 @机器人 的方式触发。""" text = event.get("text", "") # 去掉 @机器人 前缀 text = " ".join(text.split(" ")[1:]) result = agent.run(text) say(result) if __name__ == "__main__": handler = SocketModeHandler(app, os.environ["SLACK_APP_TOKEN"]) handler.start()

代码里有两个关键点值得展开。

第一，ack()必须在处理逻辑开始时立即调用。Slack 对 Slash Command 有时间限制，如果长时间不返回，Slack 会认为请求失败。

第二，respond是 Slash Command 的上下文回复方法，它会把结果发回到用户触发的那个频道和线程中。对于耗时的代码执行，更合理的做法是先ack()并回复“任务已开始”，再通过chat.postMessage异步推送最终结果。这个优化我们在后面的最佳实践里继续讨论。

4.6 本地运行与验证

在项目根目录执行：

python -m app.main

如果一切正常，日志中会出现一条 Socket Mode 连接成功的信息。此时打开 Slack，切换到你的开发工作区，在任意频道中发送：

/code 运行 print("hello agent")

预期 Bot 会回复：

hello agent

再试试一道简单的算术题：

/code 执行 print(1 + 2)

预期回复：

3

如果发送一个不支持的指令：

/code 帮我优化一下代码

当前规则版智能体会回复：

我暂时理解不了这个请求。试试发送：运行 print(1+1)

这个流程跑通后，你就拥有了一个“Slack 中执行的极简代码智能体雏形”。后面可以把规则识别替换成大模型，也可以把本地subprocess替换成远端沙箱服务。

4.7 对接 Replit 云端执行思路

如果你希望智能体拥有更强、更安全的执行环境，一个可行的方向是把代码执行从本地迁移到 Replit 这类云端环境中。

对接时的整体思路可以拆成四层：

1. Slack 入口层：保持app/main.py不变，继续负责接收用户消息和回传结果。
2. Agent 调度层：大模型负责理解意图，决定执行什么代码、传什么参数。
3. 云端执行层：调用 Replit 或其他平台提供的接口，将代码提交到云环境中执行。
4. 结果聚合层：等待云端执行结果，把 stdout、stderr 或产物链接返回给 Slack。

如果你自己在 Replit 上搭建了一个“代码执行后端”，那么你的CodeAgent里的executor就不再是PythonSandbox，而是一个 HTTP 客户端：

class ReplitCloudRunner: """把代码交给云端后端执行。 这里只描述调用思路，不绑定具体接口。 真实项目请以 Replit 或其他云平台当前开放文档为准。 """ def __init__(self, api_base: str, token: str): self.api_base = api_base self.headers = {"Authorization": f"Bearer {token}"} def run(self, code: str) -> str: # 1. 将 code 提交到云端执行接口 # 2. 等待执行完成或轮询任务状态 # 3. 返回 stdout/stderr ...

这种架构的好处是：

• 代码在远程隔离环境中运行，不会影响本地开发机。
• 云端环境可以预置依赖，执行结果可控。
• 后续可以扩展文件上传、日志持久化、部署产物生成能力。

但代价是引入异步任务和回调机制，复杂度会高不少。建议先把本地最小闭环跑通，再逐步替换成云端执行。

5. 高频报错与排查清单

在实际开发和运行时，你会遇到各种报错。下面这张表汇总了我认为最常见的一批，以及对应的排查方向。

5.1 401 unauthorized 排查步骤

当你看到unexpected status 401 unauthorized或api_key_required类型错误时，按以下顺序排查。

先确认请求是否真的带上了 Key。

# 在代码中临时打印请求头，注意不要输出完整 Key print(request.headers.get("Authorization"))

再看 Key 对应的服务是否需要前缀，例如 Bearer 前缀。有些接口要求Authorization: Bearer xx，有些只要求Authorization: xx，两者不能混用。

最后确认环境变量是否正在生效。在项目根目录执行：

python -c "import os; from dotenv import load_dotenv; load_dotenv(); print(os.getenv('MY_API_KEY'))"

如果输出 None，说明.env文件不在当前目录，或者变量名拼写不一致。

5.2 沙箱执行风险提示

本地用subprocess是非常危险的，代码一旦包含类似os.system("rm -rf /")的操作，后果不可控。即使只是教学 demo，也不要直接执行从用户输入中提取的任意代码。一个折中办法是使用 Docker：

docker run --rm --network none --memory 512m --cpus 1 \ -v "$PWD/tmp:/workspace" -w /workspace python:3.11-slim \ python /workspace/script.py

关键参数含义：

• --network none：禁止容器访问网络。
• --memory 512m --cpus 1：限制内存和 CPU 资源。
• --rm：容器运行结束后自动删除。
• --read-only：可以进一步把文件系统设为只读。

这只是一套基础配置，真实生产场景还需要考虑镜像漏洞、持久化存储隔离和恶意请求防护。总体上，安全边界投入的重视程度，应该和智能体的开放程度成正比。

6. 生产化改造与最佳实践

从 demo 到生产，还差很多细节。下面重点说几个我认为最关键的工程方向。

6.1 安全边界

代码智能体是“一把执行代码的钥匙”，安全设计必须前置。

首先要做到最小权限。机器人账号的权限只需要执行任务所需的最小 Scope，不要图省事直接给管理权限。比如，如果智能体不需要读取频道历史，就不要申请channels:history。

其次要隔离执行环境。无论用 Docker、云函数还是 Replit 云端环境，都要保证用户提交的代码不能访问宿主机敏感目录、不能读取环境变量中的密钥、不能无限占用 CPU 和内存。

最后要考虑人工审批。对于删除文件、推送部署、修改数据库这类高风险动作，智能体应该停下来等待用户确认，而不是直接执行。这类“Plan/Execute 分离”设计，能让事故率显著下降。

6.2 输入输出治理

智能体是一个面向所有团队成员的入口，输入可能来自任何人，所以要限制输入长度。一个 10 万字的“代码请求”只会造成算力浪费和延迟。同时要设置输出最大长度。如果 stdout 超过 Slack 消息上限，应该截断或改传文件。

日志和输出中还要注意数据脱敏。用户执行的代码里可能包含密钥、内网地址或个人信息，记录日志前要对这些内容做脱敏处理。另外，严禁在返回内容中包含模型请求的明文 Key 或内部接口信息。

6.3 可观测性

没有日志的智能体在线上相当于一个黑盒。建议给每个任务分配一个task_id，并在整个调用链路上透传。例如：

• Slack 消息产生task_id。
• Agent 调用模型时带上task_id。
• 沙箱执行代码时输出带上task_id。
• 最终回复用户时附带task_id。

这样做的好处是，用户反馈“刚才那个任务结果不对”时，你可以快速检索到完整的请求、模型参数、执行日志和耗时。

6.4 配置与密钥管理

不要在代码中硬编码任何密钥。开发环境用.env，测试和生产环境使用环境变量或专门的机密管理服务。提交代码前检查 Git 历史，防止曾经误提交的 Token 永久留在仓库历史里。

另外，Slack Token、模型服务 Key、云端执行接口 Token 要分开管理，避免用一个万能密钥串联所有服务。一旦某个上游被攻破，也能把爆炸半径缩小到单一服务。

6.5 异步任务架构

Slack Slash Command 对响应时间有限制，3 秒内必须完成初步响应。如果代码执行需要十几秒，就只能先把任务状态改成“已收到”，再异步执行：

1. 用户发送/code 处理这个文件。
2. Bot 立即回复“任务已开始，task_id=xxx”。
3. 后端进入任务队列，普通线程或 Worker 异步执行。
4. 执行完成后，调用chat.postMessage把结果发送回原频道。

这种方式虽然增加了一些并发处理复杂度，但体验和稳定性都好很多。尤其是有多个用户同时提交任务时，队列机制可以防止单机进程被并发压垮。

6.6 灰度发布

如果智能体要给整个团队使用，建议先在一个内部频道灰度，观察模型返回质量、执行成功率和资源消耗，再逐步放开到更多频道。可以考虑加一个简单的“开关”配置，例如根据频道 ID 决定是否允许执行用户代码。这类小开关在初期能避免很多事故。

7. 总结与下一步学习路线

这篇内容从 Replit 与 Slack 在代码智能体方向上的合作切入，拆解了 AI 代码智能体的运行原理：从意图解析到代码生成，再到沙箱执行和结果反馈，本质上是把一次“听说读写代码”的过程变成一条可执行、可观测、可治理的工程链路。

在实战部分，我们基于 Slack Bolt 框架构建了一个极简代码智能体，支持/code 运行指令，并通过沙箱模块在本地执行 Python 代码。代码量不大，但覆盖了 Slack 应用创建、Socket Mode 连接、Bot Token 配置、事件处理、结果回传等关键环节。你也看到了如何把本地 executor 替换成 Replit 云端执行后端的大致思路。

接下来如果你要继续深入，我建议按下面的路线走：

1. 接入真实大模型：把规则判断逻辑替换为 Function Calling，让模型自主决定执行什么代码。
2. 引入真正的沙箱：学习 Docker 的基本用法，把subprocess替换成容器执行。
3. 研究异步任务：使用 Redis/RabbitMQ 或简单任务队列，支持长耗时任务。
4. 追踪主流开源项目：多看看各类智能体开发平台和工具链的实现，看看它们如何组织任务、管理工具、处理权限。
5. 做你自己的“小产品”：给智能体加一个实用的内置脚本集，比如日志分析、数据清洗、定时报告，在真实使用中发现问题。

最后说一句实在的：代码智能体最大的风险不是模型不够聪明，而是执行环境不可控。无论你选择自己用 Docker 搭建，还是借助 Replit 这类平台能力，都要先把沙箱、权限、审计这三件事想清楚。建议你先从这篇最小 demo 跑通开始，再逐步加功能。

如果这篇文章对你有帮助，可以收藏备用。你接下来打算把代码智能体接入到什么场景里？欢迎带着具体问题继续实践。