The use of the term "agents" in AI (which is most likely what you're referring to, it's the most common academic reference) is really a synonym for "software program that acts on a user's behalf". An agent is seen is more attractive because it's a somewhat personified term, being a proxy for a user; also, it tends to be associated with higher order functionality (planning for agents, learning for agents, autonomous agents, etc.). More about the origin of the term on Wikipedia:
Given that, the term "agent" is more about the purpose and type of software, not how it is programmed. OOP has more to do with how it is technically designed/implemented.
So there is nothing wrong with designing your agents using OOP principles. The two subjects are not mutually exclusive.
Also, keep in mind (as some of the comments above allude to, and I agree with): use of "agents" in academia is more romanticized term; most software acts on some user(s) behalf, and so there is agent functionality in many things. It's just software at the end of the day, and if you removed the term "agent" from our collective lexicon, you wouldn't be punishing the capability of pure software design/implementation any. You will see elements of this same debate in forums specifically about agent oriented programming, e.g.:
What I'm missing in all the answers and what I thought are the most important differences between agent/actor oriented programming and "normal" OOP is that:
AOP is a higher layer or "level" on top of OOP (often implemented using OOP).
AOP is all about making concurrent (multi threaded) programming easier, have a well defined standard way of doing it (per language or framework) and therefor making it more clearly structured. The concurrency functionality is implemented in the AOP framework or language, whereas multi threading in OOP is left up to the developer and can be implemented in any way he/she likes (one of which could be AOP :P).
Examples of languages that have some implementation to allow for AOP out of the box: newer versions of NI Labview and Erlang. Wiki has more examples.
Intuitively I would guess that in general: the more functionality you add to software, the more you would benefit from using AOP. If you don't use AOP (or some other multi-threading framework), you will probably run into all of the problems that AOP already solved for you, such as: dead-locks, racing conditions, inefficient communication between threads (event queues, message queues, data queues, etc).
A good example of an (accidental) actor oriented architecture: the internet. Because it consists of "agents" (nodes/servers/clients) that function concurrently and can tolerate failure of other servers and communication channels.
发布评论
评论（2）
人工智能中“代理”一词的使用（很可能是您所指的，这是最常见的学术参考）实际上是“代表用户行事的软件程序”的同义词。代理看起来更有吸引力，因为它是一个有点拟人化的术语，是用户的代理；此外，它往往与更高阶的功能（代理规划、代理学习、自主代理等）相关。有关维基百科上该术语起源的更多信息：
http://en.wikipedia.org/wiki/Software_agent
鉴于此，术语“代理”更多地涉及软件的目的和类型，而不是软件的编程方式。 OOP 更多地与它的技术设计/实现方式有关。
因此，使用 OOP 原则设计代理并没有什么问题。这两个主题并不相互排斥。
另外，请记住（正如上面的一些评论所暗示的，我同意）：在学术界使用“代理”是一个更加浪漫化的术语；大多数软件代表某些用户运行，因此许多事情都具有代理功能。归根结底，它只是软件，如果您从我们的集体词典中删除“代理”一词，您就不会惩罚纯软件设计/实现的能力。您将在专门针对面向代理的编程的论坛中看到相同辩论的内容，例如：
http://ootips.org/agent-orientation。 html
The use of the term "agents" in AI (which is most likely what you're referring to, it's the most common academic reference) is really a synonym for "software program that acts on a user's behalf". An agent is seen is more attractive because it's a somewhat personified term, being a proxy for a user; also, it tends to be associated with higher order functionality (planning for agents, learning for agents, autonomous agents, etc.). More about the origin of the term on Wikipedia:
http://en.wikipedia.org/wiki/Software_agent
Given that, the term "agent" is more about the purpose and type of software, not how it is programmed. OOP has more to do with how it is technically designed/implemented.
So there is nothing wrong with designing your agents using OOP principles. The two subjects are not mutually exclusive.
Also, keep in mind (as some of the comments above allude to, and I agree with): use of "agents" in academia is more romanticized term; most software acts on some user(s) behalf, and so there is agent functionality in many things. It's just software at the end of the day, and if you removed the term "agent" from our collective lexicon, you wouldn't be punishing the capability of pure software design/implementation any. You will see elements of this same debate in forums specifically about agent oriented programming, e.g.:
http://ootips.org/agent-orientation.html
我在所有答案中遗漏的以及我认为面向代理/参与者的编程和“正常”OOP 之间最重要的区别是：
AOP 是 OOP 之上的更高层或“级别”（通常使用 OOP 实现）。
AOP 就是让并发（多线程）编程变得更容易，有一个明确定义的标准方法（每种语言或框架），从而使其结构更加清晰。并发功能是在 AOP 框架或语言中实现的，而 OOP 中的多线程则留给开发人员，并且可以按照他/她喜欢的任何方式来实现（其中之一可以是 AOP :P）。
具有一些实现功能以允许开箱即用的 AOP 的语言示例：NI Labview 和 Erlang 的较新版本。维基百科有更多例子。
凭直觉，我猜测一般来说：向软件添加的功能越多，您从使用 AOP 中受益就越多。如果您不使用 AOP（或其他一些多线程框架），您可能会遇到 AOP 已经为您解决的所有问题，例如：死锁、竞争条件、线程之间的低效通信（事件队列） 、消息队列、数据队列等）。
（偶然的）面向参与者的架构的一个很好的例子：互联网。因为它由同时运行的“代理”（节点/服务器/客户端）组成，并且可以容忍其他服务器和通信通道的故障。
What I'm missing in all the answers and what I thought are the most important differences between agent/actor oriented programming and "normal" OOP is that:
AOP is a higher layer or "level" on top of OOP (often implemented using OOP).
AOP is all about making concurrent (multi threaded) programming easier, have a well defined standard way of doing it (per language or framework) and therefor making it more clearly structured. The concurrency functionality is implemented in the AOP framework or language, whereas multi threading in OOP is left up to the developer and can be implemented in any way he/she likes (one of which could be AOP :P).
Examples of languages that have some implementation to allow for AOP out of the box: newer versions of NI Labview and Erlang. Wiki has more examples.
Intuitively I would guess that in general: the more functionality you add to software, the more you would benefit from using AOP. If you don't use AOP (or some other multi-threading framework), you will probably run into all of the problems that AOP already solved for you, such as: dead-locks, racing conditions, inefficient communication between threads (event queues, message queues, data queues, etc).
A good example of an (accidental) actor oriented architecture: the internet. Because it consists of "agents" (nodes/servers/clients) that function concurrently and can tolerate failure of other servers and communication channels.