当生成代码的成本持续下降，软件工程的稀缺资源就不再只是开发工时，而会逐渐变成 Token 预算、智能体并发能力、验证流程和产品判断。Meryem Arik 对 2030 年软件工程的预测，指向了一种明显的角色变化：工程师仍然需要理解代码，但工作重心将转向组织多个智能体、控制资源消耗，并对最终产品结果负责。
Token 会成为新的工程预算
今天的团队通常管理云计算成本、数据库容量和第三方 API 配额。进入智能体驱动的开发环境后，Token 消耗也会成为必须持续观测的工程指标。
问题不只是“一个请求用了多少 Token”。一个软件任务可能同时触发需求分析、代码生成、测试、审查和安全检查等多个智能体。如果失败后自动重试，成本还会继续放大。团队需要回答更具体的问题：
- 哪类任务值得调用能力更强、价格更高的模型？
- 一个任务最多允许多少轮规划和返工？
- 并行执行带来的时间收益是否超过额外成本？
- Token 花费最终对应了多少被接受的代码或产品价值？
这意味着 FinOps 的思路会进入开发工作流。单纯记录总账单还不够，成本需要关联到任务、代码仓库、智能体角色和交付结果。
并行智能体需要基础设施，而不只是提示词
单智能体适合完成边界清楚的小任务，但复杂软件交付往往需要角色分工。可以让一个智能体分析需求，一个生成实现，一个设计测试，另一个检查安全风险。它们可以并行工作，但必须共享明确的输入、输出格式和验收标准。
并行基础设施至少需要处理以下能力：
- 任务拆分与依赖关系；
- 并发上限、超时、取消和重试；
- 上下文隔离以及必要的信息共享；
- Token、延迟和失败率观测；
- 人工审批与审计记录；
- 对相互冲突结论的仲裁。
真正困难的部分不是启动更多模型调用，而是防止多个智能体在错误方向上快速消耗预算。编排层应当把“生成”和“验证”分开，并保留可追踪的决策记录。
一个可运行的 Token 预算与并行编排示例
下面是一个只依赖 Python 标准库的最小演示。它不调用真实模型，而是用模拟函数展示如何为并行智能体设置预算、并发上限和结构化结果。假设后续接入真实模型时，run_agent 会被替换为供应商 SDK 调用，Token 数也应改用供应商返回的实际 usage 数据。
将代码保存为 agent_budget.py，使用 Python 3.11 或更高版本运行。
import asyncio
from dataclasses import dataclass
@dataclass(frozen=True)
class AgentTask:
name: str
prompt: str
max_tokens: int
async def run_agent(task: AgentTask, semaphore: asyncio.Semaphore) -> dict:
async with semaphore:
# 演示中的估算规则不适用于生产计费。
estimated_input = max(1, len(task.prompt) // 4)
estimated_output = min(task.max_tokens, 120 + len(task.prompt) // 2)
await asyncio.sleep(0.2)
return {
"agent": task.name,
"status": "completed",
"input_tokens": estimated_input,
"output_tokens": estimated_output,
"result": f"{task.name} completed its review",
}
async def main() -> None:
total_budget = 1_500
tasks = [
AgentTask("architect", "Design an idempotent payment API", 400),
AgentTask("tester", "Create failure and concurrency test cases", 300),
AgentTask("security", "Review authentication and replay risks", 300),
AgentTask("product", "Check the user journey and acceptance criteria", 250),
]
requested = sum(task.max_tokens for task in tasks)
if requested > total_budget:
raise RuntimeError(
f"Requested output budget {requested} exceeds {total_budget}"
)
semaphore = asyncio.Semaphore(2)
results = await asyncio.gather(
*(run_agent(task, semaphore) for task in tasks)
)
actual = sum(
item["input_tokens"] + item["output_tokens"] for item in results
)
for item in results:
print(item)
print({"token_budget": total_budget, "estimated_usage": actual})
if __name__ == "__main__":
asyncio.run(main())
运行命令：
python agent_budget.py
把这个演示改造成生产系统时，可以逐步增加三道控制：任务启动前预留预算，模型返回后记录真实用量，超过项目阈值时要求人工批准。并发限制也应按照模型供应商、租户和任务优先级分别配置，而不是只设一个全局数字。
非技术构建者会改变 IT 的边界
自然语言开发工具会让产品经理、运营人员和领域专家直接构建内部应用。这会缩短从需求到原型的距离，但不会自动消除工程风险。身份验证、数据权限、依赖治理、灾难恢复和生命周期维护仍然需要明确的负责人。
平台团队因此可能从“代写所有应用”转为提供受约束的构建环境，例如预先批准的数据连接器、统一身份系统、部署模板、审计日志和自动安全扫描。非技术构建者负责表达业务意图，工程团队负责定义不能被绕过的边界。
这种变化也会影响供应商采购。智能体可能根据价格、延迟、合规区域和历史可靠性动态选择模型或服务。采购决定一旦进入自动化执行链，就必须具备可解释的选择规则、固定的授权范围和快速撤销机制。否则，一次看似普通的路由决策就可能造成数据跨境、许可证冲突或不可预测的费用。
监管会进入智能体执行路径
监管挑战不会停留在隐私政策页面。智能体能够生成代码、选择供应商并调用生产工具后，企业需要证明：谁批准了任务、使用了哪些数据、模型做出过什么建议，以及最终由谁接受了结果。
实践中应为每次高风险执行记录任务 ID、模型与版本、输入数据分类、工具调用、预算变化、审批人和输出摘要。日志还要设置合理的访问权限与保留周期，因为完整提示词本身也可能包含敏感信息。
特别是在金融、医疗和公共服务等领域，自动化程度越高，人工责任边界越需要清晰。一个“由智能体完成”的标签不能替代问责机制。
工程师需要补齐的能力
2030 年的软件工程师并非不再编码，而是不能只靠编码形成价值。更重要的能力会包括：
- 把模糊业务目标转成可验证的任务和验收标准；
- 为多个智能体设计角色、权限、预算和停止条件；
- 判断模型输出何时可信，何时必须引入确定性检查；
- 连接产品指标、工程质量与推理成本；
- 在速度、合规、供应商锁定和可维护性之间做取舍。
团队现在就可以从低风险流程开始：选择一个有明确验收标准的内部任务，记录每次运行的成本、延迟、返工次数和人工介入点。只有当这些指标稳定后，再扩大权限和自动化范围。面向 2030 的关键准备并不是押注某个模型，而是建立一套即使模型、供应商和法规不断变化，仍能控制交付质量的工程系统。